Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The front end community wants to wash its hands of the decade we lost

twitter.com

Post reply on HN
Print view View original

71–80 of 87 posts

Re: The front end community wants to wash its hands of the decade we lost

#71

Post by kcartlidge »

z9znz wrote: post #22
skrebbel wrote: post #15

This is just good old cargo cult JS Framework Fatigue but then in a fancy “thought leader” writing style, yes? Am I missing some fundamental new insight?

The point I got from the mini-rant was that we have been going down this path of ever-increasing complexity (and ever-increasing client burdon) with this inherent belief that it would result in something better. Better could be "user experience", or "client behavior control/consistency", or ? something. But have we really done side by side comparisons and gathered real evidence? My instinct is that 80% of websites ca…

> The Phoenix Framework (LiveView) crowd, and later the Rails (Hotwire) crowd show that you don't need a complex SPA to get user-positive experiences.

As an aside, for those unaware it may be of interest that Hotwire can be used to incrementally enhance any ecosystem's server-rendered HTML experience and not just Rails. From the simplest option of just including the source but changing absolutely no code, which has an instant impact, to making proper use of it.

One of the projects I use it on is a C# MVC (server-rendered) app and with virtually no effort you get some of the benefits of ye olde update panels from webforms. It's really quite neat.

Re: The front end community wants to wash its hands of the decade we lost

#72

Post by jaredcwhite »

mabbo wrote: post #12

I feel the author misjudges the people making these decisions because for them in their own situation, the choice of large frameworks isn't the right one. But many smart people are in different situations in which the best decision is to use a framework. If I'm Amazon or Google and each ms of time to page load (p99 and average) is measurably worth a 6+ figure sum of money per year, then yes, cutting out the framework…

React was created by Facebook/Instagram, for FB/IG. Startups with tiny teams (or a team of one!) should hesitate to reach for ANYTHING promoted by large corporations. Even Lit, a web component library I really, really like, should _not_ be a default solution. Vanilla web components—especially ones that are easily progressively-enhanced from server-driven HTML—can be a better solution sometimes.

Re: The front end community wants to wash its hands of the decade we lost

#73

Post by jaredcwhite »

kcartlidge wrote: post #71
z9znz wrote: post #22

Earlier quoted context omitted.

The point I got from the mini-rant was that we have been going down this path of ever-increasing complexity (and ever-increasing client burdon) with this inherent belief that it would result in something better. Better could be "user experience", or "client behavior control/consistency", or ? something. But have we really done side by side comparisons and gathered real evidence? My instinct is that 80% of websites ca…

> The Phoenix Framework (LiveView) crowd, and later the Rails (Hotwire) crowd show that you don't need a complex SPA to get user-positive experiences. As an aside, for those unaware it may be of interest that Hotwire can be used to incrementally enhance any ecosystem's server-rendered HTML experience and not just Rails. From the simplest option of just including the source but changing absolutely no code, which has a…

Turbo's actually really great for static sites—you can speed up page transitions and even handle some "reactive" elements using Frames and HTML fragments. Pretty awesome stuff. No Rails required.

Re: The front end community wants to wash its hands of the decade we lost

#74

Post by Gigachad »

cynicalreason wrote: post #9
stemuk wrote: post #2

After reading the entire thread I am still in the dark about what exactly the author wants to see changed. The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.

I'm in the same boat, I was expecting some punchline .. it's just moaning without anything concrete

Sums up the majority of whinging about JS you see online. I’m confused what “the front end community” even is.

Re: The front end community wants to wash its hands of the decade we lost

#75

Post by Existenceblinks »

distopico wrote: post #62
CharlieDigital wrote: post #40

I'm at a startup that builds an e-comm platform. Currently on Next.js; evaluating Astro. We're slowly coming to the realization that none of these platforms are either simpler or faster than what we could do with modern vanilla. Some very basic things like show/hide images and blocks of text based on user selection require an obscene amount of code/complexity in React that in vanilla is just element.style.display = c…

I worked with React.js for more than 5 years in a big projects and I finally burnout of it, I agree with all you said, React added a extremely complexity for simple thing, added a lot of side affects that sometimes are hard to debug and fix, fix re-render will be your daily work more that create features and in the end you get a slow application in mobile devices due the size/re-render etc. In the end I decided to re…

From engineering perspective react-dom is being 130kB (.min) while the other is 6-8kB AND faster in benchmark, yet the industry decided this is acceptable, I know that our engineering principle is rotten.

Re: The front end community wants to wash its hands of the decade we lost

#76

Post by Existenceblinks »

