This lasted years.
How did this happen?
It was probably 2012-2013, the huge changes that ES6 would bring us were all over the place.
I would argue being there since the beginning (yes, I’m that old) makes it even tougher - Tim Tate
var was left in the dust.
function does not exist anymore.
Prototype-based inheritance, which took a long time to learn properly, is gone, hidden under the 🌈 carpet of classes.
Build all the things
One big shift that was happening was building.
But when the Babel forces came along, I initially fought even harder but in the end I raised the white flag, and I joined the enemy.
I realized Babel is not some fancy library that introduces future, edge features, and when those land in the browser we’ll forget Babel. No, Babel is here to stay, for the foreseeable future.
When ES2017 will fully land in the browser, Babel will allow for ES2018, ES2019 and so on. There’s no escape. Embrace the future, Babel is your friend.
Use the simplest alternatives
No more huge releases
ES6 was so big that the ECMAScript committee decided to do smaller releases next time. This is why ES6 is also called ES2015, and was the first release with the year- we’ll have a yearly release from now on. It’s easier to catch up, will have less changes as the time to add them is limited, and it’s predictable (keep in mind though, there will be change).
Ignore the buzz
If you’re like me, you might follow a lot of people on Twitter that are always on the edge. Maybe some thought leaders that dictate what’s the next big thing. They say to use X, everyone else uses X.
Maybe they like to show their snippets using the latest APIs which are not even close to being standard, but can be used with a flag in the browser.
They might have a good reason. You do not. Don’t fall in the trap of the shiny new toys, focus on your work.
There is not a new framework every week
But the thing to note is that the big things do not change much frequently.
React is 6 years old.
Vue is 5 years old.
5 years is a very long time in tech. Those are stable technologies. Learn it now, they are here to stay for a long time, too - they are not going away.
You have plenty of time to become an expert in any of those frameworks, they are not going to go away anytime soon.
Accept that things come and go
That said, anything has a lifecycle.
A few years ago jQuery was used everywhere, now rarely do new projects start with it.
In 2013 Backbone.js was huge. Now it has disappeared from the map. CoffeeScript, removed from the face of earth.
Ember.js, Angular.js, and Meteor rocked and stayed at the top of their popularity for a few years, now the most talked about ones seem to be React, Vue, and Angular (which is different from Angular.js).
Each cycle for those major frameworks usually lasts quite a few years. I still have lots of Ember.js applications running just fine, there is no need to update them if they do their job, and I don’t plan to touch them.
Tech evolves and matures, then it gets used rather than talked about.
You are not stupid for using jQuery
Some people have a thick skin. But if you read around enough, you will find those that despise the technology that everyone once used and inform you that you are wrong. 😆
Having used PHP for a long time, I got used to this, it’s normal to have people criticizing something popular. Even Go, which is amazing for its simplicity, is sometimes criticized for that. You will always find someone that throws shit at something.
As an example, I have to cite this tweet by Pieter Levels, who built a huge independent business with a single PHP file.
But as a beginner you might find out someone that says you’ve chosen an old tech, that no one uses it any more, that you should use React instead. Ignore them, move them out of your mind.
If it works for you, it’s the right stack.
Most of the times tech is built from giant companies with needs completely, radically different than yours, or the ones of your small team. Go with what you know and make a difference even without using leading edge technology.
The other part of the spectrum is over-engineering. Don’t use tech just to feel smarter. Know it better. And learn when to use a framework or library that helps you.
You don’t have any obligation to know everything. Find your balance.
While it might sound like it from reading your Twitter feed, no one knows all the things. There’s no way someone can learn all the stuff that’s going on in frontend development. This is a lifetime school. There’s absolutely no way to graduate.
Pick tech with user-friendly documentation
It’s not by chance that React and Vue have amazing documentation. It’s a key part of their success.
Last year the ECMAScript language introduced await/async and now that feature of the language is used a lot. Promise-based code simply looks bad, you feel the urge to rewrite everything.
Don’t do it, and instead use new features for the new code you write. The same will happen this year, with ES2018. Everyone will talk about them for a while, then we’ll get back to work and we’ll start talking about the ES2019 features.
Learn the basic fundamentals, and pick your own journey
Developing on the Web Platform requires a commitment to learn something new often, even just to find out what’s possible.
Sometimes learning in 20% of the time the 80% of the things you will need is enough, without diving too much into the edge cases.
The journey has just begun
More lab tutorials:
- The stack I use to run this blog
- 8 good reasons to become a software developer
- SEO for developers writing blogs
- Review of the book The 4-Hour Work Week
- Build a lifestyle business
- Build your own platform
- As an indie maker, what kind of product should you build?
- Create your own job security
- Developers, learn marketing
- The freedom of a product business
- Generating value
- Have a purpose for your business
- The idea is nothing
- The niche
- Remote working for software developers
- Product / market fit
- The best podcasts for frontend developers
- Why should I create an email list?
- Disconnect time from money
- The scarcity principle applied to software products
- The social proof principle
- How I added Dark Mode to my website
- My notes on the Deep Work book
- The pros of using a boring stack
- How to estimate programming time
- On going independent as a developer
- How to learn how to learn
- Why interview questions for programming jobs are so difficult?
- Do I need a degree to be a programmer?
- Everyone can learn programming
- How to be productive
- How to get the real number of pageviews of a static site
- Have you filled a developer bucket today?
- How I record my videos
- All the software projects I made in the past
- Tutorial purgatory from the perspective of a tutorial maker
- Every developer should have a blog. Here’s why, and how to stick with it
- Having a business mindset for developers
- How to write Unmaintainable Code
- What is Imposter Syndrome
- How to work from home without going crazy
- How I prototype a Web Page
- You should be the worst developer in your team
- How to start a blog using Hugo
- Write what you don't know
- How to block distractions using uBlock Origin
- Coding is an art
- I wrote 1 blog post every day for 2 years. Here's 5 things I learned about SEO
- Dealing with the fire
- On being a generalist
- The Developer’s Dilemma
- My plan for being hired as a Go developer. In 2017
- Productivity gains of using a Mac and an iOS device
- How to go from tutorials to your own project
- This is my little Digital Garden
- How to start freelancing as a developer
- Sharing the Journey Towards Building a Software Product Business
- Subfolder vs subdomain
- How I use text expanding to save time
- Software is a superpower
- I love books