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

71–80 of 398 posts

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

#71

Post by goalieca »

jelling wrote: post #65
eloff wrote: post #39

Earlier quoted context omitted.

The browser is powerful enough now that one could replicate this if one wanted to. I don’t think it’s the pinnacle of software development, but it had some advantages.

The difference is that winforms basically had one way to do everything which expedited development because it skipped all of the infinite number of stupid small decisions and libraries that must be cobbled together in a typical SPA.

Win32 could do it all. And in windows there was often a different way to handle things like video across each major OS version. Yet still, I feel it was simpler! Crazy!!

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

#72

Post by myth2018 »

Anwering Q1: a number of reasons, the most important being: 1) programmers' immaturity, we're always looking for new toys; 2) excess of venture capital fuelling too many new projects, opening space for new stuff to be used instead of the old, stable and boring ones; 3) product/design people asking for increasingly insane UI frills, influenced by trends started by big tech's products.

Q2: it depends. If you think of what users need and pay for, yes, it is HUGELY inflated; if you think of the actual requirements we receive, maybe it's not that inflated -- at least part of this complexity is needed in order to build such truckload of eye candies.

It's so disheartening to see such a gigantic waste of effort. But that's the current state of our field.

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

#73

Post by hirako2000 »

Because expectations have gone up and a developer can't even take on coding some pages without prior input from some UX enginner who is likely assisted by some UI designer.

Because we don't have just 1 or 2 desktop web browser mostly rendering text anymore.

We've got 3 or 4 major browsers that most managers want to support all, even though one has over 50% user adoption, and could be installed within 2 mins if not due to IT administrators locking everything in and shipping almost nothing to browse the web.

Each of those "major browsers" with their own same but not the same implementation for mobile, across many different sizes from tiny low rez screen to worry about to phablet/tablet factors, that can rotate of course, so landscape and portrait please, packing videos, photos, and scalable graphics often within the same visible area.

One would think that's enough headache to deal with, but fonts aren't treated equals, and remain proprietary so text won't be the same across windows, linux, OSX and android. No. You may pick one system font that is called the same so should be the same, but it isn't actually the same, at least last time i checked it wasn't.

Oh, and the highest speed consumer bandwidth out there is something like 400Mb/seconds, and the lowest might well be a under 100kb. Both want the best possible, so full HD clip and MB pixels pictures for one, and low def steaming and scaled down pics for the other. And throw something in between to make the average bandwidth users also happy.

Oh, and since we got the cloud and aws is "cheap" demand super quick agile delivery of course. Co pilot and soon gpt codex will make it no-excuse to be late on those over optimistic estimates.

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

#74

Post by AdamKlob »

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

There are RAD IDEs for popular Unix frameworks like Qt or Gnome and probabyly much more I haven't heard about.

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

#75

Post by arcturus17 »

davedx wrote: post #47
andix wrote: post #22

Earlier quoted context omitted.

One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.

To be fair most front-end projects have abandoned redux now. It was for sure boilerplate hell.

I've been doing some research recently and it continues to be by far the most popular state management framework for React. The fact that there are alternatives doesn't mean that most projects have abandoned it.

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

#76

Post by codeptualize »

eloisant wrote: post #53
codeptualize wrote: post #32

I disagree with the premise, things have gotten a lot simpler. I think you need to make distinction between website and web application. The latter came later and is by definition a lot more complex, I assume this is mainly where the premise originates from. But having gone through building websites with frames, tables, png's for box shadows and border radius, jQuery and php based web apps, and having spend many days…

Web applications don't all have to be Single Page Apps. That's where most of the unnecessary complexity comes from. Unneeded SPA.

That's not less complex, that's moving complexity to a different place with different problems and constraints.

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

#77

Post by art0rz »

flippinburgers wrote: post #44
quxbar wrote: post #11

I get the impression making a web app was considerably more difficult for a solo developer pre-jQuery. For a while we had an explosion of choices, and ultimately things coalesced around React and similar paradigms. Meanwhile the per-capita productivity has been skyrocketing as increasingly sophisticated cloud services provide everything from raw key-value storage to turnkey caching and auth solutions. Is it more comp…

Web apps used to be just html and forms so no the complexity has skyrocketed.

Where the majority of the complexity was in the backend. Now, the complexity has simply moved.

I'm quite happy I don't need to have two different codebases in different languages for most things anymore. I'm more than happy to offload it to the browser to save me some effort, time and money.

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

#79

Post by electroly »

claudiulodro wrote: post #16

Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven't done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.

I'm a Windows developer and as such I'm biased, but I think Windows apps are dramatically easier to write than web apps. I still use WinForms professionally to this day. Productivity is absurdly high. The number of concerns to worry about is low. The framework has been stable for 20 years and I know all of its quirks, which never change. Fads are ignored. We can zip around with amazing speed.

On the other hand, our apps are:

- Ugly looking

- Dated looking (this is different than ugly, but our apps are both)

- Full of UI jank (too many WinForms controls take their sweet time painting on the UI thread)

- Non-server-based

- Non-cross-platform

- Non-sandboxed

- Installed from downloaded file that gives scary warnings in your browser when you try to open it

These downsides hint at some of the reasons why I think web-based development is necessarily more involved than for Windows apps.

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

#80

Post by andix »

mojuba wrote: post #42
andix wrote: post #22

Earlier quoted context omitted.

One of the best examples of this complexity inflation problem I always see is the Redux pattern in frontends. This pattern comes with a lot of overhead, a lot of things that need to line up (Actions, Reducers, Actioncreators, Selectors, ...). And most of the time the applications that use it are completely trivial. If you remove Redux, half of the code is gone, it's faster and easier to understand and extend.

Same for MVC/MVVM and Co specifically on mobile. These things were created to teach beginners a few important concepts, mainly separation of concerns. MVC/MVVM work well on toy sample projects with 2-3 pages but can ruin a larger project. Somehow wherever I'm seeing MVVM applied there's also messy, buggy, impenetrable code around it. I don't think it's a coincidence.

Exactly, those patterns may be good if you know exactly what you're doing.

But in all the other cases, they just make everything more complicated and harder to understand.

I've once worked with a messy codebase, it was written in a very "naive" way, but that was also the strength of that code. Every view was in one file, every action was just one method, so you exactly knew what code was executed when. We tried to refactor it, but it became complicated really quickly (the domain was really complex), so we decided to just adopt to the style. We only split up components that became to big into smaller components, sometimes decoupled things a bit, but most of the time just kept all the logic.

And this product is successfully in use for over a decade now.

Post reply on HN