cehrlich wrote: post #14
christophilus wrote: post #3

Ah, yes. Everyone’s favorite whipping boy: the front end developers. I don’t think the last decade was a mistake. React (and Preact and similar) are my favorite ways to build out UIs. I prefer it to every other thing I’ve tried— and I’ve tried just about every other thing, including building native UIs for a decade. It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the chur…

Yeah, I think people who pretend that modern FE is possible without React or another similar framework haven't built a modern frontend and dealt with all the demands for interactivity that users have nowadays and the complexity this brings regarding rendering logic, state, etc. There's still a time and place for sending HTML and maybe a few tiny JS files down the wire, but for anything "application-like" it's just no…

There are a couple of full-blown text editors written in vanilla js so it's very capable of doing highly interactive.

Re: The front end community wants to wash its hands of the decade we lost

#77

Post by em-bee »

slightlyoff wrote: post #65
talkingtab wrote: post #33

Earlier quoted context omitted.

I agree, if you are that virulent about what is wrong, maybe you want to give a clue as to what you think is right. Or do you just think everything is wrong?

OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor). More pithily, maybe PHP was good, actually? Popping up a level, this isn't about tools, it's about c…

so in essence your argument is that management needs to care about performance because most end users have devices that are not powerful enough to process all that javascript, based on this technical argument i found hidden in a footnote:

JavaScript-delivered UI strips the browser of its ability to meaningfully reorder and slice up work so that it prioritises responsiveness and smooth animations. JavaScript is the "fuck it, we'll do it live" way to construct UI, and stresses the relative performance of a single core more than competing approaches. Because JavaScript is, byte for byte, the most expensive thing you can ask a browser to process

that's fine. as an independent developer i don't care much for the management problems in large teams, so maybe this topic is not for me. i need to make the tradeoffs between engineering and product performance, development cost and client budget all by myself, and hence am looking to technical solutions to find the right tradeoff.

what i am missing on the technical side of the argument is how "fuck it, we'll do it live" relates to latency.

my expectation is that while device performance increases continuously and becomes cheaper, latency on the other hand does not improve as fast.

to put it drastically: people in rural africa or india have smart phones from the 2010s but internet connectivity from the 1990s

Re: The front end community wants to wash its hands of the decade we lost

#78

Post by cehrlich »

Existenceblinks wrote: post #76
cehrlich wrote: post #14

Earlier quoted context omitted.

Yeah, I think people who pretend that modern FE is possible without React or another similar framework haven't built a modern frontend and dealt with all the demands for interactivity that users have nowadays and the complexity this brings regarding rendering logic, state, etc. There's still a time and place for sending HTML and maybe a few tiny JS files down the wire, but for anything "application-like" it's just no…

There are a couple of full-blown text editors written in vanilla js so it's very capable of doing highly interactive.

Of course it's _possible_. If you go deep enough, React is just vanilla JS after all. The question is how fast a team can build and maintain something with each method.

Re: The front end community wants to wash its hands of the decade we lost

#79

Post by slightlyoff »

em-bee wrote: post #77
slightlyoff wrote: post #65

Earlier quoted context omitted.

OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor). More pithily, maybe PHP was good, actually? Popping up a level, this isn't about tools, it's about c…

so in essence your argument is that management needs to care about performance because most end users have devices that are not powerful enough to process all that javascript, based on this technical argument i found hidden in a footnote: JavaScript-delivered UI strips the browser of its ability to meaningfully reorder and slice up work so that it prioritises responsiveness and smooth animations. JavaScript is the "f…

Device performance has been growing in diversity as we approach smartphone saturation (the last couple of hundred million flipphones getting traded for https://infrequently.org/2021/03/the-performance-inequality-...

As this relates to latency, JS-mediated UI is slower to materialize for a host of reasons, not least of all the problems with getting it across the wire (as you note). Naive SPA designs tend to serialize what should be parallel (data fetching and shell setup). Getting better at this requires more sophistication, whereas teams that stick to basic HTML + light progressive enhancement tend to end up with simpler systems that are faster for light-to-medium session depths and are easier to diagnose/fix when things go sideways.

Re: The front end community wants to wash its hands of the decade we lost

#80

Post by Existenceblinks »

llamaLord wrote: post #16

As a PM, I’m used to being blamed for shit going wrong (it’s part of the JD). But c’mon… the state of modern FE development… that’s my fault too???

There was/is also a level of resisting against evidence too though. Like "I don't care performance I will use what I like". And find reasons to back subjective metrics claims, like hiring pool (catch-22 problem of demand & supply of type of workforce).
Post reply on HN