Live data from Hacker News

The Frontend Treadmill

polotek.net

41–50 of 722 posts

Re: The Frontend Treadmill

#41
I've seen this so many times already, going from server-rendered web apps to client-side rendered web apps in React, then through multiple generations of state management and component management strategies in React, then back to server-side rendered stuff with Next.js, it is so tiring.

Re: The Frontend Treadmill

#42
The counterpoint is that if you don’t adopt a framework you end up with a “framework” you built yourselves that people outside your team don’t understand, is generally poorly documented and needs constant work to add features existing frameworks already have. There are common features needed on the FE and common problems to solve, why not at least start with something instead of nothing?

Re: The Frontend Treadmill

#43

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?

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.

Re: The Frontend Treadmill

#44
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.

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...

Re: The Frontend Treadmill

#45
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.

Re: The Frontend Treadmill

#46
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.

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).

No regular frontend needs any of that. Serde support, that's a ridiculous requirement for painting some web boxes on a display.

Plus, as the other comment noted, the basic JS types go a long way now.

Re: The Frontend Treadmill

#48

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?

Yarn is still great. npm is ok. pnpm is a little faster than Yarn but has less features.

Re: The Frontend Treadmill

#49
We have a jquery/Razor front-end that has a ton of global JS state manipulation and a file called 'common.js' which is a dumping ground for almost any function used in two places regardless of what it does. Many things are reinvented wheels (badly) and the previous team left a ton of XSS vulnerabilities in on top of that. Language differences from the previous offshore team mean things are named strangely to me, but even then, there's sometimes bad names for variables and functions.

Does it still function? Sort of. But most of our bugs are front-end issues because it's difficult to reason about any of the control flow. It isn't just obsolete or an unpopular framework, it's bad code.

There's no way I'm going to stay quiet about rewriting something like that if I want to stay at the company (spoiler: I'm quiet about it) and I don't think anyone else should be quiet about it either. This shit causes stress.

Re: The Frontend Treadmill

#50
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.

It's amazing what CSS can do these days.

I'm working on a side project where one of my initial constraints was I wanted the entire site to degrade gracefully when JavaScript was disabled. This led me to a situation where whenever I wanted to add some function that would typically be done with JavaScript, I'd ask, "Can I do this without JavaScript?" To my surprise, the answer so far has always been yes. It's amazing what CSS selectors on basic HTML controls can do these days. There's still not a line of JS in that codebase.

Post reply on HN