As I've said elsewhere, frontend development is limited only by the limits of human imagination, whereas backend development is limited by the constraints of backend systems. For example, there is an absolute answer to 'what's the most efficient big O runtime I can achieve for sorting this data set'. There is no absolute answer to 'what is the complexity of drawing an aesthetically pleasing button and modeling its interactions to maximize user joy?'
Ask HN: Why did Frontend development explode in complexity?
61–70 of 398 posts
Re: Ask HN: Why did Frontend development explode in complexity?
#62Earlier 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.
Tell that to European corporations. Angular + NgRx/NGXS is the de-facto gold standard there.
Re: Ask HN: Why did Frontend development explode in complexity?
#63It'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…
This. While engaging in flame wars about React I have noticed that all of them start with a peculiar definition of done that, lo and behold, necessitates not only React but whatever feature if the month they are busy ductaping to it. What we need is an honest conversation about what USERS think about spa apps, flat design, etc while holding very obviously interested parties from skewing the narratiwe.
This.
No user wakes up and says, "I gots to find me a UI built with React* today, or I'm going to cry." Ever.
Users. Don't. Care.
We keep adding tech and tools and experiences - if you asked users - aren't improving all that much.
* Or whatever technolgy being championed.
Re: Ask HN: Why did Frontend development explode in complexity?
#64I think it's something analogous to Jevons' Paradox.
Jevon's Paradox, originally written about the use of coal, noted that as it become more efficient to use a resource, the end result was generally not that less of that resource was used, but in fact more.
I think the same thing has happened in frontend development: Tools which were written to make development easier have not had the effect of making it easier to do frontend development, but have made it possible for outside factors (product managers, customers etc) to demand ever more from frontend devs.
Re: Ask HN: Why did Frontend development explode in complexity?
#65Earlier 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.
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.
Re: Ask HN: Why did Frontend development explode in complexity?
#66Why? I think mainly FOMO. When react was out with the blessings of Facebook people wanted to use the same library. Of course most people didn't really care/understand that their internal crud app for editing invoices wouldn't need that complexity. I think my answer should answer your second question: This kind of complexity is actually needed on some apps but these apps are a minority. Programmers love shiny new thin…
It's a mix of this FOMO and a lot of people not knowing how to wire up AJAX well. I've seen entire teams reach for react just because there is a portion of the page where some AJAX was required and react is the only way this new crop of devs knows how to do DOM stuff with server side effects.
In what way is react related to ajax calls? I don't get it :(
Re: Ask HN: Why did Frontend development explode in complexity?
#67React must be used for all websites- no matter the cost, no matter the implications, no matter the practicality. How else will you hire any developers? They explode if not writing JSX.
If something doesn't work out there is yet another react-centered solution to your problem. Server side react can probably fix it. Tailwinds can fix that other thing.
These websites must, obviously, be hosted on kubernetes clusters. They must also be behind three or more load balancers.
Never attempt to cache anything. Redux is managing state and state can't be cached.
I realize you didn't say "React" in your question.
redis has to be installed, even if not used.
Re: Ask HN: Why did Frontend development explode in complexity?
#68There are a lot of salient points made in this thread, but one other aspect is that frontends are the end of a dependency chain, that is roughly like pipelines->databases->middleware->webservers->frontend. The tail end of such an architecture can be more easily change, because less depends on it, usually the only thing is the user's eyeballs. In that situation, more variety proliferates because there aren't as many constraints. Less constraints usually translates to a diversity of approaches, which is what we see in the frontend world.
Re: Ask HN: Why did Frontend development explode in complexity?
#69Earlier 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.
MVVM: yes, in most cases. There are some cases where it's a godsend, but most of the uses I have seen are ... not entirely sane.
But MVC? That's pretty minimal in terms of what you're going to do anyway if you have functionality (model) and will be interacting with it (view). Controllers are often misunderstood, and in the case of Apple massively misapplied (Massive View Controllers).
Re: Ask HN: Why did Frontend development explode in complexity?
#70Earlier 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.)
I think QTCreator provides a similar experience, but I haven't used it in years and might be wrong.