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

341–350 of 722 posts

Re: The Frontend Treadmill

#341

Post by jdauriemma »

mplanchard wrote: post #335
jdauriemma wrote: post #327

Earlier quoted context omitted.

Hi there - I work at Apollo and I'd be happy to help you migrate off our old CLI. That utility was sort of a hodgepodge of tools that we ended up either replatforming to our `rover` CLI or, in the case of code generation, recommending that folks use GraphQL Code Generator. It's a testament to that utility's sprawl that I can't guess your use case just by your name-drop of it. I realize the irony in my saying that sin…

I appreciate this! It is the codegen part, but because it’s in a repo that mostly is just getting bugfixes until we eventually subsume it all with something newer, it’s hard to justify the time spent to migrate to a different tool. The issue I was having with pnpm was that it wouldn’t install the apollo CLI tool due to its having set a required node version that is now quite old in its package.json. I was hoping the…

That's a start! Forgive me, I'm heading into a meeting but I want to share some resources with you. It's close to the end of my day so I'll check back in the morning. If you prefer to continue the conversation on another platform, I'm happy to exchange emails or Discord handles. Also consider posting at community[.]apollographql[.]com, the Apollo Client team tries its best to respond to everyone who asks for help there. Any code snippets would be helpful to illustrate observed vs. ideal state when migrating.

Re: The Frontend Treadmill

#342

Post by mplanchard »

rcleveng wrote: post #294
homebrewer wrote: post #278

Earlier quoted context omitted.

pnpm saves a lot of disk space by reusing packages and hardlinking (or reflinking if your filesystem supports that) from a single global directory. It's fully transparent for you. Optionally, it can also use a strict mode (or whatever it's called) where you can only access packages that are explicitly mentioned in your dependency list. Really helps with preventing you from accidentally creating unexpended ties to you…

Cool, thanks! I've not anything this succinct between them before.

I agree with their assessment. It uses some nifty storage tricks and I really appreciate the ability to know when packages are accidentally depending on dependencies they haven’t declared.

Re: The Frontend Treadmill

#344

Post by mplanchard »

gedy wrote: post #99
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…

> it seems like literally everything is deprecated I know you mentioned a company-backed example, but bear in mind most open source libs are given away and maintained for free. After a certain point people move on, so basically what do you expect to happen. I created and maintained a couple libraries for 5+ years and it didn't really help my career or life in any way - no job offers, didn't matter to interviewers, so…

Ya for sure, I’m not ragging on the small library devs. Mostly that’s not where the problem is anyway, because they tend to do a small subset of things reasonably well and so there’s not a lot of reason to change.

Re: The Frontend Treadmill

#345

Post by jchw »

bdlowery wrote: post #333
jchw wrote: post #145

> Whatever framework you choose will be obsolete in 5 years. I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam…

Svelte will never overtake react. It won’t even overtake Vue.

Honestly, I don't even really care that much which frontend library wins, and I've been mostly happy with React as a foundation to build off of. If the future is some Rust-based framework compiled to WASM, that's ultimately fine with me. Just as long as whatever it is is relatively performant and stable and doesn't add 1 megabyte of code to every pageload.

Re: The Frontend Treadmill

#346

Post by whstl »

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.

I agree 100%, but "JavaScript only when needed" is a loaded phrase. Especially when you don't have an engineering-centric culture.

Product/Design teams will kick and scream into getting you to add as much javascript tchotchkes as possible with zero regard for usability, performance, accessibility or good engineering.

Re: The Frontend Treadmill

#347

Post by mplanchard »

locallost wrote: post #135
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…

decides to swap out a working package manager for another for no apparent reason "Why do JS people keep doing something new for no apparent reason?"

The reason was that I was trying to use a newish feature of yarn (plug and play) to improve CI caching. However, it refuses to play nicely with svelte. pnpm provides similar benefits but works with svelte.

Re: The Frontend Treadmill

#348

Post by bloomingkales »

uhoh-itsmaciek wrote: post #336
nullpoint420 wrote: post #310

Earlier quoted context omitted.

But it _doesn't_ use web standards. It has it's own mental model and gotchas just like any other framework.

It does. It bridges a purely server-rendered architecture with a SPA really nicely, and does it mostly with web standards. You don't need to run any client-side JS with a Remix app. It's not perfect, but there are a lot of benefits to its approach. I won't try to argue there's no front-end treadmill: there absolutely is, and I had to laugh reading the current top comment because I just had to migrate off Apollo CLI a…

It’s a nuanced topic. If we want to dive in, I can provide a glimpse into the first layer of the anus as we stick our head into it.

When we shepherded a lot of sheep into frontend via these courses and boot camps and quasi courses/bootcamps in the form of certain frameworks (hey, you only know this one framework?), we created a cohort of something.

Now what is that something? It’s not really the tinkerer that loves doing this stuff and would have found a way to express themselves (please pay attention to the word “express”, as in, can’t help it). That something was … a pragmatic identity. A pragmatic identity was formed where “I am now a software engineer because I and my cohort agree, we really know how to do our stuff”.

Such a cohort can only be fueled by identity, not passion. This cohort can’t innovate and must cling to the identity of their original accreditation, so they will always be defensive.

That’s the first layer of the asshole as we enter it, it goes deeper. The second layer involves large amounts of money and people’s livelihoods, to which they’d defend unto death.

Re: The Frontend Treadmill

#349

Post by 9dev »

codingdave wrote: post #174
jchw wrote: post #145

> Whatever framework you choose will be obsolete in 5 years. I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam…

Agreed, and I'd add that "obsolete" is a strong word. You can run an older framework for a long, long time. So long as people exist who know your stack and can be hired to work on it when needed, your stack is not "obsolete". "Dated", maybe. "Legacy" is also sometimes an accurate term. But until the day comes when nobody is left who will work on it, it is not "obsolete".

You can, but at some point things start breaking down. Your dependencies are all outdated and pile up CVEs (which you probably are contractually obligated to do something against.) The dev-tool extension is no longer maintained, and Sentry stops support too. You want to improve things by migrating to the new version or competing framework, but that requires lots of toil, since a lot of things changed in subtle ways or are done differently now, and that has ripple effects. Before you know it, you’ve spent four months playing the zero-sum game of rewriting your frontend. Finally you’ve made it, and then they release Tailwind 4.

Re: The Frontend Treadmill

#350

Post by daotoad »

namaria wrote: post #265
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.

I think you mean exacerbated

I get really exacerbated when people make this mistake.
Post reply on HN