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

331–340 of 722 posts

Re: The Frontend Treadmill

#331

Post by KronisLV »

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…

The other day, I needed to quickly whip up an internal dashboard with some dynamic logic. Being somewhat lazy, I just imported jQuery and some additional scripts for it, one of the small CSS-only libraries for basic styling, put all of the custom code in a single JS file and that's it.

No toolchains. No build process. No learning about any particular way of doing state managing or rendering or what have you. Just some files and some code.

It was delightfully simple. For bigger projects I do think that the likes of Vue strike a nice balance between features and usability, but I've also seen a lot of messing around with toolchains and package versions (or even stuff like needing to migrate away from AngularJS), sometimes it's nice to avoid all of that when you don't need that complexity.

Re: The Frontend Treadmill

#332

Post by AgentME »

toddwprice wrote: post #227

I also miss the web. When HTTP form posts were a thing. React and friends are desktop apps, delivered over HTTP, where the browser is the runtime. You know why we got so obsessed with JavaScript? Cause screen refreshes look janky. "Just use XMLHttpRequest to send the data ONLY over the wire! And get data ONLY as a response!" That's how we got into this mess. I'm not saying you don't need JavaScript, or there aren't r…

It's weird to see React frequently treated in these kinds of discussions as the opposite of the good-old ways of doing things because React has great support for server-side rendering and form posts. Its server support was one of its major features that initially distinguished it from other front-end frameworks of the time and helped lead to its popularity.

Re: The Frontend Treadmill

#333

Post by bdlowery »

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.

Re: The Frontend Treadmill

#334

Post by pttrn »

guybedo wrote: post #244

LLMs are a huge win in that regard. I delegate most of my frontend tasks to Claude Code, no need anymore to waste hours understanding why the latest version of framework xyz isn't compatible anymore with library abc. Also, it feels like there's way more boilerplate code, repetitive tasks in frontend land, once again my buddy Claude Code can generate UI components html and typescript code 100x faster that i can

“I just fuck around til it works”

Re: The Frontend Treadmill

#335

Post by mplanchard »

jdauriemma wrote: post #327
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…

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 graphql codegen options would be more similar, but after about an hour of trying to figure out how to get it to generate approximately the same output I gave up.

I’ve worked around it for now by using `pnpm dlx` to use the old apollo CLI without having it as part of the actual package dependencies.

Re: The Frontend Treadmill

#336

Post by uhoh-itsmaciek »

nullpoint420 wrote: post #310
flufluflufluffy wrote: post #266

Earlier quoted context omitted.

I find Remix really nice to work with, it’s a framework that embraces and utilizes web standards (what the article is arguing we should get back to doing more), and I’ve learned everything I know about it (and the majority of everything else I know about front end dev) for free. It’s not like you need to purchase courses to learn. At the same time, I don’t think there’s anything wrong with selling courses to teach pe…

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

But this "The web was perfect in 1999--stop changing things!" take is tedious and intellectually lazy. (I'm not accusing you of it, but it's certainly a common sentiment.)

We should be working together to solve concrete problems, and avoid both chasing the latest fads and pretending there's no room for improvement.

Re: The Frontend Treadmill

#337

Post by whstl »

MrBuddyCasino wrote: post #78
larrik wrote: post #56

Earlier quoted context omitted.

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?

At least when Vue 4 rolls around, you can pay Claude Code to do it for you (for a modest fee ). Btw what made you choose Vue over React?

Not GP but if I were to start a project today that needs an SPA I would go Vue rather than React 100%. Or if you want to be trendy, something like Solid or Svelte are also ok.

React is okay-ish when done in moderation but it becomes spaghetti too quickly when the team is not made of 10x ninja rockstars from space. It is particularly bad for startups, you either slow down with code reviews or pay the price. The main reason IMO is the reactivity mode. Too many footguns to watch out for.

Plus, the quality of third-party React packages is abysmal. What a terrible ecosystem. Using as few dependencies as possible makes it better, but it's hard to push back on larger teams.

In the end it's all about opinion of course but after 10 years going back and forth between both (hey I'm trying to stay employable) that's my experience.

EDIT: But if I had to do SSR I would avoid Javascript period. Lots of backend languages are better for SSR.

Re: The Frontend Treadmill

#338

Post by ewzimm »

bloomingkales wrote: post #322
cpursley wrote: post #308

Earlier quoted context omitted.

And what have you put out into the world?

I push back on stuff like this so developers who feel the feet on their throat from this culture can have some confidence to nudge the boot off. There goes my hero: https://youtu.be/EqWRaAF6_WY

I can tell you that your response is at least relevant for me because I happen to be working with Remix right now, not because of any influencers but just because I happen to be working on a Shopify project. I've seen lots of frameworks come and go and evolve, so I'm not surprised that this one changes a lot, but I always enjoy getting opinions from people with experience. Whether or not I'll end up resenting it in the future, I don't know, but at least I'll have been warned.

Re: The Frontend Treadmill

#339

Post by mplanchard »

schindlabua wrote: post #110
mplanchard wrote: post #92

Earlier quoted context omitted.

I agree you can avoid it with care, but I do think it's a JavaScript problem, at least moreso than in other languages. The culture is one of acceptance of churn. It seems like everything from minor libraries to major frameworks is much more likely to introduce a breaking change in JS than in Rust, C++, or even python. I've never written any emacs lisp that I had to change when upgrading emacs, and the third-party lib…

And I think the Javascript problem exists because frontend/UI is just a very complicated domain, in the sense that frontend is a big messy ball of side effects. If you've been around and saw the web grow up, and saw all the new ideas all those libraries brought to the table (jQuery deferreds becoming async/await, 960 grid slowly morphing into flexbox and css grid, etc etc) then all the breaking changes make sense, we…

I’ve been writing JS since the PHP and jquery days, so I’m not unfamiliar. I understand these libraries are doing complex things, but they also seem to love churning for churn’s sake (react hooks is an example, svelte v5 is another, eslint entirely deprecating their old config format is yet another).

I don’t mind learning or using a framework to do complicated things. I mind when the ecosystem as a whole makes it so much harder to get real work done and instead forces everyone to do busywork like switching tsconfig to eslint, then switching eslint config to the new flat format.

Re: The Frontend Treadmill

#340

Post by jchw »

moooo99 wrote: post #317
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…

> And Angular might eventually run out of steam, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together. I think this is true but also misses some aspects. Take Angular as an example. Angular1 and 2 cannot be compared at all, they were basically nothing alike except for the name. This burned many developers. But Angular itself is also changing quite drastically. Not…

I agree with Angular 2 not really being the same as Angular 1. Angular in general was a lot less stable, pushing API breaks inside of release candidates and generally just playing fast and loose with things. That said, there was a migration path to go from Angular 1 to 2 incrementally. It wasn't fantastic, but if you had a large Angular 1 app, it was absolutely better than rewriting the whole damn thing.

Angular took a while longer to become more stable. React considered all of its early releases to be 0.x releases, until (I believe) 0.14 -> 15.0, at which point I'd certainly consider React fairly stable. Angular, meanwhile, was kinda unstable until I'd say around v4. Which to be honest, was still a while ago (Google says 2017) but it does bear mentioning.

> React hat a major paradigm shift with the advent of functional components and hooks. They were compatible, but very different from another.

The thing is, functional components are not new. They were a part of React 10 years ago, before React was formally considered stable. I do think hooks came a bit later, but it wasn't that much later. I know that many early React clones supported stateless functional components pretty early on.

And yes, compatibility is key. You can continue to use class components indefinitely. I don't think they have any plans to deprecate them any time soon.

Post reply on HN