Web dev is still fun if you want it to be
93 jacques_chester 91 5/31/2025, 6:23:24 AM github.com ↗
I wrote a silly toy website and went out of my way to enjoy it, rather than endure it.
I wrote up my thoughts. Maybe they'll resonate with you. Maybe they'll infuriate you. As long as they make you feel something more than a cosmic shrug I'll be pleased.
The joy came flooding back to me! It turns out browser APIs are really good now.
You don't even need jQuery to paper over the gaps any more - use document.querySelectorAll() and fetch() directly and see how much value you can build with a few dozen lines of code.
All of these things except Next.js are over 10 years old now (Next is 8). What makes you think they'll be out of date next year?
In JavaScript, it is not. So you claiming 10 years as a time frame in your response is in bad faith, because you certainly know that code written 10 years ago is 100% incompatible with the modern versions of the same frameworks.
Sorry to hear your situation but I found there's hardly any point in debating with your team on moving towards simplicity - just better to keep your head down and take that paycheck every 2 weeks.
My goal is to build a microstartup with a small team - and for that I am definitely going to choose the traditional JQuery/HTMX/Turbo setup with a server that renders templates. To hell with React.
This leads me to question why people still use jQuery instead of native JavaScript. From my understanding, jQuery primarily serves as a polyfill. So why jQuery and not native Javascript?
Not even a shared API management service — dedicated to the app!
It’s insanity.
Most cases because it is not worth the refactoring to remove jQuery and in a few cases when it is in new project is because the person coding doesn't know to code without it.
Case in point: this site versus Reddit. HN is 100x snappier. Just a few lines of un-minified plain JS. Reddit crashes the browser on my iPad
Embrace the cascade - check out ITCSS methodology.
Fluid typography and spacing - https://utopia.fyi
It is a similar sort of confusion that comes from people thinking React is a Web framework. It’s actually a small library.
I know it's an unpopular opinion (and the React people swear it's not true) but React is absolutely a framework, not a library!
Adding React to a project fundamentally changes how that project is architected, and affects almost all of the code written for that project going forward.
Trying to use it just as a library very much goes against the grain of how it is commonly used.
However, the frontend build systems are often complex to do complex state management. Sure, it's possible to reimplement it all and accidentally end up rewriting your own vanilla JS frontend framework, but beyond a point, that's equally as unfun as modern webdev.
It's not hard to shift the state management though, and when I find myself sat with a nice architecture that's formed without a complex frontend system, and with some really simple, uncluttered backend that could probably serve millions of requests a day from a homeserver and internet connection.... it gives me a profound feeling. It's a satisfying and familiar feeling from webdev I enjoyed around 2 decades ago as a teen. It feels like the old way of doing it.
Now, having designed, built and run systems from on-prem, through VPS & VMs onto serverless and static site stuff, doing it the old way again just feels better overall. Maybe it's nostalgia.
But then I feel the reason why we moved away from doing it the old way was because the complexity of the applications needed more efficient ways to make use of relatively limited bandwidth, storage and compute resources at the time. Now these things are all commoditised, and my home desktop and internet connection now has probably the same capabilities as a small datacentre back then... the dreamer in me wants to believe there's no reason why we can't all go back to the old ways of doing it now.
Not sure I fully understand the second bit. Given how much more powerful servers are now (both physical and abstracted) doesn't that vertical scaling mean horizontal scaling is less necessary? If horizontal scaling is necessary, depending on where in the stack you're scaling, the global consistency offered by modern cloud data stores make it more efficient than ever for lots of servers to exchange a session cookie for state and return fully rendered HTML.
..but then they kept adding. And adding. And adding. And adding.. and now where are we? Death by a thousand cuts. 10x the complexity for an additional 7% benefit
I recall working on systems where the frontend and backend lacked clear separation, such as through an API layer, and there were no defined contracts outlining these boundaries between different teams or disciplines. This often led to significant challenges and disorganization, necessitating numerous compromises, not just in UX and UI.
Such issues typically arise in projects involving many people and disciplines. Fortunately, libraries like React and frameworks like Next.js have significantly reduced this chaos by facilitating the development of a decoupled frontend and backend.
This was 10 or 15 years ago. Now, with a decoupled front-end and middleware/backend, it's much easier to refactor or even replace services and features. Additionally, it's much easier to integrate new teams and technologies.
I agreed it makes it harder in places. Like when I (as a be dev) have to write JS hooks, or the JS dev's on the team have to interact with the database.
I find I'd rather code in a RESTfull code base than a socket system. I miss the lines.
Here's a random example: https://dev.to/ingosteinke/using-jsdoc-to-write-better-javas...
I usually don't make a SPA though, only using it for specific parts (with their own entry file).
Many big companies and startups blindly jump into the React/Vue/Angular stack, along with other complexities like Vite, Webpack, SSR, Zzzzzzzz... etc, where things are tied so loosely with 100s of dependencies and with a fragile underlying platform such as NPM. The output produced is only very marginally different from what could be achieved by the traditional MVC frameworks like Django/Rails/Phoenix etc. What do we lose here? a breathtaking amount of productivity and time. In addition, all the complex layers brought in place to make React FEs work with the backend such as GraphQL etc, also only increase the number of places you will have to maintain.
With SPA and all the modern snake oil like "serverless", engineers only will have to make changes at several places and implement some extra adapter logic, and spend a lot more time writing crap, than actually getting things out the door. With something as simple as JQuery which still holds its ground today, coupled with helper libraries like HTMX, Stimulus/Turbo, you can replicate 90% of the SPA experience, and ship things insanely fast, and maintain logic and state only on the backend. Your user only cares about seeing new features and existing features being easy to use. They don't give a fuck about whether you're using React or plain JavaScript or JQuery at the end of the day.
Absolutely! However, I believe users aren't the issue. Hiring managers, HR, etc. absolutely give a fuck about whether you're using React or plain JS.
I have a friend that is a recruiter for a moderately sized company. She said that when they were looking for a frontend developer, if one's resume listed Angular and not React, then your resume was instantly thrown away. Not even a second of consideration was given.
I am not sure how common that is within the industry as a whole, but it wouldn't surprise me if it's quite common. It's shit like this that makes me absolutely hate our industry. I love programming, but I am really beginning to hate doing it for an occupation.
I come from the old school way too. I still publish applications in 2025 with just plain HTML, CSS, JS, and .Net backend. Nothing fancy. However, I am feeling compelled to learn React (against my will) sheerly for job prospects. My users nor my employer would benefit from React, but I've been considering using it sheerly for 'Resume Drive Development.'
Small companies are great - but in the general job market, when you propose an idea that is not inline with the higher ups in the company, it quickly becomes a matter of ego and hate, even if it is the right idea.
Instead, you can adopt 2025 standards, including Web Components, JavaScript and CSS modules, and modern JavaScript (ECMAScript 2022, also known as ES13, and even ES15). Additionally, CSS Level 3 features such as variables and container queries, along with WCAG 2.2 guidelines, are all widely supported by the latest browsers.
Web Components definitely have their thorns, as well as the shadow DOM. They're still a lot more capable than people give them credit for. Nested CSS has also been great, but I still reach for SCSS because nested CSS is still missing a few syntactical goodies. However, LLMs really bridge the gap and allow me to quickly write decent small web components without worrying too much about the internals.
For web components, I utilize Lit for its syntactic sugar and because I appreciate the decorator approach. Since browser compatibility is typically not an issue in these projects, I leverage native CSS 3 features and avoid using SCSS as a polyfill for nesting, variables, and maintaining DRY principles.
I haven't heard of Mithril before. Thanks for sharing!
This is always true for any web project. HTMX is an abomination of opinions that are harmful to both small and large scale projects. It attempts to solve problems (poorly and naively) in the mid scale that almost nobody ever spends much time in. It's a toy for inexperienced managers to create bullshit maintenance work while they try to quickly jump to something else. We need to stop making crap like this and focus on coding according to web standards and sparingly add much better tools as the project scales up.
Lasted for a year until we had users wanting to do complex interactions on the frontend.
Simple CRUD apps are fine, but users expect a lot of interactivity these days where things on the screen interact with each other.
The nice thing about Django, though, is that you can easily switch to api-based backend with DRF or Django-Ninja. We used DRF but if I were to do it again, I'd choose ninja.
React, not so much fun
I keep seeing the same point that argues against how "not fun, depressing, worse a <thing> has gotten these days". The most recent incarnation of that is how programming with AI feels worse than programming on your own.
I don't think the problem is inability to find a way to derive fun, the way you could previously. The problem is deriving fun while still getting paid for it.
To reiterate on the web-dev, you probably can make it fun again, given that you were able to have fun with it previously. But it probably will have to be done in your spare time after job.
I started out with Server Side Includes on a shared host, but converted to using PHP along the way to be able to make a base file with all the stuff that is repeated (header, main, footer etc), and then injecting the content from index.php, /contact/index.php etc.
Turns out, you get really far with HTML, CSS and a light sprinkle of PHP, and it is super fun and fast and you get things EXACTLY how you want it. No fighting other peoples opinionated decisions.
I have created many sites from scratch with Hugo, and generally enjoy the process, but this is even more fun, because ... I can do whatever I want!
I have a static file download only webapp[1], and I managed to get the includes done with only a 99-line JS component.
Honestly, once you get a decent way to specify, in HTML tags, include files, a significant portion of what you use a framework for (DRY) becomes redundant.
[1] Dynamic data to hydrate elements on the page is via API-only URLs.
Being able to super quickly iterate, without caring too much about the results, but having fun seeing what comes up
I’ve really enjoyed exploring. Making small experiments, that you can make 5-10 of easily of in just one session
Like these silly things:
* https://openjam.ai/lonely_ant_702/vnqovd512h
* https://openjam.ai/stupid_coral_852/pvjda0dyc2
* https://openjam.ai/stupid_coral_852/qg8yembjg5
PHP, ASP.NET or Spring/Quarkus, with just enough JavaScript, no npm, no builders, nothing.
Likewise with WebGL or WebGPU, direct src includes, no build.
All of my web resources have code like:
Form submissions are super trivial to work with too. Covers 99% of my use cases. Every time I think I need something like web sockets, I can usually wiggle my way out of it with some kind of rearranging of the problem.But 0s feedback loops from the likes of PHP and Bun+TypeScript spoiled me.
It's like a drug I can't get enough of.
Yes, some of them have a case for local-first. If you do, you really should start with that out of the gate though.
Worse still are sites that require JavaScript to read them.
Form validation probably should have also been done via child tags, not attributes, so that error messages could be independently associated to each validation rule.
This also means that your application will work the same with JS disabled as it does with JS enabled.
Here's a somewhat convoluted explanation of the general approach: https://fex-template.fly.dev - it happens to use F# with the Fable compiler but it should be somewhat legible to most developers!
Hardly a ringing endorsement there!
Apparently even saying "I tried AI and it was somewhat OK" is enough to summon the anti-AI comments.
Tailwind is the key. It provides a semantic layer over CSS that LLMs can actually reason about. Otherwise it's just guessing.
No comments yet
Often I find that the common web app needs nothing more than a few dozen helper js functions.
I haven’t been working on any sort of crazy features with elements moving around the page or excessive Ajax components (do they still call it that!?). On the other hand, most sites don’t have these features.
I agree. A framework forces a shared consensus on how to solve a particular set of problems.
A single competent engineer on their own can make that consensus themselves. If the system is larger than a single competent engineer can manage, it seems intuitive that a small handful of engineers who are familiar with working with each other are less dependent on a framework for shared consensus.