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

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 · a year ago

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

PaulHoule · a year ago

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.

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 · a year ago

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 · a year ago

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.)

mips_avatar · a year ago

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 · a year ago

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

Not all the fault of node.js

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 · a year ago

cornholio · a year ago

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 · a year ago

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.

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

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

aaroninsf · a year ago

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 · a year ago

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.