Ask HN: Is webdev getting complicated without results to show for it?

I think the problem is that basically none of these technologies are optimized for a solo developer. I remember deploying cool websites on simple LAMP servers in college a few months after learning to code. I had implemented so many things with just jQuery, sqlite, and php (sign on, media player, messaging) Then I was told I needed to learn a javascript framework and react, I started doing tutorials but never deployed anything. What a waste! I was having fun and deploying real apps.

I would say that the evolution of React has slowed down and build tools are in a state of consolidation. Compare development with the abandoned CRA to Vite.

I felt that way about front end end work when I got a FT job working on a React system about 5 years ago but now I don’t feel overwhelmed at all.

The way people talk about it is intimidating though. The average person who wants to make a modern blog should probably host it in Azure or AWS object storage with a generator like Hugo or Pelican. Hugo in particular is zero bullshit if you don’t need to customize it, it is just a simple binary that doesn’t require you to learn anything about go or how people resolve dependencies in go or go build systems. I picked Pelican because it is written in Python and I know I can make it do whatever I want. When I send people to

https://jamstack.org/generators/

It is like waving a red flag in front of a bull in terms of eliciting the reaction of feeling overwhelmed.

Some of it makes coding much faster, easier and safer in larger teams. Typescript massively increases velocity and code quality. React and other front end frameworks let teams do component-driven development and patterns like atomic design really neatly, which makes apps more consistent.

What that complexity is really buying is desktop-class web applications like Figma, Notion, and the like, and massively reducing the engineering costs of building products like those to the point where it’s way cheaper and easier to build a rich, complex web app that can run for anyone anywhere than it is to build desktop or mobile software with the platform-holders’ own APIs.

If you’re not doing one of those and are just doing a light crud app, then you probably want to use one of those desktop-class web apps like AirTable.

And if you want to make a static website, then we have some much better tooling you can opt into to make managing it and building it out faster, but it’s far from essential.

Sure, web apps 10 years ago looked and worked largely the same as current ones, but they were usually monolithic and custom mountains of JS which were difficult to write, deploy and maintain. Few organizations could deploy something like Gmail.

So a good chunk of this emerging complexity tries to improve web developer productivity (at the cost of stack complexity and fragility). It's the infamous indirection treadmill, laser focused on a single thing: overall productivity and fast delivery of the final product by low skilled employees.

There are people who are trying to strip away that complexity. FastHTML and HTMX are showing the direction of where the wind is blowing in my opinion.

Now the fact that it looks and feels almost like a new flavor of JSP is another matter. I think the HATEOAS model was tried tested and true and just needed a bit more refinement rather than the total overhaul that SPAs+JSON APIs brought in.

The external product is _marginal improvements_,

the internal product is _full employment_ along with a healthy dash of _intellectual pleasure_, though much of the latter is in rediscovery of principles and approaches which regularly recur as the pendulum swings. But pride of ownership and invention is strong human drive.

I dont know I think its largely settling down as the market acknowledges that both React and Typescript have won and as a result a lot of the complexity buzzwords you listed dont matter.

Were seeing bun's first party typescript support pave the way forward to remove the need/weight of bundlers and transpilers

Were also seeing Next.js (for better or worse) pave the way for SSR support in a way that comes naturally for React Devs.

Jamstack is a fading niche, specifically Gatsby (still useful for content sites, but Next.js can fill this role too)

Headless CMS will always be useful for content and is not a JS/SPA exclusive thing.

Serverless adapters is also very niche.

Also SPA's are here to stay, whether people want to accept this fact or not, there is functionality that is only enabled by an SPA architecture.

I'm currently using some of the latest popular stack, for a simple Web site that could've appeared almost the same 25 years ago[*], with static HTML and a little client-side JS. (And could've been implemented faster then, and would've operated much more efficiently.)

158 NPM packages already, and the page load requests are insane.

Two reasons I'm doing this monstrosity of an implementation anyway:

1. Resume-driven-development, on a personal/indie project.

2. Using the framework's interactive SSR just to make it harder for freeloaders (AI company scrapers, copy&paste developers) to copy the information or the implementation tricks.

[*] Except for a little flexbox "responsive" flowing, corner rounding (without kludges), and some fade transitions, none of which are necessary.

It's only getting complicated if you make it complicated. I work at a company using Ruby on Rails and everything is much simpler than on a previous job that had a full-JS stack. Rails + turbo is all you need.

I don't think it's real complexity.

I mostly do backend and ops. Usually, I never generate backend code with llms, I mostly use them to generate test cases and small helper functions, but each time I try to do complex stuff, even with low domain specific knowledge, llms do not help. Rubber ducking is my most recent use (thanks to a comment here) and is fine, making them still useful _enough_.

