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

[Satam]

SPAs, SSR, typescript, bundlers, transpilers, jamstack, headless CMS, serverless adapters...

But where is all that complexity going? Most websites and web apps I encounter are no better than they were 10 years ago. Sure, they look better, but that's largely orthogonal. There's maybe a bit more interactivity but it's still basic CRUD most of the time. They break the same, sometimes even more.

It seems like chasing marginal improvements in dev and user experience leads to complexity which begets even more complexity.

[mips_avatar]

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.

[mjomaa]

It's not too complicated if you leave out docker, ci/cd, cdn, waf, etc.

Not all the fault of node.js

[PaulHoule]

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.

[alazoral]

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.

[Satam]

OP here. Thank you! I think your singling out of truly complex apps like Notion makes the situation more intuitive to me.

[PaulHoule]

Funny I was building apps like that in 2006 so now I look at most of the popular JS frameworks and think "gee those are good for form processing even if they might not be necessary" but not for the kinds of applications I was building back then.

[cornholio]

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.

[abraxas]

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.

[PaulHoule]

I don’t think HATEOAS is harmful but acronyms like it contribute to the feeling of overwhelm.

[abraxas]

That's fair. I think being in this ecosystem makes us forget how much implied knowledge we assume from the audience.

[aaroninsf]

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.

[bnchrch]

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.

[neilv]

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.

[dihydro]

This is absolutely insane to me. Native HTML5 gives so much power and it seems like front end devs love to jargon and buzzword the next big thing to death every other year. I primarily work in networking and if we added the layers of complexity like I see front end work does we would have SDN configuring an internal PtP VPN for every device on a LAN just because it's the hot new tech.

[neilv]

I made a powerful HTML5 Offline app a long time ago, for some technical requirements (and cool-sounding user) that would be challenging, no matter what stack was used.

Then I was in an interview, where some junior openly sneered at me, for not using a recent popular RDD framework for it.

Part of the problem, even for highly experienced people, is that even the good jobs usually have "technical interview" gatekeeping that's not very enlightened.

(Yes, no matter what framework or stack you're using, I've probably done related things before, and I can pick it up quickly. No, a Leetcode hazing won't tell you how I think, nor what I can do, and it just seems like you're jerking off.)

[fabiofzero]

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.

[orwin]

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.

[schmookeeg]

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.

[Aurelsicoko]

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.

[PaulHoule]

(1) The OP is saying that some people don't feel this way, in fact they feel overwhelmed by new things. I think most people feel bored if they don't get enough novelty and they feel overwhelmed if they get too much. Different people have different tolerances at different times and in different situations. Since we are "in it together" we often have to deal with other people who want more or less novelty than we do.

(2) I want roll my eyes at the bit about "dopamine". It's true, but in the same sense that "adenylate cyclase is activated" and "proteins get phosorylated" and "genes are expressed" and so forth. Your brain is a complex system and anything it does involves the coordination of many kinds of neurons. Scientists know a lot more about it than you or I and there is vastly more that they don't know about it. Probably every kind of neurotransmitter is involved when you see something on social media and repeat it.

(3) I remember Amazon being pretty big in 2000. I'll grant that you can provide people with a richer experience with front-end tech but I don't see SPA being needed to make a store with more items or that handles more users. I remember circa 2011 that many of the web designers in my town who were really good at making Ruby on Rails app seemed to think they couldn't sell that kind of system to customers and they struggled mightily with AngularJS and other frameworks. They regained their footing with React. (Has a bit of that "worse is better" feel like C. I want to like Vue but I can draw whatever I want the way I want to draw it with React.) What appeals to me about heavy front ends is really new stuff like

https://aframe.io/

I mean being able to deliver 3-d content to desktop and mobile and jump into an immersive world is really cool and makes my brain feel good.

(4) Are you talking about energy use on the front end, back end or on the huge spiderweb of wires, fiber optic cables, amplifiers and such between them?

[aaronbrethorst]

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

[ipaddr]

Splitting the code base adds complexity. Adding a script tag does not.

[threatofrain]

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.

[pierreburgy]

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.

[jaredcwhite]

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.

[beretguy]

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.

[mjomaa]

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.

[butz]

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

[moltar]

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

[Satam]

Except last I heard it's getting merged with the hated React router and it's not really clear what that implies, no? Haven't used either, just reading.

[beretguy]

That’s JavaScript again.

[dihydro]

Yes.

[pushfoo]

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

[mathverse]

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

[solardev]

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>

[rcarmo]

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.