- Don’t wrap too much of your identity in a tool.
- Every tool will eventually fade.
- Flexibility is a valuable skill
- Changing tools does not mean starting over.
I agree with pretty much every word of this article.
Perhaps most problematic of all is the effect that contemporary developer experience has on educational programs (be they traditional classes, bootcamps, workshops, or anything in between). Such a rapidly expanding and ever changing technological ecosystem necessarily means that curricula struggle to keep up, and that the fundamentals of web development (e.g. HTML, CSS, HTTP, browser APIs…) are often glossed over in favor of getting students into the technologies more likely to land them jobs (like React and its many pals). This leads to an outpouring of early career developers who may speak confidently about things like React hooks or Redux state reducers, but who also lack any concept about the nature of HTML semantics or the most basic accessibility considerations. To be clear, I’m not throwing shade at those developers — they have been failed by an industry obsessed with the new and shiny at the expense of foundational practices and end user experiences.
And so, I ask: what exactly are we buying when we are sold ‘developer experience’ today? Who is benefiting from it? And if it is indeed something many of us aren’t too excited about (to put it kindly), how can we change it for the better?
I agree with pretty much every word of this article.
We were told writing apps with an HTML-first, SSR-first, progressively enhanced mindset, using our preferred language/tech stack of choice, was outdated and bad for users.
That was a lie.
We were told writing apps completely using frontend-y JavaScript would make our lives easier.
That also was a lie.
I agree with pretty much every word of this article.
If you’re top priority is paid employment, right now, React is a great choice for that.
True. But…
If your priority is long-term resilience and maintainability, vanilla JS (probably with a light build process on top of it) is the ideal choice.
It will never become obsolete, or suffer from a breaking version change. It’s fast and performant, results in less code sent over the wire, and generally has a smaller footprint of things to break.
New from Mr. Vanilla JS himself, Chris Ferdinandi:
A learning space for people who hate the complexity of modern web development.
It’ll be $29 a month or $299 a year (giving you two months worth for free).
Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.
It may sound like 32 kb of JavaScript is nothing on today’s modern web with quick devices and fast broadband connections. But for a certain cohort of users, it makes a big difference to how they experience GOV.UK.
This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!
Removing jQuery means that 32Kb of JavaScript has been removed from the majority of pages on GOV.UK. GOV.UK is already quite fast to load and for many users this will make no noticeable difference. However, the change for users on a low bandwidth connection or lower specification device will be much more noticeable, resulting in significantly improved page download speed and performance.
I’d recommend going in the order HTML, CSS, JS. That way, you can build something in HTML, add CSS to it as you learn it, and finally soup it up with your new-found JS knowledge.
Excellent advice for anyone new to web develoment.
Once you start getting into interactive website territory, with API calls and fancy stuff, that’s where you need JavaScript (JS) knowledge. More specifically, vanilla JS: plain JS with no additional frameworks or plugins. The JS that your browser understands without having to do any pre-processing. It makes working with frameworks a whole lot easier, and it’ll help you to know when not to use a framework (and avoid making users download massive JS bundles when all you need is a tiny bit of code).
Elise Hein documents what it was like to build a website (or web app, if you prefer) the stackless way:
- use custom elements (for modular HTML without frameworks)
- use the in-browser package manager (for JavaScript packages without build tools)
- match pages with files (to avoid routing and simplify architecture)
- stick to standards (to avoid obsolescence and framework fatigue)
Her conclusions are similar to my own: ES6 modules mean you can kiss your bundler goodbye; web components are a mixed bag—it’s frustrating that Apple are refusing to allow native elements to be extended. Interestingly, Elise feels that a CSS preprocessor is still needed for her because she wants to be able to nest selectors …but even that’s on its way now!
Perhaps we might get to the stage where it isn’t an automatic default to assume you’ll need bundling, concatenation, transpiling, preprocessing, and all those other tasks that we’ve become dependent on build tools for.
I have a special disdain for beginner JavaScript tutorials that have you run
create-react-appas the first step, and this exercise has only strengthened my conviction that every beginner programmer should get to grips with HTML, CSS and vanilla JS before delving into frameworks. Features native to the web are what all frameworks share, and knowing the platform makes for a stronger foundation in the face of change.
Van11y (for Vanilla-Accessibility) is a collection of accessible scripts for rich interfaces elements, built using progressive enhancement and customisable.
I really enjoyed this interview between Drew and Chris. I love that there’s a transcript so you can read the whole thing if you don’t feel like huffduffing it.
I decided to implement almost all of the UI by just adding & removing CSS classes, and using CSS transitions if I want to animate a transition.
Yup. It’s remarkable how much can be accomplished with that one DOM scripting pattern.
I was pretty surprised by how much I could get done with just plain JS. I ended up writing about 50 lines of JS to do everything I wanted to do.
Pairs nicely with HTML DOM.
This is a great way to organise code snippets—listed by use case, and searchable too!
Next time you’re stuck on some DOM scripting, before reaching for a framework or library, check here first.
Frameworks (arguably) make building complex applications easier, but they make doing simple stuff more complex.
And that’s why I think people should learn vanilla JS first. I’ve had many students who tried to learn frameworks get frustated, quit, and focus on vanilla JS.
Some of them have gone back to frameworks later, and told me that knowing vanilla JS made it a lot easier for them to pick up frameworks afterwards.
Chris Ferdinandi is a machine!
A vanilla JS roadmap, along with learning resources and project ideas to help you get started.
Some more useful snippets of JavaScript. The functions and helpers are particularly handy if you’re weaning yourself off jQuery.
Another deep dive into web history, this time on JavaScript. The timeline of JS on the web is retroactively broken down into four eras:
Nice to see “vanilla” JavaScript making a resurgence in that last one.
It’s 2017, the JavaScript ecosystem is both thriving and confusing as all hell. No one seems to be quite sure where it’s headed, only that it’s going to continue to grow and change. The web’s not going anywhere, which means JS isn’t going anywhere, and I’m excited to see what future eras bring us.
This is such a great perspective on what it’s like to build for the web over the long term. The web will always be a little bit broken, and that’s okay—we can plan for that.
The Web has history. If you build with web technology it will stick around. We try not to break the web even if it means the mistakes and bad decisions we have made in the past (and will make in the future) get set in stone.
Here’s a handy directory of scripts that set out to solve one problem without any dependencies. Useful for poking at, picking apart, and learning from.