We all want our sites to look attractive and feel fast and responsive across a multitude of devices and screen sizes. There are common tools develo...
For further actions, you may consider blocking this person and/or reporting abuse
The right tool for the job you say… but how do you know what your job will be in the next five years?
Say you start with HTMX, at which point do yo decide to switch to another framework because you can't manage state anymore or you don't have the right library? Those decision are often hard to anticipate, tend be postponed until it's too late, they involve heated discussions etc. It's not like you can migrate a codebase to a new framework just like that.
The reason why React (and to a lesser extend Vue, Svelte etc.) are so popular is because they respect a golden API design paradigm:
Simple things are super simple in HTMX. Harder ones might not be possible at all. Yes there is a tooling tradeoff when you start with React, but simple things are still simple, while scaling to much harder thing is possible. You know you're unlikely to get stuck, whatever your "future" is.
That's a really good point. You can't really say for sure what the job would be in the next five years, but you can make some educated guesses depending on the type of project you are building, and how much client-side interactivity you are anticipating.
I've seen many a NextJs project get deprecated overtime, when all it really needed to be is a simple static page hosted somewhere. I would happily have kept these 'simple', and spend time migrating a project that that really can take advantage of the strengths of of React, Vue, etc, when/if that scenario arises.
It's about finding a balance. Do you start from an index.html file, or a fullstack NextJs app deployed in a k8s cluster and all the bells and whistles? It's a good practice to sit down, think about it and be aware of your options.
You guys are stuck with abstracted bs, you don't even know what your own code does. Over 300 packages for a normal nextjs project. Really Bro ? Just because you like this GOLDEN API DESIGN PARADIGM ?
Do you have any idea how your memory is managed ? Can you even keep up with all these dependencies ? do you know what each of them do ? This is all confusing to me. These cooperation are building tools to aid their development and not yours. You think it'll fit your future but it doesn't. Features are already provided to you, you don't chose them buddy, Companies get behind these frameworks, what happens is you end up embracing frameworks so much you forget design patterns and end up stuck with frameworks. Your thought process is based on the frameworks design, not your design.
Keep things simple, if it needs to get complicated, do it your self. Take HTMX for example, if you can't manage state without a library, are you even a developer ? that's a skill issue bro. When something gets hard the option is to look for someone elses work ? Is that how programming works ?
I mean look what happened since ES6, do you really think what happened from 2019 to 2024 was the future ? Developers have adopted tiktok brains nowadays. Every problem they come accross has a library or framework nowadays. Good luck!
The Article highlights what's actually wrong with the industry. It's a solid article and points out exactly why you should use the right tool, choosing the right tool for the job requires RESEARCH, Research on what the job exactly needs you to do. Love the article.
Cudos to the writer
So you don't use any framework? You mutate your UI with Basic dom api?
Why not?
Isn't that what React is doing?
I guess if you like it there's no problem with that, doesn't matter what react does, also c++ compiler do compile in assembly but we don't write in assembly for that reason.
Personally for as much I use the Dom api and try not to abuse frameworks to do stuff that is not even ergonomic with frameworks I would never ever work in a project with vanilla Js or jQuery, I did my time on that kind of stuff and any framework even AngularJS is better both in terms of velocity you get and it being much easier to organize your code and keep a fucking value in sync with the UI.
Hard things are possible in HTMX, you just use JS without a framework in addition to it. The point is, not everything needs to be done by JS, JS is a tool for enhancing web content.
Great post
There are constantly new libraries being released, and many developers are eager to try them out or incorporate them into their upcoming projects. I prefer to keep things simple by minimizing the number of NPM dependencies and writing custom JavaScript code whenever possible. For server-side rendering (SSR), we rely solely on Node.js and do not depend on any additional frameworks or libraries. The more NPMs you add to your project, the more potential issues and challenges you may face in terms of management and upgrades.
When you begin to scale and have competition that has out-scaled you, you might begin to have a rethink on this approach lol.
Opensource libraries are necessary evils, we just need to choose the least evil among them.
But going full inventor mode on projects that are production facing is a recipe for disaster.
I totally agree that NPMs are the necessary evil. We just don't pick any library, we pick that makes sense and has good community support, lesser GitHub open defects, good stars and downloads.
"Avoid premature abstractions, try sticking to web standards and don't scale to the moon."
Yeeeeeah!
Yeah! These kinds of things can feel clever in the moment. I think it takes experience to know where abstractions are worth while, and where they are just going go make things more complicated for you (or your peers) in the future. I'm still learning all the time.
Great post! But you are talking about dependencies, what about inconsistencies? Each tool has it's own special concept that you need to learn? And a documentation that is not always up to date? This is also part of the developers experience.
Thank you! Yes it's a good point. I had written something about this when mentioning abstractions on abstractions. The more abstractions there are, the more framework specific concepts you need to learn and a DSL is born. In the end I left this out, as maybe the 'hidden cost' over time is more related to how often these concepts break or change. There are some great examples of this (e.g. AngularJs > Angular), but others like React have remained true and a component written in 2016 would still work today, so I decided to exclude it for brevity.
Regarding documentation, my personal experience has been positive. It's almost like libraries use their documentation as marketing material, in making it attractive and approachable. My only negative experience is finding deprecated documentation while Googling... which to be fair is annoying, especially if it's not clearly marked as deprecated. Perhaps I could have touched on this in the article, thanks for the thought!
I suppose, things are a bit different for professionals, as - at least for some time - they can ignore the progress and just keep what they are used to. There are more than enough companies that earn good money using their old PHP-toolkits or Typo3. But for a newcomer, learning can be the biggest pain point. Often you find documentation that applies to older versions of a package. If you do not know, that a tool is outdated (or even in a per-beta-state), you can easily get lost. This can be extremely time consuming, and as we know - time is money!
As a C++-programmer, you will most likely update your tools frequently, but you do not get any package that introduces a completely new language with the next update.
"developer experience over time"
This should be a focus in tech discussions more often! Great article!
Absolutely! It's like buying a new car. Everything can be shiny and clean at the start, but you should really be thinking if it's the right car for your needs and with some miles on the clock.
As an Angular Dev, since it’s birth, in 2016, I must say I really enjoyed the experience of using Remix, recently, for a mini Shopify project.
Now thankfully, I have quite a bit of React experience, which helped with the Remix syntax.
But, it was really refreshing, to experience a new paradigm.
Remix allows us to write client side & server side code on a single page. Remix includes two server side utility methods called loader() & action(). The former pulls records from the database, when the page loads and the latter handles form data and submits it back to the database.
Anyway, enough of the details, but it is kind of cool being able to use both client & server side code, in the same place.
And it was good to be able to compare another framework with Angular, which is quite verbose & opionated [not a criticism, by the way].
I would say, that if you plan to do a small app that isn’t going to scale much and only involves a one person team [yourself], then don’t use a framework. Just use JS/HTML/CSS or even just a server side language like Coldfusion or PHP, that are compiled at runtime.
If on the other hand, you plan to build a big enterprise project that will scale, with a large team, then a framework is an absolute requirement. Frameworks allow us to work well, in teams, because opinionation helps us to understand how to write code in the same way, with the same methodology. Plus, frameworks like React & Angular, have first class documentation, which is vital, when working in a large team, with members that might differ, in skill level & experience.
Anyway, great article.
Thanks! I love your summary. And your point...
I think this is hitting the nail on the head of the biggest advantage FE frameworks in the JS ecosystem have to offer. It's just a shame that this then locks us into using Javascript (since it is the only language in the client), which is why I'm finding low JS alternatives like HTMX and Alpine so intriguing.
Really love the mention of HTMX. But no Astr? It's the new kid but it's simplistic and powerful. Also you can use components from your favorite frameworks. Here's an article on a nice template that uses it.
dev.to/dansasser/supercharge-your-...
Hey thank you! Yes, I love Astro and I use it for my side projects. I was in two minds whether to mention it in the article. In my eyes it's solving a different problem space to client side driven frontend frameworks I mentioned, though I feel it still does suffer from the hidden costs highlighted in the article, so perhaps I should have included it anyways.
I'm currently working on an article documenting my experience of building an Astro 'light' project in Go. My thought being, if you wanted to build a static site but you don't need to integrate with a UI framework like React, how simple could it be if you don't need to use Javascript.
Thank you for the thought, and congratulations on the nice article!
I completely agree with the idea that convenience doesn't always equate to simplicity. As someone who's spent a fair amount of time maintaining older projects, I've experienced firsthand how quickly dependencies can pile up and turn into a nightmare to manage. While the rapid setup and hot reloading are great for quick development, the long-term costs in terms of maintenance and updates can be overwhelming. It’s a good reminder to critically assess our tool choices based on the project’s actual needs rather than just following trends or opting for the most popular framework.
Absolutely. The advantages that an older project has is you can see the trend of the project and its needs. Has it not changed in years? Does it need to be an SPA? Is there much client-side state? It could be worthwhile, cheaper and a time saving exercise in the longterm to assess if it's viable to refactor to something that requires less maintenance and better suits the projects requirements (that are now well known).
Great post, the hidden cost of dx is scary if we are just installed without knowing the "cost"
"It is very difficult to make predictions, especially about the future."
-- Neils Bohr
I fully agree with every word in this post. Unfortunately, nothing changes on my end -- front, as well back IYKWIM Lol
All I have (though!) is a very well-articulated re-confirmation of a problem that has existed, nor is going away anytime soon. Sigh.
Love the quote. Stay hopeful, there is a lot going on in the low-js space, like the resurgence of MPA's, HTMX, AlpineJS etc. I have more articles lined up in this space to come that I'm working on.
If I DIY, I will end up debugging my code. If I use a framework, I will end up debugging not only my code but also the framework. Because I code the way that works for me. Inevitably I will inject something into the framework that the framework didn't anticipate, and have to dig into the framework because frameworks are written for performance, not to help developers figure out why the framework chokes. (Alas, I have tried writing a framework from scratch and had my effort canceled by my boss.)
Good points and articles; frameworks are just abstractions of layers of abstractions, but that's a part-time job to maintain everything. That's why I am now building my project with the minimum dependencies possible, hopefully with none.
Thank you! That sounds very interesting - carbone.io/? I'm curious how you will go about it!
Just mind blowing, I just started to learn react, and this is the reminder and a answer to.my own question that we are just using a library or framework from top view, but they have to do nearly same as what we do in normal js/ts, and adding too many frameworks to a project is a nightmare, and so many things I had to imagine/guess (cause i just started learning and new in all), but still this article was 👍
Thank you! I wish you luck learning React, it's a really valuable tool to have on your belt. I just wanted to write this article to highlight some of the cons that I feel are not fairly represented in the marketing hype.
Funny thing is that all mentioned frameworks are still years behind the ones already developed in other languages. And to my knowledge most pf these new frameworks are greatly overrated in terms of what they are capable of doing on middle to large projects.
Great article. I'm looking to build a data intensive(100s of thousands rows in total) dashboard application with filter tables and many charts/graphs that are user interactive and real time update from database, or some other source.
Kindly suggest which approach is better for long term.
Thanks!. You know your requirements best, but going on what you said, that sounds like it could be an ideal fit for a FE framework like NextJS, SolidStart, SvelteKit, etc.
Excellent and I totally agree!
Glad you liked it, thanks for the feedback!
Checkout primatejs.com -- they solved the vendor-lockin problem.
Hey thanks, I had not come across this. It's an interesting take.
Where is Angular, my beloved?
Please forgive me, Angular.
Your conclusion is like mine, but...
This is the path trodden by the evolution.
When the real best solution emerges, the one path will become reality.
Thank for sharing
Thank you for sharing good news
Excellent article. I'm just missing you didn't mention vanilla Javascript. Is that not a recommended platform?
Thank you! I intentionally didn't recommend any specific solutions or platforms, as the answer is always dependent on your use case.
That being said, if your project is written in Javascript, it's always nice to write vanilla JS where it makes sense to do so. You know it isn't going to go out of date, until the product requirements change!
Something I needed to read. Thank you! :)
ty
You cant argue with this quote
Absolutely, I went out of job 5 months ago and decided to give a try to react type of projects. So, I built something that was well defined in my head as per the features required. (I had built the same in PHP twice in my career)
The experience was indeed very hopeful when after 3 months, I had something working fully. But then, I realised that moving to nextjs was a good move and I did.
What has been my hardest dilemma was: I had built something in 3 months that would have taken more with php frameworks. And yet, all that was to come with hosting, migrating one layer after the other have certainly showed that you are precisely on point with a side-effect with these technologies.
great writing, thanks
Could you please provide real examples? It seems this is a vague confirmation to me.
Yes node_modules. Many memes exist about it, but... It works and it works pretty well. It's also important to realize that a lot of the modules that are installed are for the dev experience (dev dependencies) and will not be bundeled in the production version of the app (see npm prune). So you see... Its not a trade off at all. You get great developer experience and it will have no effect on your production bundle 🙂 (except if you update your actual bundler or build tool maybe)
There are also tools for updating your dependencies, like dependabot for example.
The article is focusing on the drawbacks of having so many dependencies (including dev dependencies). Yes, dev dependencies don't make it into a production bundle, but you are still building your project on top of dependencies, of dependencies and dependencies - and this does have a cost (see 'Keeping up with dependencies' section, also mentioned
dependabothere), as well as when things break (thinkleft-pad,everything).It's not to say it doesn't work, but it is to raise awareness of the trade offs when depending on so many dependencies.
You explained very well
At Elanat, we created a modern framework that overcomes the weaknesses of front-end frameworks.
The article is available at the following link:
dev.to/elanatframework/webformjs-l...
LAMP... and job security for the next five years, no problemo lol.
This article seems incomplete to me so what is the final takeaway or will you suggest to use some framework that will simply the work i think react is widely popular and less pre built in packages
Thanks for your feedback. It's difficult to have an ultimate final takeaway, but I do think "use the right tool for the job" and not just reach for a 'default' FE framework is a good practice right now. I have more articles coming in this space to explore alternatives, when you don't need something as big and feature rich as NextJS, SolidStart, etc.