Live data from Hacker News

Ask HN: Why did Frontend development explode in complexity?

news.ycombinator.com

251–260 of 398 posts

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

#251
post #48

Frontend was always complex, being web, mobile or desktop apps. It is following similar cycles from decades ago. Winamp[1] in 1997 made their own UI using custom draw in Windows because those components and level of customization didn't exist in the standard API. We can historically observe these cycles of complexity and technology changes only looking at Windows toolkits: Win32, MFC, QT, Silverlight, Windows Forms,…

Indeed, the devs who dismiss the complexity are the ones least suited to solve for it.

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

#252

Earlier quoted context omitted.

Async queues are far from meaningless. They are the basis of distributed, resumanble/retryable computation. If you can't see the advantage of keeping your processors fed with work as close to 100% of the time as humanly possible, I got nothing for ya. Hell, AWS is basically popular because you can have novice programmers toss up synchronously programmed lambdas, and scale out the underlying infrastructure with Amazon…

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

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

#253
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.

I do not think that you would be able to do ActiveX, COM, OLE, MFC, C++ after 2 weeks of bootcamp. Yes, Delphi and Visual Basic simplified many of it but there were still many challenges to develop and ship your software. Just shipping alone and dealing with installers was a challenge by itself. Now compare it with a browser tab and a single click that deploys your code across the globe so it event can run in space o…

But here's the thing: you didn't needed COM or ActiveX or MFC in many cases. You could literally wire up and build an up pretty effortlessly. With webdev today we jump directly to very complicated things when 90% of the time they are not needed.

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

#254
post #226

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?

There's always the option of a native client rather than a web-based client. A good example from days gone by is Evernote. If you've only started using it recently you might not know this, but the client used to be really good.

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

#255
I started my Web Dev career in 2005, around the time "Web 2.0" started to pickup steam. It was (In my recollection) really the beginning of the Web Application model. Users were starting to expect web pages to do more, and be more than "click a link, go to another page"

I'm certain any developer from that era has a story about writing tools to make their own life easier. Prototype and jQuery were popular as they abstracted a lot of the obnoxious stuff you had to do over and over again.

And the story goes on from there. The complexity is a story of trying to simplify for the developer, and then trying fix the costs of the overhead from those simplifications.

As for your second question. It's not necessary of course, but if you don't use these frameworks and tools, sooner or later (I think) you're going to be engineering a solution yourself.

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

#256

Earlier quoted context omitted.

This relates in no way to any statement from the comment you replied to. Did you mean to reply to a different comment?

> [..] the most popular state management framework for React [..] Quoted from the comment they're replying to. > [..] maybe “state management” is not something you need a framework for? Quoted from their reply.

Ah I beg your pardon. I read the comment in completely the wrong tone of voice.

To me it seemed like the comment was attacking its parent for investigating state management frameworks in the first place - when it in fact called out "no framework" as a valid alternative to any number of frameworks.

(I hope that made sense)

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

#257
Complexity in software typically comes from codebases made for multiple teams. When you have multiple teams, this is unsurprisingly a benefit. When you don't, you typically get one team pretending to be many, and the needs of the other personas will be guessed, not known.

Web frontend work starts at a disadvantage because of the css/html/js divide. If you actually have distinct designers/authors/coders, it works as designed. If you have a small team, it doesn't. To the typical disasters that we are all used to and have probably been responsible for.

The best symptom of this, to really demonstrate, is when you don't know what tools a contributor needs other than a text editor.

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

#258

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…

For me the reason for the explosion in complexity in both frontend and backend comes down to package managers on all platforms getting way better with transitive dependencies and lowering the cost of adding those dependencies. Developers used to be wary of bringing in another dependency just in case it created some conflict, but ecosystems that near-perfectly encapsulate transitive dependencies have gradually done away with that healthy wariness, with a combinatorial explosion in packages as a consequence.

Create-react-app installs 1500 packages to show a hello world page, and it is quite sane in its choice of dependencies. For me this is a symptom of the whole npm ecosystem being diseased with dependicitis.

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

#259
post #249
post #226

Earlier quoted context omitted.

/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?

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 over being more utilitarian.

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

#260
post #125

I recently transitioned to a "full-stack dev" role (using React on FE), and honestly, it is much _simpler_ than I expected. I had the opinion before that FE is lacking the breadth of BE development, but of course, without actual experience in the matter I might have missed something. Now that I'm 2 months in, I still don't see the complexity, actually, if anything, React makes stuff so much _simpler_ due to its leani…

There are probably 15k npm libraries that solve that very thing. I think this is part of what people struggle with and complain about WRT web dev. There are so many choices for libs and frameworks it can be hard to know which one to pick and which dragons you'll find along each path.

FWIW if you're using hooks and React, React Hook Form is good: https://github.com/react-hook-form/react-hook-form

Post reply on HN