I learned “pure” JS back in 2013, when HTML5 was brand new, and I still don’t get most of the stuff going on nowadays.
I work on a large code base that was built in .NET 4 with a lot of jQuery for the front end. We’re modernizing it, but it’s very slow work. A significant part of the work is improving the organization of scripts, of which there are thousands. We’re not even prioritizing getting rid of jQuery, because it works. To rewrite all the stuff that works, instead of focusing on structural matters, dependency management, maintainability and security, would be insane. (And that’s just the JS bits, on top of which there’s all the legacy .NET stuff to do.) We aim to get it into a state that will leave it working and maintainable in future without excessive effort.
Sometimes I wonder who these people are who always promote this year’s library or framework, then next year promote something newer. Do they work in real companies with real applications under heavy use? Have they ever had to maintain a codebase that was written more than 6 months ago? Or do they just build proofs of concept and small apps and pontificate a lot, then move on to the next job before things get serious?
We did a full rewrite of our site years ago going from backbone to react and TS. We just did it page by page, clean sweep on each page, all new work done on a fresh slate with the old code base being abandoned page by page but otherwise left alone until all the pages were migrated at which point we could just completely drop the old code base. We’re so much more productive now and happy working on the code base. Refactors are much easier than before as well.
I’ve worked on massive jQuery code bases before and they turn into worthless spaghetti code in no time at all. Dynamically altering html with no source of truth is the worst pattern you could have on a frontend. I have a ton of respect for what the jQuery library introduced but it was never a framework and was used in a terrible patchwork way. I wouldn’t even bother trying to save any of it. Clean split and keep that codebase tightly quarantined behind lock and key and don’t let it even touch the new code base. The spaghetti code it creates is like a virus.
Yeah that would be great to do but we are very underresourced so the technical debt just keeps building up.
I stepped out of webdev like 5 years ago. Now every time I try to get back into things to work on an open source project or whatever I just give up because I do not understand things.
Everything seems to be based on React which is some kind of magic templating library that does everything? And also dynamically updates thing in response to changes and talks to the server?
I much prefer the days of just using vanilla js to manipulate a DOM and talk to a well defined API.
I’m sorry but framework and library in this post are going to be used loosely, because even React, Vue, Angular, Svelte, etc devs use the terms loosely.
React is mostly a UI library like you would find in most native app development. Of them all them JS frameworks/libraries is one of the less opinionated and with less batteries included. By design it does not does everything. Most other frameworks do way more.
It lets you define custom components. The components can have properties that their parent component defines and internal state. If the state or the properties change the component gets redrawn (magically). There are some lifetime functionalities (things to do on first render for example) and performance improving stuff (memoization) but mostly that’s it.
All the other features you talk about are third party libraries or frameworks that can operate with react or are build on top of and cover the bases, like routing, fetching, caches, server side rendering, styling utility libraries, component libraries, animation libraries, global state management, etc.
The big difference with the vanilla way is that the approach is mostly declarative. The runtime takes charge of updating the DOM when your components state or properties change.
You take a big performance hit, and an even bigger bundle size one, but the speed of development and huge ecosystem of readymade solutions can be really important for some use cases.
Other frameworks take different approaches to solve the same problems:
- Component system for code reuse and organization.
- Some way to manage state
- Some way to decide what to re-render and when.
- Extra stuff. Some frameworks end here, some have tools for everything you would need for a web app.
Great article. there was a even a response a year later https://medium.com/front-end-weekly/how-it-feels-to-learn-javascript-in-2017-a934b801fbe
That second article is hilarious. It’s trying to point out that the first article is over complicating things then doing the same thing except the author thinks it’s not complicated what they’re saying when it’s actually insane.
I learned JavaScript waaaay back when from this book. I used to carry that around in my rucksack at high school :-\
That worked out well - one copy in stock for £4.05. I’ve been trying to learn JavaScript for a while, so thanks for the recommendation :)
Ohh, I don’t know if I would recommend it in this day and age, it’s very basic and over 20 years old haha!
Ah, for £4 it’s worth a look 🙈😁
My god it just keeps going.