Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

Post reply on HN
Print view View original

271–280 of 398 posts

Re: Ask HN: Why did Frontend development explode in complexity?

#271

Post by pixl97 »

ergonaught wrote: post #210

Because business cares about business and moves too fast to get it right or waste time on values, and by the time enough people might object the network effect or inertia or tech debt or whatever you want to call it has become The Way It’s Done and nobody can stop long enough to fix that.

Business is in competition with other business, not in competition with 'doing things right'. Forcing businesses to 'do things right' is called regulation and will get you lots of subcomments on how that's bad here on HN.

Re: Ask HN: Why did Frontend development explode in complexity?

#272

Post by tomwheeler »

seti0Cha wrote: post #239

I'm more of an ops and backend guy, but I used to do a lot of web development in the early days of the web - assembling HTML, a sprinkling of javascript, hand-rolled CSS and embedded styles. In a certain way it was very simple, but in another it was horribly complicated. Sure, the pages we built were simple compared to today, but the tools we had were extremely crude and building a large website required some pretty…

This is my experience as well and I agree with your point.

25 years ago, I had to know which parts of HTML, JavaScript, or CSS did or didn't work properly in different versions of Netscape, Internet Explorer, and a few other browsers. This also varied by platform. Internet Explorer 4.x varied significantly between the 16-bit version on Windows 3.11, the 32-bit version on Windows 95/98, and the surprisingly decent version they released for the Mac.

"Graceful degradation" was the goal on my team, so it wasn't so much about building functionality with JavaScript as it was about using it to make things more convenient when possible, without breaking things otherwise. For example, we would use client-side validation to save a round-trip to the server, but server-side validation would ultimately catch the problems if a client had JavaScript disabled. Keeping those validation rules in sync was a pain, because the server-side code was written in a different language from the client-side code.

I do think that frontend development is more complicated than it needs to be these days, but understanding the evolution, I can certainly see why it reached this point.

Re: Ask HN: Why did Frontend development explode in complexity?

#273

Post by nfRfqX5n »

imnotreallynew wrote: post #154

Related question: what would the folks here recommend for someone that wants to keep the frontend “stupid simple” while not resorting to writing everything in pure HTML/CSS/JS? I’ve heard mithril.js recommended before but I’ve yet to try it. I have experience with Angular, React, and a bit of Ember and the amount of code and “magic” involved is absurd.

React is simple

Re: Ask HN: Why did Frontend development explode in complexity?

#274

Post by cies »

Shitty ducktape-y standards (most notably JS that was initially designed in 10 days). But it still became the standard for x-platform SaaS UIs: point your browser to a URL and go!

So a lot was demanded of these shitty standards (HTML, CSS and JS) and in oder to push them to the max a lot of "frameworks" emerged helping you with that. First jQuery, then Knockout, ..., React, ...

> Is that complexity necessary or artificially inflated?

I'd say it's organically inflated: no one did it on purpose. Every one tries to make it simpler.

I'm a big fan of Elm, which GREATLY reduces the complexity or browser apps... for me.

And still I prefer server-side-rendered if possible (or I have to manage the state on both ends, which also increases complexity).

Re: Ask HN: Why did Frontend development explode in complexity?

#276

Post by taeric »

wlesieutre wrote: post #259
taeric wrote: post #249

Earlier quoted context omitted.

As much as I hate modern frontend code, I question this narrative. What 20 year old GUI library is running circles around... anything?

There’s another discussion going on about how the older layers of Windows you dig into, the more useful the UI gets, perhaps that’s the narrative they’re thinking of: https://news.ycombinator.com/item?id=34216619 I’m inclined to agree, older UI toolkits could make plenty productive UIs. But they aren’t good at following yearly evolving design fads, and webpages tend to lean heavily toward marketing and appearances ov…

Older toolkits were great at single team creations. This, interestingly, did mean the person making it knew exactly how to use test it.

I question whether the toolkits were actually better, or we just had fewer things to use test? Certainly fewer form factors. Granted, the decision to try and have a single code base for many different resolutions and such is, of course, questionable.

Edit: directly to the point, is it the old toolkits that made better tools? Are those same toolkits used today? Pointing at older tools does not show that the toolkits were better.

Re: Ask HN: Why did Frontend development explode in complexity?

#277

Post by lucidguppy »

Alan Kay thinks the internet and TCP/IP is awesome - but the web is horrible. He's coming from the small-talk world where you have an incredibly powerful environment that's self enclosed.

He sees the browser and javascript as a step back to technology that was developed in the 1970s.

The dom+javascript just isn't as powerful and so every attempt to improve shows some defect that a good plurality doesn't like and then they redo everything over again.

We're basing everything on a language that was originally functional but was disguised as an OOP language because some executives thought JAVA was the next big thing. We're forcing a document object model to be a human interface model.

We're stuck in this local maxima of power and functionality and all these attempts won't work because they're incremental. We need a quantum leap about what we think the human interface of the internet should be - and it shouldn't be the browser.

Re: Ask HN: Why did Frontend development explode in complexity?

#279

Post by ericlewis »

taeric wrote: post #252
peterhunt wrote: post #238

Earlier quoted context omitted.

I didn’t say they were meaningless, just that they are often overused and can make systems needlessly more complex. How many microservices architectures with dependent webs of async queues emulating distributed transaction semantics could be replaced by one big rdbms? I think a lot!

My favorite is when a new project thinks it needs this on day one. I'm willing to place money that most new projects will struggle to saturate a single computer. Much less a distributed infrastructure. (yes, I'm well aware there are some cases. But even most fang projects are doing relatively little work, all told.)

Chime famously (but maybe not externally) ran almost all infra off two co-located beefy servers all the way up to their millionth customer. Maybe that is dumb, but we never had any downtime or slowness that was a result of work we did. The APIs we would rely on sometimes though did.

Re: Ask HN: Why did Frontend development explode in complexity?

#280

Post by TobyTheDog123 »

peterhunt wrote: post #167

Early react team member here. The popular react/webpack/npm stack is probably what the OP is talking about. It was popularized because the Instagram web team used webpack and npm in 2013 so we recommended it alongside react in the early days. I was TLM of the team when we made these decisions. There are three main points I want to add to the conversation. 1. UIs actually have a lot of complexity. The number of states…

Disagree on the first reason - I don't think actual application code and logic has anything to do with frontend overcomplexity.

My issue, and the reason I moved away from JS altogether and to Flutter/dart, is the massive amounts of redundant and complex tooling, choices, and concepts.

Webpack, npm/yarn, Typescript (TSConfig), package.json/node_modules, Babel, Prettier/ESLint, React, Remix, Next, Svelte, ESBuild, ES6/ES5/ES2020/ESNext, Tamagui.

Yes I'm mixing categories in the list above, but the point I'm trying to make is that with something like Flutter/Dart, there's only Flutter/Dart.

Even if there's some really cool new JS library that handles all of my application-centric concerns (namely, layout animations and good handling of shared types across n different apps/packages/services), I'll never use a JS library again because it will simply never be enough. I'm not going to use these band-aids anymore.

Post reply on HN