First of all, it is by now ubiquituous and you can create a lot of amazing things with it.
You know the best thing though? I envy you!
Think of The Guide as the whole back catalogue of a band with all their sins of the past. Whereas “The Good Parts” is their hit single.
Starting with a much cleaner slate
And here is where you come in. I don’t even want you to think about the good parts of the language itself. That can come later — if deep-diving on a language’s syntax and constructs tickles your fancy. Right now, I envy you because you have a chance to hit the ground running. And I want you, as a newcomer, to not repeat the mistakes we did to get where we are.
You’re very welcome to disregard this advice. You’re also welcome to challenge it — after all, this is what new voices are about.
If something sounds too good to be true, often that is exactly what it is.
This is where the MDN Web Docs is my weapon of choice. It is an unbiased, open, very well maintained resource. It is not a Mozilla only thing, but many other players add content and help keeping it up-to-date. It is even writable — you can do edits when you find something is wrong.
The great thing about the Web Docs is that it isn’t “just” documentation. It also has code examples and detailed browser support tables for all the things it talks about.
Many resources that tried to document the open web came and went. MDN prevailed.
Talking about browser support, Can I use is a well-maintained resource. It doesn’t only show detailed browser support. It also links to the standard documents telling you what should happen. And it shows the quirks and problems in various versions with possible workarounds.
Browsers are much less of a problem
Talking about browsers, it is a wonderful time in that regard. We’ve had a tricky ride there. In the past, browsers were a black hole and we had no idea what magic made them work.
Until browsers committed to following standards we had to know about their ideas how things should work. In essence, our career was dependent on knowing how browsers mess up. That’s easy to do, but in the long run not fulfilling.
Nowadays browsers take a much more leading role in defining and inspiring standards. Browsers themselves strive to be evergreen. Non-standardised functionality is behind flags or shipped in “developer editions” or nightly builds.
The best thing is that browsers makers are available for feedback and invite you to file bugs. This has been a massive change and something we as developers should cherish.
There is a lot less of “this is how it is, not much we can do” and a lot more “well, that doesn’t work, can we get this fixed”.
Learning browser developer tools
Moving from console.log() to breakpoint debugging
We’re human, we get tired, we get bored, we get sloppy. That’s why it is good when we get reminders that we’re doing something wrong whilst we’re doing it. In Word processing this is the spelling and grammar check that adds squiggly red lines were we went wrong.
Linting — prevent bugs by not writing wrong code
In development, this is linting. Linters are software that analyses your code while you write it. It executes the partial code in the background and tells you when something is wrong. In the past you needed to install and configure linters yourself. These days, many come as extensions to editors with preconfigured rules. Rules that are the result of years of experts arguing and finding a consensus what makes sense. Google’s developer tools in Chrome give you similar insights. Reading through the results of linters is a good learning exercise. They not only tell you that something is wrong, but also why, what the effects are and how to fix it.
Finding an editor that makes you more effective
Publication and build processes
That said, editors are not the only place where linting can help. It can also be a part of a publication process. Sonar, for example is a tool that requires a URL and than tells you all the things that need improvement. This involves performance, compatibility, security and many more. A service like Sonar can act as a gate-keeper in your release process.
A bug found by you is better than one reported by your users. Or, even worse, one that prevents people from using your work without you ever hearing about their problems.
A common piece of advice is to start your own project and follow best practices as you can’t break others that way. But I am not sure how helpful this is and found it rather dry and frustrating.
Should creating your first project include configuring your own server?
There is no doubt that you learn a lot by starting your own projects and running them in a professional manner. But you don’t need to start that way. I’d argue it makes more sense to start smaller. JSBin, CodePen, Glitch and other hosting communities are there for you to play and learn. They allow you to use preprocessors, frameworks and package managers to build something.
You don’t get stuck setting them up and configuring your own computer over and over again. You can see if they work for you without the overhead of having to learn and un-learn something.
In a job, as part of a team, it is unlikely that as a junior developer you’d be setting up the environments. So keep that for when it is necessary.
Learning materials are free and in abundance. But what’s good and what’s spam?
Contributing to projects and dealing with other people
Instead of starting by owning of a product, it makes much more sense to take part in existing ones.
Many open source projects have people to help you get involved. You can get started by helping to improve documentation. You can fix simple problems maintainers are too busy to look at as they got bigger fish to fry.
You can learn a lot by lurking and seeing what people do and how they work with each other. You also learn what to avoid and what kind of developer not to become.
It doesn’t help that many community tools value “fast an often” as a way of contribution over “good and well explained”. You will encounter terrible communication and open hostility to change and discussion.
You’re new here. Be that new person and a better one than those who annoy you
And here is my plea to you. Don’t become that person. Don’t feed the ego of those valuing telling others that they are wrong over working together. Stay calm, be kind and don’t let blanket statements and open dismissal of ideas stop you.
There is a lot to choose from. No need to fill your life with more drama, when all you want is to make your mark as a creator.
We have a beautiful technology stack here and if I learned anything that change is the only constant. And today, here and now, I hope that you will be part of a change that we need.
Your happiness is more important than getting into fights over syntax, process or what framework to use. Happy developers build better products. The more diverse we become, the more we can reflect those who use our products.
And with that, I am looking forward to seeing what you do next. Thank you for going on this journey. It did me good, I hope it also will work for you.