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

241–250 of 398 posts

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

#241

Post by pixl97 »

claudiulodro wrote: post #134
marcosdumay wrote: post #105

Earlier quoted context omitted.

Yes, the browsers export a lot of capabilities to the frontend. But you point no reason why the frontends must use those capabilities.

IMO it's mainly Google and Chrome/ChromeOS trying desperately to keep people away from the competing Windows and Apple ecosystems, which requires that the browser do essentially anything a stand-alone program could do. This doesn't explain why there are a million JS frameworks, but it does explain why the browser has ballooned in features and complexity over the years.

>This doesn't explain why there are a million JS frameworks

Not sure if this is a valid answer, but I would assume that both Microsoft and Apple provided decent and easy to use frameworks to build applications on their operating system. This setup a particular amount of vendor lock in, the library is already there and doesn't need downloaded/installed making it easy on the end user.

On the other hand, frameworks were not provided by the browser manufactures initially. Also, everything is downloaded so 'include foo.js' is just as easy as 'include bar.js' opening up a vast ecosystem of frameworks.

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

#243

Post by c-smile »

TheOtherHobbes wrote: post #190
c-smile wrote: post #169

I would not say that Web UI is that more complex than desktop UI. In principle. It is media that changed quite a lot - spectrum of devices that we need to show our UI on. We had pretty much fixed 80x24 character terminals, then we had 640x480 pixel grids, sometimes 800x600 and more. But at that times you can still assume that pixel is presented to the user as a square of 1/96 x 1/96 of inch. Such fix allowed us to us…

Web UIs should have been procedural from the start, but HTML's design confused semantics and visualisation. CSS was supposed to clarify this, but CSS isn't procedural either. So js was added to the mix to fill the gaps in what CSS can't do. But js doesn't componentise well, so React was invented as yet another layer to "simplify" everything else. So now we have a "proper" frontend dev language which sits on top of a…

HTML is nothing more than grouping definition of DOM elements. One of possible ways of defining element agglomerations.

It is not bad or good, it just allows to make job done - to group (semantically link) DOM elements together.

But the DOM element itself is what makes the difference. DOM element is the atomic block that a) can be attributed, b) may have states c) to be styled according to those attributes and states and d) can receive events.

In that respect Web UI is more granular than desktop UI. On desktop you have windows (NSViews, GtkWidgets, etc) that are macro state machines. E.g. COMBOBOX, LISTVIEW that have predefined complex structures and expose quite few configuration options|styles.

Web UI components are usually composed from many individually accessible and configurable DOM elements. And that creates an impression of Web UI complexity. But in fact Web UI is just a DOM element with styles and bunch of layout managers to replace those DOM elements - its vocabulary is conceptually simpler and more regular than desktop macro blocks.

ReactJS (PReact, Mithril, Vue, etc) are not more than reactive DOM element aggregators - definitions of runtime assemblage of those LEGO bricks (DOM elements) in response of state/attributes changes.

On top of those we have Web UI frameworks that are all about providing sets of components - predefined types of aggregates of DOM elements.

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

#244

Post by taeric »

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…

Further on the zirp idea, a lot of the explosion can be seen to correlate really well with team sizes. This gets into a feedback loop where you need bigger teams, which in turn means you will benefit more from segmented code. Which means you need more teams.

Not shockingly, the answer isn't a simple use fewer people. Rather, the amount of complexity in a codebase will vary based on budget and organization size. That is, there is no correct answer intrinsic to the code.

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

#245

Post by taeric »

pmlnr wrote: post #200
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…

Don't forget about resume driven development, though that ties in with marketing.

This is usually responsible for bad code. Which, to be fair, is often associated with complexity. They are different, though.

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

#246

Post by spaceman_2020 »

dsego wrote: post #236
spaceman_2020 wrote: post #218

Earlier quoted context omitted.

What are people using now? Good old context?

Things like react-query for syncing with server state (which can be most state in web apps) are getting popular, or smaller hook-oriented stores, like zustand, jotai or recoil for true client-side state.

Second time today that someone has mentioned React-query to me. Sign that I need to look that up finally

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

#247

Post by gls2ro »

wankle wrote: post #177
perrygeo wrote: post #132

The question itself might contain a partial answer. If "frontend" and "backend" are assumed to be two completely separate disciplines, the architecture is going to reflect that (Conway's law). It's possible that building a website as a wholistic product (ala Ruby on Rails) is inherently less complex because it eliminates an artificial boundary. We see backend teams struggling to build APIs and frontend teams struggli…

"Consider what if the software team (singular) just created HTML UIs directly from the DB and eliminated the middleman? I'm looking at things like HTMX and phoenix live view as a potential solution." In the enterprise, data transit, processing and management architecture is more complex than save this text in the database; just as decent UI and UX is more complex than a text field and input button.

In the enterprise sometimes things are complex and sometimes things are getting complex when you take a team of 100 people and ask them to build a new system they will build a huge system and discuss for months about reliability, error handling, remote storage, and a lot more needed systems.

Each specialisation will define some constraints that will only be needed when their system is 3 years old but present it as if you dont start with that it will be hard to add it afterwards.

Thus if you ask a 100 people department to create a new web app it will create a web app that will provide enough work for 100 people.

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

#248

Post by chrisco255 »

brimstedt wrote: post #180

The main reason is because we shoehorn complex apps/ui's into a browser that wasn't made for it. It's not the UI is very complex , or that there are ton of frameworks with different maturity levels. It's because the browser and thus html/CSS was made for documents. If we made a "browser" made for apps, where we didn't need to transpile to js, and didn't need to cater for incompatible browser versions, but could conce…

You could do this now with HTML canvas and web assembly, but you won't, because the web already has a rich feature set of accessible and search engine friendly features.

> but could concentrate on what really matters we wouldt have such a big problem

Curious for someone who dismisses the complexity of front end, what you think really matters in creating a cross platform UI application experience that works on all devices?

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

#249

Post by taeric »

stiray wrote: post #226
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…

/me remembers MFC/QT/BCGsoft and C++ codebase and gently smiles on thought that maybe the issue are everywhere else except the UI complexity. We are where we are, but it is interesting that GUI libraries from 20 years back are still running circles around latest and the greatest UI web front-end, even if it is also client rendered. Maybe, just maybe, we should search for an issue somewhere else?

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

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

#250

Post by satyrnein »

chrisco255 wrote: post #231
satyrnein wrote: post #212

Earlier quoted context omitted.

In my experience, people don't start out with the goal of loading indicators on buttons. It's usually the mistaken idea that avoiding a page reload will make the action faster. Instead, you now have a slow Ajax call, and the button appears broken, so now it needs a loading indicator.

"a slow AJAX call"? What is even meant by that. Async JS is not slow. It's only limited by the user's connection speed and amount of data to be transferred and server response speed. This is a few dozen milliseconds but can be optimized down to sub 10 ms (the server and latency is the bottleneck not JS). A full page reload will of course take longer because instead of one tiny JSON object you have to send the full HT…

I was referring to the server being the bottleneck, as you mention.
Post reply on HN