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

181–190 of 398 posts

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

#181

Post by sibit »

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.

Personally I've had great success with adding Web Components to server side rendered projects. It's really simple to just bind a class to the custom element and attach a few event listeners. If you need something a bit more complex rendered on the client side you can use mithril or similar libraries like lit-html. When I need to hydrate a state I JSON encode the model as a data-state attribute and I decode it when the Web Component's connectedCallback method fires.

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

#183

Post by wankle »

fortnum wrote: post #2

This will be a posting, which either receives no to little responses or will have 256 responses within the next couple of hours :) I am sure, there'll be quite a few who'd argue that this is necessary complexity, but my take on this definitely is the latter - artificially inflated But it's not only the web . Same happened to Java in the 2000s and is currently happening to Android. Any mainstream Java job is more conf…

Plumbers are vitally important, imagine flushing the toilet and poop pops out of the kitchen faucet.

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

#184

Post by arbitrage »

ls15 wrote: post #179
WandaVision wrote: post #114

Unpopular biased opinion. Frontend development is mostly done by people who are into visual things and less into logic. Unlike backend engineering, where people working are primarily choosing technology based on logic/merit and less by visual appearance. This leads to the adaptation of large number of garbage frameworks in frontend primarily because their landing pages look visually appealing. After some time fronten…

Ok, but why aren't companies then firing all frontend developers and instead let backend developers build logic frontends with vanilla HTML/JS/CSS?

Because you can't do that with vanilla HTML/JS/CS.

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

#185

Post by bena »

sillysaurusx wrote: post #46
eterm wrote: post #33

Earlier quoted context omitted.

TWenty years ago windows development was a lot simpler than modern browser applications. Fire up visual studio and create a new winforms project. You could literally drag and drop your way to a modest application with only minimal programming 'under the hood' for the business logic. I still don't think anything has surpassed the usability of winforms for a developer just wanting to get something done.

Can confirm. I love winforms. Convinced that even the most hardcore Unix devs are missing out on the sheer joy of being able to double-click on a form you just dropped into an editor and seeing it automatically add an event handler for the common case of whatever type of UI component it is. (Buttons are onclick, inputs are ontextchange, etc.)

XAML in Visual Studio is similar. You can put in the call to the handler, then "Go To Definition..." and it will create the handler for you.

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

#187

Post by nokya »

mojuba wrote: post #12

It's artificially inflated and I'm seeing this in almost all areas, not just frontend. Some of the projects I've seen could have been reduced in size multiple times with no effect on the outcome whatsoever. In one instance I rewrote a GUI app and made it 15 times smaller (!), that's my absolute record to date. Been wondering for years, so you need to actually be inventive to add unnecessary complexity, it's not that…

"Where is this coming from? Is it because we want our work to look important?"

I am intimately convinced it could play a role, at two layers. First, at the framework layer itself: the plethora of propositions seems symptomatic of our approach to dealing with things we don't like. When confronted to the choice of walking the extra mile to improve and contribute to an existing language/framework, or building your own new thing that focuses on solving your own problem, my guess is that the more senior architects (esp. those working at licorns or GAFAMs) will choose the latter option, thus resulting in an increased offer. Also, let's not forget, being the author of a successful language or framework sounds cool.

Second, at the user layer (architect at random corp): this individual is increasingly convinced that working with the latest silicon valley approved framework will work wonders on her/his resume.

I am confronted to new software architectures on a weekly basis as a result of my job and the choices of framework/language X as opposed to Y often follows a common pattern: some architect thinks that segmenting a system into as many components/technologies as possible somehow always makes it more reliable at the end.

If I owned a software company, I'd immediately get rid of anyone showing these behaviors. But I have to admit: the bigger the mess, the more hours I can bill :)

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

#188

Post by manv1 »

On the web side you need to synchronize the DOM, the visual state (which is mostly related to the DOM), the user's state, and the backend state using a protocol that's stateless.

Really, the browser side stuff is the real PITA. It's a hacked together piece of shit written by people who were too clever by half. And it's designed to be used/driven by less-than-skilled individuals.

But in the end one big problem is there aren't a lot of ways to model a UI effectively. One given screen can have multiple states and behaviors that are state dependent, and the tools really aren't there. How do you specify "animation like x/y/z" on a screen?

There are tools for designers, but they're don't really work when handing that off to development. What I've seen is people printing out prototype screens and annotating everything, but that's obviously janky.

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

#190

Post by TheOtherHobbes »

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 virtual DOM which is still based on HTML etc.

All of this could have been avoided by making Web 1.0 procedural and explicitly extensible and not baking content styling into HTML's semantics. There would have been some small additional complexity and it might have been harder for beginners to learn initially. But the current stack is far beyond non-developers anyway.

I suspect there would have been at least a fighting chance of replacing everything with a single standard library that runs faster and could easily handle everything React does more simply and elegantly, including resolution-dependent rendering - probably something like iOS/Android, but even simpler, and using the browser explicitly as a VM/secure container.

Post reply on HN