just use svelte for SPA XD
it's just like normal html with autoreactivity
Ask HN: Why did Frontend development explode in complexity?
331–340 of 398 posts
Re: Ask HN: Why did Frontend development explode in complexity?
#332Earlier quoted context omitted.
Tell me you're not making complex webapps without telling you're not making complex webapps
The publish-subscribe/observer/mediator pattern is perfectly fine for state management, and doesn't need a framework. At most, a small-ish library, but you can also re-implement it yourself quite easily. Reading your comment, I have the impression you took it as "there shouldn't be any state management necessary", instead of "state management doesn't need a framework" sense.
FWIW, Redux literally _is_ a pub-sub/observer pattern implementation :) And the Redux core library _is_ extremely small.
But, that led to the community building hundreds of addon libraries for the same sets of use cases, which is what led us to build our official Redux Toolkit package to simplify standard Redux usage patterns.
Re: Ask HN: Why did Frontend development explode in complexity?
#333just use svelte for SPA XD it's just like normal html with autoreactivity
Re: Ask HN: Why did Frontend development explode in complexity?
#334Earlier quoted context omitted.
"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 n…
> 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 :) I recently greenlit a project that uses the latest Angular, C# REST APIs and a SQL server. It's clean, it works…
(note: I agree with your approach, just making a point)
> that uses the latest Angular
But what's the migration plan for the next time Angular goes through a massive ecosystem migration and suddenly you're staring down the barrel of being massively out of date, or investing anywhere from days to months of work running just to stay in place? This is what actually seems to be the problem to me, not just in frontend either: very little is stable, and you end up piling hacks upon hacks just to try and stay up to date. People also pick new tech after being burned by previous tech doing these massive ecosystem-wide migrations and seeing how painful it is.
I wish I knew the solution :)
Re: Ask HN: Why did Frontend development explode in complexity?
#335Earlier quoted context omitted.
> visual and non-visual parts are separated globally, not on a view-by-view basis Yes, yes, and YES! This is something that confused me greatly over the last years: teams/companies I was in contact with were really struggling getting MVC to work (never mind MV*) and I wasn't...but I wasn't doing anything special, at least not that I could tell. I would implement my model, TDD-style, put minimal views on top, possible…
Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API? Please forgive the lack of background of this next question, but does this mean you do not support BFF pattern? Have you heard of Dubray's SAM (State-Actor-Model) approach? Curiou…
> Does this mean we could fragment an application into, say, a low-level "engine" or "kernel" in C or Rust, an application server to handle requests to it, and the view be any of a React Native mobile app, desktop app, or convenience web API?
Let me present: Kotlin Multiplatform Mobile[0] (or KMM, a real mouthful I'll grant you). Something I'm very excited about, because you could do exactly that. Seems like an interesting thing to keep an eye on.
Re: Ask HN: Why did Frontend development explode in complexity?
#336Earlier quoted context omitted.
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.)
Another reason there is so much complexity is that the computer speed allows it. If you are constrained by processing power you will chose a more simple architecture... until you start optimizing. A lot on unnecessary complexity is premature optimizations. That "web scale" service you are building with "serverless" and other cloud services will likely run fine on a 1$/moth VPS - but who would like to manage such a sm…
You aren't wrong, but I suspect there was more unnecessary complexity in early computers then you'd allow. Is why don't ridiculous demo scene stuff is still created today. :)
Re: Ask HN: Why did Frontend development explode in complexity?
#337Earlier quoted context omitted.
As much as I hate modern frontend code, I question this narrative. What 20 year old GUI library is running circles around... anything?
Django, bootstrap and a sprinkling of jQuery works really well and results in simple code that can be maintained by a single dev. Bootstrap is only 11 years old. jQuery is 15 years old. Django is 18 years old. jQuery is used by 94% of the websites that use JavaScript. https://w3techs.com/technologies/overview/javascript_library
None of those are gui toolkits, though. At best, you are pointing to html working rather well at it. Though, that is more force of will from developers, as html was specifically not a front end toolkit at the outset.
Re: Ask HN: Why did Frontend development explode in complexity?
#338My conspiracy theory of choice is that all these big front end frameworks have been developed and heavily funded & pushed by (primarily) Google and Facebook specifically to make it so people are forced to run client-side JavaScript to get even the most basic functionality in every website, this ensuring tracking and ad code can get delivered.
Re: Ask HN: Why did Frontend development explode in complexity?
#339Re: Ask HN: Why did Frontend development explode in complexity?
#340I started a project in October. Spent part of November and through December building prototype frontends to decide which way to go - the whole next / nuxt type debate, looked at svelte and Laravel. Finally came to the conclusion that since I was using Django for the backend anyway, there really wasn’t anything that couldn’t immediately be done just as well with Django templates. Sure, maybe at some point I’ll need to integrate some other frontend tools, but by that time I will have tested market fit and I will have customer feedback that tells me if I actually need something different for my UI. All of these front end frameworks add a ridiculous amount of complexity and brittleness for unclear advantage.