In his recent article, Josh Comeau predicts AI won’t overtake frontend development (at least not soon). I agree, but something else Mr. Comeau wrot...
For further actions, you may consider blocking this person and/or reporting abuse
The main reason JS frameworks are prevalent is because they are filling a gap left open by sluggish development of web standards and even slower adoption of them by browser vendors or their understandable unwillingness to look beyond their own problem space.
Web Components are cool as a technology, but also complex and cumbersome. They have no native server-side rendering and need a lot of boilerplate to set up.
On the other hand, frameworks are moving fast. Between the request for simple signals in Angular and their implementation were only a few months. Some developments are measured in weeks rather than years – and you don't need to wait for browser companies to adopt the changes. Frameworks won't ever become a thing of the past: there will always be new gaps.
But you're right, a lot of the larger frameworks are mostly aimed at developers with their claims "do more in less time" meaning development speed rather than the performance for the end user. Luckily, some of the newer frameworks make less compromises when it comes to end user experience to achieve a worthwhile DX. Especially solid.js, Astro and qwik aim to deliver less JS to improve performance. Other frameworks, like preact and Angular have taken up signals as a way to increase performance. Just the react devs don't want to break their dogma of immutable state, even though it's shown not to scale well.
Well, maybe that's one thing that could be a thing of the past at some point.
Agree with all of that. Just had an additional point.
Performance for me is often not how fast the front end renders - who cares, if it's fast enough on the target hardware then no one really cares if it could be faster; if it isn't then there's a problem for sure - so this kind of performance metric is app specific. In my apps performance is probably down to the size of the code and the ease with which it can be split apart - I can't predict the network speed with anywhere near the same accuracy as I can the other specifications in the my user community.
I'm building a new platform for a niche in the b2b space; so for me the most important thing I can do is get software in front of my users and iterate on complex requirements, frameworks help me do that, and help me do that better with several teams contributing to the same code based effectively, due to an IoC architecture for which I would have had to build a framework myself, if I hadn't co-opted React.
Maybe your target is wrong. If you only target top-tier hardware less than two years old, you may lose customers.
Also, it's not nice to drain your users' batteries if they're on their mobile browsers.
You're just driving my point about speed of development over speed of user home for me.
A large part of this is the ecosystem. The react ecosystem is in a strange state right now. Many packages are orphaned, some even no longer support the newest react versions. New packages have varying quality and maintenance. At the same time, established devs like TanStack are becoming more framework-agnostic.
I don't know which one you mean, but there are several framework-agnostic options that play well with the newer frameworks.
My target is fine. It's my target market, well known and understood. Our app is mostly running on a laptop, the mobile version would infrequently be used during a day, and does not drain battery life to any level that has ever caused a comment, let alone a loss of a sale. My users reduce massive costs in their organisation, keep people safe and stay out of jail by using our software and content - better I improve that quickly than get stuck on a detail about how some other framework would save me some small amount of battery life, which is clearly negligible.
I don't rely on a 3rd party framework, beyond React. The IoC framework we use could be implemented on Solid, Vue, Svelte or whatever, we chose React. We have a balanced DX to UX that works for us. It seems you wanted to jump to a conclusion about this, I didn't mention it at all, I wonder why that is?
In our market, and for our customers, our ability to quickly implement features and adapt to changes in the law and the environment is much more important than low level performance improvements - they simply don't pose a challenge for us in our current situation.
Just to satiate my curiosity: how do you measure lost sale?
Congratulations.
I explicitly wrote that I did not know about your solution, so which conclusion do you mean I jumped to?
That being said, you seem to work under the assumption that other frameworks would have better performance at the expense of worse DX or slower development. This is not necessarily the case.
An interesting discussion topic. For clarity, do you mean ES5 when you say vanilla JS (for maximum compatibility)? And do you have all JS in a single file?
I'm ok with ES5.
I think it comes down to where the differentiation between website and web-app lies, as you mentioned.
I've hand built several all-in-one (i.e. JS+CSS in a single HTML file) mini interactive ES5 web pages before (that support IE11), including using d3. It's possible, but I would have preferred a bit more infrastructure to help. For example, using
findon a array is so much simpler than having to write an ES5-compatibleforloop that does the same thing.A colleague I once knew built something similar that ended up near ~10,000 lines long and was a nightmare to debug.
But for simpler sites, yes - I agree with your point of view.
FYI FrontendMasters.com doesn’t use a framework. We use Hugo/Go for templating and vanilla JS on top. The website is incredibly fast as a result.
I’ve documented some patterns here: github.com/1Marc/modern-todomvc-va...
For a few larger dynamic components, we started using lit-html for rendering. There’s an example branch in the repo.
If you are building a portfolio website, just use Vanilla JS, but if you are building an enterprise project like a front end CMS, with a team of 20 Devs, then an opinionated approach is your friend. I spent 15 years using Vanilla JS & resisted frameworks, until I could no longer get a job. I spent a few years learning Angular & React. I tend to do more Angular contracts now, but I am never out of work. I love learning more about topics like TypeScript and state management [NgRx]. And I believe I am now a better team player, because of these frameworks.
It would be practically much harder to create an enterprise project with a large team, using Vanilla Js, although it is not impossible with the correct amount of preparation & planning.
I remember marvelling at the HighCharts code base, which was done using Vanilla JS, and classes. Similarly, TinyMCE is another great example of a Vanilla JS project, that is incredibly well organised.
My feeling, is use a mixture of approaches, depending on the requirements.
May I will try fork my: jsDoc/React app without using any JS framework. I have idea. Without any compile system, but still using jsDoc.
always js with framework, practicality is everything.