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

151–160 of 722 posts

Re: The Frontend Treadmill

#151

Post by breadwinner »

> Whatever framework you choose will be obsolete in 5 years.

The mistake here is the assumption that you need a "framework". I challenge this notion. What does code that does not use a heavy framework look like? It is very maintainable and easy to use and will not become obsolete.

Here's an example: https://github.com/wisercoder/eureka/tree/master/webapp/Clie...

It uses two 500-line libraries, hardly a "framework". One for MVC/History and one for TSX.

The notion that you need React/Svelte/Vue/Angular is what is obsolete. All you need is VanillaJS.

Re: The Frontend Treadmill

#152

Post by gedy »

mangodrunk wrote: post #45
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.

Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.

> The BE / FE split has been a really bad experiment.

What do you mean - "full stack" is very popular and frankly produces some of this weird unmaintainable code. Hiring backend-y type people and making them develop UI (with state especially) is where half these companies realize "crap we need a front end developer"..

Re: The Frontend Treadmill

#153

Post by lelandfe »

0x000xca0xfe wrote: post #120
mplanchard wrote: post #2

I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines. The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated . Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally d…

And the craziest part is that it is built on top of JS/HTML which is an extremely stable technology at heart. 15 years ago I wrote a small (5KLOC) vanilla JS webapp that is still in daily use by around 10 people without a single line changed. It held up better then my Win32 applications! Almost all of the front end churn is simply a political/organizational failure.

This stability does mean that old React (or Knockout, or whatever) applications will still work just fine for the end users, likewise without a single line changed.

The instability is on the tooling side (and peer deps). Getting back into a project that uses Broccoli and Bower is a nightmare. And that was just a handful of years ago. You have to become a detective, finding what combination of package versions and Homebrew dependencies were expected on the last git commit date.

Re: The Frontend Treadmill

#154

Post by happimess »

gryn wrote: post #109
mangodrunk wrote: post #45

Earlier quoted context omitted.

Well said. The BE / FE split has been a really bad experiment. It has exasperated the issue where the FE is overly complex because there are people on a FE team, so they toil away and just add complexity. It is also problematic that we have so many people who only know web development and nothing else.

As someone who's been on teams/products that did away with the front/back separation back in the php era I think that's a terrible idea. When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger. I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c proc…

I think you're conflating the coders with the code. I read the upthread comments as advocating against dedicated FE/BE coders, not against dedicated FE/BE code bases.

Of course you want your embedded C separate from your CSS! The critique, I think, is that you don't want a front end team, because if your front end is in good shape, then they'll change things just to keep busy.

Re: The Frontend Treadmill

#155

Post by jollyllama »

francasso wrote: post #55

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 to…

Yup. The Frontend ecosystem juice isn't worth the squeeze unless you've got a full time team of software devs on your project. Better to ditch NPM etc. and go with HTMX.

Re: The Frontend Treadmill

#156

Post by 8n4vidtmkvmk »

fragmede wrote: post #33
mplanchard wrote: post #2

I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines. The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated . Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally d…

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?

No, we're past pnpm and on to bun now

Re: The Frontend Treadmill

#157

Post by upghost »

The article mentions "web fundamentals" and "getting back to the fundamentals". Sounds great! Would anyone care to have a conversation about what this means? Like does the author mean DOM manipulation or TCP stack? I feel like this is pretty broad and even though I've been doing full stack for a bit now I'm suddenly not sure if I know the fundamentals.

Re: The Frontend Treadmill

#158

Post by ilrwbwrkhv »

ForTheKidz wrote: post #19

Why does FE development have such churn? Desktop toolkits from 30 years ago work just as performantly today; what is so difficult about the browser that demands constant framework updates?

Noobs. Almost all typescript devs and React devs and especially NextJs devs are terrible programmers and absolute beginners. So that creates churn.

Re: The Frontend Treadmill

#159

Post by uoaei »

mplanchard wrote: post #2

I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines. The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated . Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally d…

My conspiracy theory is that FE engineers do this on purpose for job security. Otherwise there simply wouldn't be enough work to justify headcount and salary. Of course there's very few actually devious people who do this on purpose, but who among us hasn't thought "tickets are light this week, how about if I upgrade xxx or yyy?"

Re: The Frontend Treadmill

#160

Post by taeric »

mplanchard wrote: post #2

I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines. The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated . Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally d…

Fully agreed that the amount of "that was last year's answer" is obscenely frustrating.

Would be one thing if there were minimal boilerplate for the options, but so many patterns are quite involved.

Post reply on HN