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

The Frontend Treadmill

polotek.net

Post reply on HN
Print view View original

51–60 of 722 posts

Re: The Frontend Treadmill

#51

Post by ForTheKidz »

wbobeirne wrote: post #44
ForTheKidz wrote: post #26

Earlier quoted context omitted.

Javascript doesn't have a good enough standard library to execute on this. You need frameworks just to patch up the runtime (or otherwise avoid the holes). Last time I checked they didn't even have decent hashmap or set implementations (let alone decent serde support).

This was true in the lodash and jquery as essential days, but hasn't been the case for years. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Ah, I stand corrected. I have more recent examples but I struggle to recall them. Map and Set were certainly the two largest absences I remember.

Re: The Frontend Treadmill

#52

Post by only-one1701 »

The biggest problem by far with the frontend ecosystem is that it assumes everyone's been writing perfect frontend code which makes deprecation/migration a breeze. Frontend is much more forgiving then backend, which means you can write absolute dogsh*t and have it not be discovered for years. This compounds, unfortunately, and when it comes time for breaking changes in a new library or framework versions, I think the authors of these versions don't understand how bad it is in the average frontend trenches. So more bad code is written to patch over existing bad code, and the cycle continues. Gets worse, in fact.

Re: The Frontend Treadmill

#53

Post by donbrae »

I wonder whether AI being the new and shiny thing will lead to a reduction in ‘innovation’ in front-end frameworks. Front-end dev seems to me to have been a solved problem for years now, yet there are still new ways of doing things for marginal gains. I personally just use vanilla JS (having never built anything Facebook-scale which would necessitate using a tool like React) and would be happy if instead of working on yet more front-end stuff, folk will otherwise build something AI-related, both because that is where the hype is but also because it’s genuinely exciting.

Re: The Frontend Treadmill

#54

Post by zwnow »

antirez wrote: post #9

To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScript only when needed, no separation between backend and frontend folks in the company.

Yea people should just learn Elixir/Phoenix and forget about all their npm js issues...

Re: The Frontend Treadmill

#55

Post by francasso »

I think this THE main reason why many people are getting fed up with javascript heavy frontends and switching to technologies like htmx.

Personally I stick to json to feed data to my frontends, but I gave up on "frameworks" a while back and just implemented my own abstractions on top of vanilla js and the dom and have been happily using them for years. If you work in large teams with people that don't care so much tough, that would also have drawbacks.

Re: The Frontend Treadmill

#56

Post by larrik »

MrBuddyCasino wrote: post #30

Feels like an article from 2015, where churn was still enormous. Today we have more stability: mostly React, Angular is also still around, some novel approaches like Svelte or HTMX, but mostly its the reactive paradigm packaged in different ways (eg Vue.js). No XHTML, no IE6, heck not even IE. CSS converges on Tailwind. What is unsolved is the dependency hell: builds break over time, just by NPM rot.

Meanwhile, my team has been trying to upgrade a large app from vue2/nuxt2 to vue3/nuxt3, which has no real upgrade path at all.

Oh, and the time between nuxt3's prod release and vue2's EOL was like 9 months.

Vue 3 IS better than 2, but at what cost?

Re: The Frontend Treadmill

#57

Post by only-one1701 »

conorbergin wrote: post #27

When I made my first website I read things online like "svelte is better than react" and "solid-js will be the next big thing", and I thought this was an important part of web development. Newbies should read MDN and ignore everything else.

React's been around long enough and is dug in deep enough to have decent ROI on knowing fairly well, but the recent obsession with Next.js and SSR...maybe not. Privately I think this might be their undoing.

Re: The Frontend Treadmill

#58

Post by 8s2ngy »

I have given this a lot of thought, and I haven't been able to come up with any reasonable long-term solution that avoids major refactors or swapping out libraries and tools. I am leaning toward pairing React with React Router for creating server-side rendered web apps. My thinking is that React has "won" the JavaScript wars, maintaining its popularity consistently over the past decade, and React Router is one of the most downloaded libraries for React. (At this point, I’ve come to terms with the fact that React Router will likely introduce breaking changes in its next major update, as it has done many times in the past.)

Re: The Frontend Treadmill

#59

Post by only-one1701 »

crab_galaxy wrote: post #34
olliepop wrote: post #8

Earlier quoted context omitted.

Component lifecycle methods to hooks and HOCs, does that ring a bell?

Class components and HOCs aren’t deprecated though.

They're very much not "best practices", and will be deprecated soon (if they're not already).

Re: The Frontend Treadmill

#60

Post by fragmede »

mplanchard wrote: post #43
fragmede wrote: post #33

Earlier quoted context omitted.

Wait, we're supposed to use pnpm now? What happened to yarn? What's wrong with npm? I stop paying attention for six months and even the installer has changed. What's an npx?

Right??? I started out the process trying to stick with yarn and upgrade it to use plug and play for better CI caching, but svelte apparently just does not work with it and will not do so, so I started looking into pnpm.

Meanwhile, I had to do some backend thing yesterday, and ended up using the LD_LIBRARY_PATH trick, which was introduced in 1988.

I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.

Post reply on HN