Web dev is still fun if you want it to be
113 comments
·May 31, 2025simonw
If you've found web development frustrating over the past 5-10 years, here's something that worked great for me: give yourself permission to avoid any form of frontend build system (so no npm/React/TypeScript/JSX/Babel/etc) and code in HTML and JavaScript like it's 2009.
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.
icameron
I absolutely completely agree and do this myself. Unfortunately all of my peers and bosses don’t see the value, and the shop is overrun with trend chasing resume driven developers. React/node/next hosting on aws and containers and it will all be out of date next year. Everything we do has such low amount of users we don’t need anything but a single VPS and simple backend. Many of my apps from 10 years ago still run the same rails and jQuery just fine. Actually upgrading the rails versions and pulling out the jQuery dependencies is easy now too. It’s just so much simpler and works perfectly. But this is seen as detrimental to my career. It’s not appreciated. I sound like a dinosaur to the bosses and coworkers. But I enjoy it and my shit works fine. I’m saving so much time and hosting costs. Everything runs on a $40 VPS.
jonas21
> React/node/next hosting on aws and containers and it will all be out of date next year.
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?
cookiengineer
The point of your opponent's argument is that measured age should be an indicator of maturity and stability of frameworks and toolchains.
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.
hu3
Next.js keeps breaking code so there's that.
null
magic_hamster
You are right that you are being efficient and reasonable, but also you are right that you sound like a dinosaur. This is the same for people who cling to C as "this is all I need", possibly producing beautiful efficient code with no VMs or slow interpreters, at the cost of lower cooperation with their colleagues.
The bottom line is your choice of tools is also a social thing. Rejecting the mainstream tooling can be appreciated by some, confuse others, and sadly developers with lower self confidence might even see it as a form of insult.
lcnPylGDnU4H9OF
> You are right that you are being efficient and reasonable
Well, that’s all I needed to hear. What’s the point of not sounding old-fashioned when the new fashion is worse? Considering the social point, why not be more critical when the efficient and reasonable thing is derided by others as old-fashioned? Why not expect those people to update their world view?
princevegeta89
This is the case at many teams in almost all companies. One sad reality is people want to keep their jobs and so they tend to inflate stacks and codebases so much so that they can "keep working on things" for a long long time.
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.
exiguus
I understand your perspective. It's similar to AWS services like CloudFront, API Gateway, SQS, and Lambdas—all designed for a microservice architecture that may not be necessary if scaling isn't a priority. The same applies to frameworks and libraries such as Next.js, and even React, Vue, or Angular, in my opinion. Most products and companies are not on the scale of Netflix, Spotify, or Facebook.
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?
LtWorf
Good luck hiring people that will agree to that.
satvikpendem
Well you wouldn't do this in a company environment, this is for personal projects only.
AstroBen
Often this works out to a better user experience too
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
andrei_says_
Also CSS! CSS grid, :has(), custom properties and improved browser compatibility. CSS is an amazingly powerful and beautiful language.
Embrace the cascade - check out ITCSS methodology.
Fluid typography and spacing - https://utopia.fyi
simonw
That CSS Minecraft demo from last week was such a beautiful example of how much you can do with `:has()` these days: https://news.ycombinator.com/item?id=44100148
satvikpendem
Now get ready for if() coming soon, then we won't need JS at all, it'll all be Turing complete in HTML and CSS only.
jacques_chester
Grids! I knew I forgot something in my list. Updated.
john_the_writer
100%.. tailwinds is a trendy way of adding inline style. I mean it's literally a 1 to 1 translation in most cases. I miss when css was css.
perrygeo
HTML and Javascript (the vanilla kind, written right into <script> tags like a caveman) is still one of best ways to experiment with UIs. It's not sustainable or maintainable but why do you need those qualities in demo software? I still maintain that a competent developer should be able to bang out an HTML/JS demo faster than they can draw the same complex flow in Figma.
sadcodemonkey
Yes! I have to do front-end work occasionally but have been bad at staying on top of trends, so I would resort to jQuery if the requirements aren't super complex. Discovering querySelectorAll() and fetch() eliminated 75% of what I used jQuery for.
In the bad old days, there were a handful of canonical tutorials you used to learn the basics (HTML, CSS, JS) of web dev. Is there anything like that now that starts from those three technologies to build an understanding of web apps?
It seems like it could fill a real need for beginners who want to start by grasping the DNA of the web, so to speak, instead of the complex/sophisticated tools that are popular (not that there's anything wrong with that approach, if you need those skills for a job or project immediately).
1dom
I agree, modern browsers, CSS and JS can do so much now.
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.
Toritori12
Big part of why FE system are so complex now is because we moved a lot from BE to FE, especially state management. I dont think it is possible to get back to session cookies and keep the "infinite" horizontal scaling that modern BE have.
1dom
Yeah, that's what I was referring to mainly - frontend frameworks to help manage complex state in the browser. If you want complex state in the browser, using vanilla JS to do the same clientside state and rendering becomes tedious: it's easier and more fun to shift it back to the backend.
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.
AstroBen
I think it's more nuanced than that. The original React model of UI = f(state) is pretty simple and solved the state management issue. Building your UI with function composition isn't a massive jump in complexity
..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
exiguus
> 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.
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.
john_the_writer
That delineation is all but gone in some apps. Elixir liveview for instance, has not concept of front or backend. It's all socket, so there's no break.
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.
danenania
You can do state management easily enough with variables and a rerender function. React et al give you granular DOM updates for performance, but for a simple app it doesn't really matter.
midiguy
Tbh, I would be pretty frustrated developing any non-trivial frontend code without a type system. But I am interested to try dropping frameworks.
AlbinoDrought
For the projects I've written like this, I've been able to get by with simple JSDoc and an IDE that supports them.
Here's a random example: https://dev.to/ingosteinke/using-jsdoc-to-write-better-javas...
65
You can always compile your front end code from Typescript to Javascript with something like esbuild.
notyouraibot
The hate towards modern front end tooling such as React/TS/JSX is nothing but a phase. 10 years ago engineers were hating and raging against PHP, but today they want to bring PHP back and make it a fundamental part of their tooling? They hated writing plain old CSS but now they want it back instead of Tailwind? None of this hate is actually based on any engineering value, sure you can build a little dumb todo app in plain old HTML, CSS and JS and it will work flawlessly, and if that's your goal you better stick to that, React, Next, Webpack, Vite and all these other tools aren't built for that purpose. Its nothing but nostalgia and elitism.
lcnPylGDnU4H9OF
> sure you can build a little dumb todo app in plain old HTML, CSS and JS and it will work flawlessly
This is a weak argument. These technologies can be used along with a database for state persistence to make literally any website in existence. That’s before even mentioning that those three things are how React et al. even work in the first place. What is a React component if not a logical collection of HTML, JS, and CSS?
dontlaugh
Nobody wants PHP back, though.
mushufasa
I actually started my startup with this approach -- good old Django.
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.
number6
Yeah we do this. Ninja is great.
React, not so much fun
frankie_t
Sorry for writing something a bit tangential, I'm mostly replying to the heading not the content.
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.
vouaobrasil
Exactly. AI makes everything less fun because it turns what was once fun into an industry by its design.
satvikpendem
Not sure about that, I've had great fun vibe coding like another commenter said, as I can simply write what I want in English and see a result immediately. Of course, I'd never use this for production, but for prototyping, it's nice. This is the opposite of industry, as you state.
vouaobrasil
I'm not talking about short-term gains like you having fun, but long-term effects on the industry of programming. Of course technology always provides some short-term fun in terms of elevating activity to higher industry levels in the long run.
DamnInteresting
This is quite true. I like to build browser-based games, and it is much more fun and stimulating to write a lot of the bits in old-fashioned HTML+SCSS+Javascript. I still use libraries for tricky stuff, like handling audio playback, but it's not that hard to implement one's own drag-and-drop (for example), and it works very well. Plus, there is the added benefit of understanding how things work.
29ebJCyy
I know this is somewhat antithetical to this article, but I’ve gotten similar vibes recently from Astro. Yes, I had to relearn some stuff, but once your brain starts thinking the Astro way, it mostly just works and feels closer to rails (but with the ability to craft weird fun JS experiences) than any JS tool I’ve used since Rails 4.
bstsb
completely opposite experience from me. i loved the original idea but i just can't get into the code fences and server/client rendering, nextjs has a clearer separation of concerns for me
rsolva
I accidentally started having fun while wipping up a new website for a non-profit with relatively simple needs.
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!
lelanthran
> 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.
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.
nico
Personally, vibecoding has brought back a lot of the joy of coding
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
beakerbox
This is fun. I remixed this sci-fi black hole particle simulator by adding some sliders to adjust the particle movement. Amazing what a few prompts can do these days... https://openjam.ai/shocked_impala_852/jgoz80mge0/3
2OEH8eoCRo0
The recent vibe coding parlance confuses me. We have been vibe coding the whole time. If you write code before you have a design then you're vibe coding.
satvikpendem
That's not really the meaning as used currently, which is to use AI to create the application in its entirety, not bothering to look at the code at all.
scruple
I don't really have anything to add but I also recently spun up a Sinatra app for my personal use and I really had a lot of fun doing it. It was my first time using Ruby since 2022 when I left a Rails job, after having spent more than the previous decade primarily writing Ruby. I love the language and community so much but I don't have a professional use-case for it at my employer today, and I don't have a lot of free time in my personal life, so I just don't end up using it much. Thanks for sharing your thoughts here, I resonate with them a lot!
ofrzeta
"bring back Cloud Foundry"? It's not dead, afaik. Also there is Korifi, a project to bring the Cloudfoundry API to Kubernetes https://www.cloudfoundry.org/technology/korifi/
null
sublinear
> I even eschewed HTMX. I bought the book! It's great, it made me feel hopeful, I want to use it someday. But I just ... didn't need it.
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.
recursivedoubts
maybe check out fixi, our minimalist implementation of generalized hypermedia controls?
https://github.com/bigskysoftware/fixi
we are hopeful that w/the work of alex petro and the triptych project that we can get some of the core ideas of htmx into the HTML spec itself:
pjmlp
On hobby coding it is definitely fun as always.
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.
bob1029
AspNetCore w/ absolute minimal usage of the abstractions has been my favorite web development experience by miles. Things like MVC and *.cshtml are really powerful but I find basics like PHP-style string interpolation to be way more intuitive and ergonomic.
All of my web resources have code like:
httpContext.Response.WriteAsync(Layout(... inner HTML content ...));
hu3
I adore C# and .NET Core.
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.
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.