However, this week I had to do some front-end. I tried llms, once again thinking it would hurt me more than help me, but I was wrong. It can generate 100 good lines of good front-end (granted, mostly htmx) in 3 or 4 iterations. Useful, working stuff, not shit I have to spend hours debugging. I was helped by the fact that I already had an architecture and data models (worked on that yesterday), and it just had to generate forms and containers without real algorithm inside (well, and a FSM but I wrote it by myself, it was easier than try to explain it to a LLM. And it's fun to write).

[edit] forgot my point: I don't think front-end is really more complex than it was in 2014. It is more tedious, and use more tools, but also more streamlined and straightforward. My story about how llm fare is also about that: it seems really good at generating boilerplate/streamlined code, and front-end is mostly that. Also now I understand devs who say that llms took 50%+ of their workload, when before today I thought they were lying or not realising the lost time from using them.

I wonder if this is why most of my engagements over the last 5-10 years were teams that hired "senior only" engineers, whereas some ocean of HTML updates could be handled by any number of juniors, and also provide a needed training funnel to move people up in seniority.

I certainly don't appreciate the cognitive load a lot of my daily stuff takes. It used to be simpler, more direct, and more satisfying.

Our brains love new things. Whenever we see or experience something new, they release dopamine that makes us feel good. That’s why we enjoy keeping up with the latest news, events, or technology. It’s part of being human, and it won’t change.

With each new wave of technology, things improve, even if they look the same on the outside. For example, today’s huge online stores weren’t possible 10 or 15 years ago. Innovations, like better system design and separating different parts of a website’s function, made this possible. New frontend tools pushed content systems to be more focused on APIs, leading to headless CMS platforms (Contentful, Strapi, etc).

I believe the next big change will be about using less energy when browsing the web. This could lead to new tools, hosting technologies, or apps. While websites might still look similar, the experience will keep getting better in small, meaningful ways. Another cycle of improvement is just around the corner.

I am perplexed by SSR being lumped in with the rest of your examples as an approach that increases complexity.

If you work at a specific company then you could just focus on a narrow subset of tech that your company cares about, largely unaware of trends in any direction. I've seen a lot of people (probably the super-super majority) who have that relationship to work, although I personally don't like to talk tech to them for that very reason. For such people work is work and never fun, and that's why they never looked outside.

Anyways, tech doesn't have to be your hobby. You don't have to be aware of anything outside your company. You company could've bet on SPAs about a decade ago and you could still be on the set of solutions surrounding that, unaware that SSR even exists. That's the level of stress which you are contractually obligated to, and nothing more.

Although not every website or app needs all of these tools, they offer a much better User Experience (no page reload, better performance, etc.) and, even more importantly, a much better Developer Experience. The learning curve is a little bit more steep, but these tools drastically facilite the creation of large websites or apps. For example, we could not build very large ecommerce website with one single main.css file.

I can't draw a graph here, but imagine complexity as a line going much higher much faster relative to meager improvements as a whole with a barely-raising line (and on average weighted down by many individual cases where websites have gotten demonstrably worse).

It's a shame, because the actual web platform as defined by browser APIs has gotten hugely better just in the last few years. We rarely see any of those improvements taken advantage of in the wild though. It's a huge, huge bummer.

I’m writing PHP without any JS for personal projects like it’s 90s and it works and I’m enjoying it and I’m getting stuff done.

Yes! You mean Next.js app router caching :)

It becomes a little bit easier with Next.js 15 tho

If you can't wait or don't want to figure out the black box magix,I offer https://achromatic.dev which is basically all RSC, server actions and based on shadcn/ui.

Nothing like the time wasted on npm updates, usually with additional minutes to fix new issues after update.

Try Remix. Works amazingly well out of the box. Complexity is well managed and abstracted.

Yes.

TL;DR: Yes and it's creating "It's X and limited by Y, but it works" projects

In web front-end, the same pattern crops up repeatedly. Two examples:

* Elm[1]: It's brutally functional and limited by purity, but it works

* htmx[2]: It's grug-brained[3] and limited by that, but it works

I'll let others enumerate web frameworks. On desktop, software for uxn and Varvara[4] by Hundred Rabbits fits the same pattern:

* 64k of RAM and limited to 4 colors, but it works

* Created when Xcode was painful to install on a boat over pre-Starlink satellite internet

Who knew rage-quitting could be so productive? ¯\_(ツ)_/¯

[1]: https://elm-lang.org/

[2]: https://htmx.org/

[3]: Said to be by the HTMX creator: https://grugbrain.dev/

[4]: https://wiki.xxiivv.com/site/roms.html

Yeah it became a rocket science with high barrier of entry. Like DevOps.

I think part of it is bandwagoning, everyone jumping from one fashionable tool/framework to the next, doing so very quickly and repetitively from like 2018-2022 or thereabouts.

