- There are more things to learn than ever
and how could any of us keep up?
These days it's just like ugh.
(electronic music)
So, the other day, I put out a tweet
asking people their thoughts about Grid
and David Kerns tweeted something back
that I found really interesting
and I thought I would turn it into a viewer question.
He was saying that one of the things
that sort of is a fear around learning Grid
is that things will change,
that somehow either the spec will change
or the browsers will change
or our idea of how to use Grid will change,
the best practices will change
or I think, especially,
that somehow the tool itself will change.
And any time that he or others
might put into learning Grid right now
might be, it might be too soon,
you might have to relearn it or it might go away
or, like, why bother to spend all that time learning it?
I get it.
I feel like we're in a time right now
where there are more things to learn than ever
and every week there's some hot,
new must-learn thing everybody's talking about
and how can any of us keep up
with learning every single one of these things?
Maybe 10 or 15 years ago,
it seemed like as soon as you heard about a new tool,
a new technology, you got all excited
and you definitely wanted to go learn it,
especially if it seemed like a lot
of people were talking about it,
that it would be important to go learn
but these days, it's just like, ugh,
there's too, too, too, too many.
So how in the world are we supposed to keep up?
Why should we invest time learning something
like CSS Grid or any and the rest of the stuff
I'm talking about with Intrinsic Web Design?
Don't we already have too much on our plates?
It's just too much.
Here's what I have to say about that.
I was speaking at an event, a part in Seattle,
in April and Jeremy Keith who is one
of my favorite speakers was there as well.
And he was presenting this new talk
where he separated and it's just such
a smart way to think about it,
he's separated our material from our tools,
for us to really not think about CSS Grid
as another tool or to think about Gulp
and Broccoli but to actually understand
that there are materials and there are tools,
that HTML, CSS, and JavaScript
are the thing of which the web is made.
They are the materials of the web
and things like GIT, NPM, Yarn,
Sass, Gulp, Grunt, Babel, Webpack,
Vue, React, Ember, jQuery, Angular, Bootstrap, Foundation,
these are all tools.
They're starter kits or they're frameworks
or they're build tools or they're things
that help you write code faster
or things that help you not repeat
certain tasks over and over again.
Those are tools.
And, you know, you could think about it
like, oh, you're gonna build a house,
so your tools are things like your hammer
and your saw and your materials
are the things like the boards that you buy
or the roofing shingles that you're using
and you're choosing which roofing shingles to use.
They're separate.
So I really think that putting time
into learning about new material
is more valuable and makes more sense
than time being put into learning a new tool.
Not to say you shouldn't learn a new tool.
We absolutely should learn new tools
but I kind of feel like at this point
there are so many tools, there are so many options
when it comes to build tools or tools for launching things,
tools for speeding up your workflow,
tools for not repeating yourself with code,
tools for getting started with a starter kit or a framework.
There are just so many thousands of options out there,
that in a way, it might be best
to wait till you have a problem,
a real problem, and then look for something
to help you solve that problem.
So you find yourself repeating yourself
over and over and you go, huh,
I wonder if someone has created a way
to automate this so I don't repeat myself so much.
Ah, that would save me a lot of time
because I am spending a lot of time
repeating myself in this one particular way.
Instead of going out and being like, oh,
there's 45 more tools for making things
more efficient, I should learn all 45 of them,
even though 44 of them are solving
a problem I don't actually have.
Maybe 15 years ago we could do that
but at this point, it's just too much.
But that to me is separate from learning our material
and when there's a new thing in HTML
or there's a new thing in CSS
or there's something fundamentally
changed about the way the web works,
the way the network works or the way
that the things that you can do using JavaScript,
that time is well spent learning those things.
Vanilla JavaScript, vanilla JS,
vanilla CSS, vanilla HTML,
because that stuff will never change.
When something new is added to CSS,
when it's actually shipped for real in CSS
and put into browsers, it's there permanently
and in some ways, it's kind of hard,
when inventing new CSS to invent CSS
or change CSS or do something to the nature of CSS
so that it doesn't break web sites
that have been around for 20 years
or the way the web works
because you will create a mess
where things can't operate properly.
So it's one of the constraints of the folks
who invent new CSS, to make sure
that they never break pre-existing code,
that they've never changed it too much.
So any code you write today is gonna run in 10 years.
Any code you write today is gonna still work,
ideally, I think, it's gonna work in 100 years.
I really believe that the time spent learning CSS Grid
or other new CSS technologies
is time well spent and that if any of us
needs to kind of cut back on the overwhelm,
to definitely cut back on the tools
and don't cut back on the material,
learning about the medium,
learning about the material itself.
The other question that David had, really,
was about, he said something in a later tweet
about, well, what about Flexbox?
Like, there was a moment, there have been instances
where people have put time
and energy into learning something like Flexbox,
only to later have it be changed
or that the earlier understanding was a mistake
or that things are not what they were
when it was first invented.
That is true, that has happened,
especially Flexbox is a very good example,
where the CSS working group wrote a draft for Flexbox
and put everything behind prefixes
and then changed the spec and changed
what the prefixes did and then changed
the spec again and eventually came up with a final draft,
the final version, the final version,
not even a draft, and that is what shipped in browsers.
But the reason that things were changing
is because of the way the CSS working group
thought about the invention of CSS
and this thing where we had vendor prefixes.
And the whole plan with the vendor prefixes
is that the code would keep changing
but web developers, web designers,
were not supposed to use it.
I didn't know this.
I used web prefixes all the time
but there was this idea that we weren't supposed
to use it yet 'cause it wasn't baked.
Turns out that that didn't really,
that system didn't really work very well
and so now we're getting rid of vendor prefixes.
Now, nothing is coming out with a vendor prefix
and everything is being put into the browser
and changed and made different
and different ideas about how the specs work
are discussed and it might take years
for a new thing to get worked out,
all the details, but in all of those years,
it's not actually in the browsers
in such a way that we can put it on our websites
because our users don't have it.
Everything is behind a flag.
So Grid did that for five years.
Grid changed multiple times over five years
but that happened between 2012 and 2017.
So we didn't know it.
People that are web developers, web designers,
were not actually using Grid,
we were not writing code with Grid,
we were not launching websites with Grid
and all of those changes were made,
kind of, not in secret but sort of in a world
that we didn't even realize was happening,
many of us, most of us.
So once Grid finally did hit browsers,
once it finally did ship, it shipped finished.
Unlike Flexbox, it shipped finished.
And that's the principle that every browser
maker is using, going forward.
No one is using vendor prefixes anymore.
Everybody's waiting until the spec
is really, really finished.
It's behind a flag and if you want to test it out,
you can use a browser like Firefox Nightly
and turn on flags and learn all about that
and get into experimental world
but if you want to stay in the real world
where your users have these things in their browsers,
they won't show up until it's done.
So once it has shown up and once it is ready to go,
it really is ready to go.
And so Grid may change, it may evolve.
There are several things, many things
that people would like to add to it.
I hope that we do add a lot of those ideas to Grid
but the things that exist right now,
if you learn Grid level one,
that time spent will be well spent
because that code, that way of working,
that mental model is not going to change
for the rest of our lives.
It's gonna be for better or worse, we're stuck with it.
It's going to stay the way that it is now.
So go for it, learn Grid.
We don't really know what the best practices are.
And, well, of course we'll discuss best practices
and we'll debate whether or not
we should write our code this way
or write our code that way and we may decide
to change our techniques or just change
the way we use it or we may come up with new ideas
and you know, 10 years from now,
we might use Grid in a way that's different
than our first thoughts of how to use it today.
But Grid itself, the technology of Grid,
the syntax and what each thing does is not gonna change.
So don't worry, it's cool.
It's time to learn it.
It's been out for well over a year now
and why not?
Let's go.