Thankfully it's slowed down somewhat since then, with the frontend industry mostly standardized around Next.js for big apps, Vite for sites that don't need much serverside rendering, or Astro for simple blogs.

As for whether there are results to show for it... well, now you have some pretty cool web apps like Figma, ClickUp, Felt, OpenSolar, Photopea, Codesandbox, etc. that actually use interactive clientside Javascript to its potential. That would've been more difficult with a server-only stack that renders and sends HTML over the wire, or with manual AJAX fetches. Is it possible? Yes, just harder to reason about -- and importantly -- harder to divide up across multiple developers or teams.

What Jamstacks (Javascript, API, Markup) are really good at is allowing a cleaner separation of concerns, where one team can work on the backend API and another can work on the user-facing frontend and a third can work on editorial content, all without stepping on each other's toes (but with frequent communications and collaboration).

Are they misused sometimes? Yes, often, I think. A lot of sites don't really need to be in Next.js or a Jamstack at all. Wordpress would've worked fine. Wix would've worked fine. Anything would've worked fine. But our industry chases trends, beginners are taught what's fashionable, and then when they're no longer beginners, they try to improve the tooling, eventually some of it gets good enough to start a new trend, and the cycle starts anew...

------

<Long rambling anecdote>

On a personal note, I think a part of it also might be the nostalgia of days past that weren't really all that simple. Maybe we just forget how complicated it used to be?

I started web dev back in the 90s, hand-coding HTML on a 28.8k modem before Javascript and CSS were invented.

My first full-time permanent job was as a full-stack PHP dev, where I had to manage not just the HTML and the PHP templates but also the bare Linux VM under it (this was before EC2 became really popular, so we still rented shared metal from a data center) and everything above it. I had to learn and implement every OS package, every daemon from redis to varnish to monit, every row in every database (we used MySQL for most things, Postgis for geo stuff, Filemaker for other things), every interop script with other parts of the business (sometimes in AppleScript, sometimes C#, sometimes a Bash script, sometimes some Excel macro), every SSL cert and DNS and SPF setting, every PHP and Varnish and Apache option, every MySQL and Redis clustering/slaving/failover setup... long before ever touching the HTML.

Then on the frontend side, we had to hand-code every basic JS interaction from the cart total calculator to every AJAX fetch from the database, all while screaming at the then-primitive CSS and trying to massage it to work correctly across Firefox, Chrome, IE, Safari and all of their rendering quirks and and CSS and CORS bugs, while juggling more complicated functionality across several versions of jQuery and a horrible matrix of JS features supported or not by different browsers, all while phones were beginning to become more and more important but best practices and standard UIs weren't fully developed yet.

I don't think there was anything simple about that stack. Every single layer of it had like a hundred different failure modes, all of which compounded exponentially with every other layer, and there were a lot of layers. When something went wrong, it was always my job to figure out where in that maze things went wrong. There wasn't really such a thing as a frontend or backend dev yet, you were just a web designer, and everything from the graphics to the code to the server was your responsibility, whether it's a GIF alpha transparency or SVG rendering issue or a cache invalidation bug.

Fast forward a decade or two, now the web landscape is very different, but a `npx create-next/astro/vite-app` will get you a functional local website in under a minute. Two or three clicks will deploy it to Vercel or Netlify in seconds. Databases can be similarly configured and deployed within a few seconds, if you need one. I can make an interactive dashboard in half an hour, polish it for another, and have it ready for users in half a day. That sort of productivity was never possible in the old days. Part of it is the growth of managed higher-abstraction services (i.e. they took the legacy clouds and built value-added abstractions over them to create things like Vercel, Netlify or even just DigitalOcean and Heroku), but the JS framework race did yield some useful (if messy) outputs too.

You can still make websites the old way if you prefer. But coming from Perl, PHP, and Visual Basic, I taught myself Javascript and React over the course of a few weeks. Once I got over the initial learning curve, it was an incredible improvement over the old ways, at least for frontend work. Once you start being able to compose pages out of real components, serverside templates and string replacements and such will never be enough again. Typescript moves the error-checking from runtime to write-time, vastly simplifying the debugging process. Modern IDEs are an incredibly powerful tool compared to the old text editors and basic syntax highlighting. Hot reload and built-in preview servers make any changes go live by the time you can cmd-tab back to the browser.

The developer experience now is sooooooo much nicer than it used to be, if you know how to use the tooling.

The UX, not so much... but that's because most of the industry thinks of the user as the unwitting victim to be productized and milked, not as the customer :( That's not really the fault of the frameworks, but company business priorities.

</anecdote>

Yes. Next question, please.

Seriously now, using Preact and vanilla JS without any build steps is something that more people should try out. Even bundling seems redundant in these days of multi-request HTTP connections.