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

351–360 of 722 posts

Re: The Frontend Treadmill

#351

Post by 230nanometers »

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…

One of many reasons I left FE jobs. I'm tired of spending my evenings discovering what refactor I'm gonna have to do next.

Re: The Frontend Treadmill

#352

Post by niccl »

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…

but it doesn't seem to happen the same way in other parts of the programming world. Even in Django, yes, there are squillions of libraries for different things, and many of them haven't been updated in years, but the long-lived ones don't tend to have breaking changes in (at least in my experience). It just seems to be front-end stuff where people will make breaking changes in some long-lived package, and for no obvious reason.

Make a new package, or a distinctly different version of the original package that won't get imported by a simple upgrade.

Or am I missing some reason that it's not as simple to do this in front-end stuff as it is in other areas?

Re: The Frontend Treadmill

#353

Post by skydhash »

hajile wrote: post #93
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…

There's a disconnect between how a computer wants to do things and how a human wants to do things. This disconnect isn't so noticeable on the backend where the problems are generally related to scaling (as there isn't a generalized solution). On the frontend though, this disconnect is everything. This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules. This le…

> This leads to a tension between devs wanting to abstract and everything constantly breaking the abstraction rules.

This exists everywhere. But the churn only exists in the NPM section of the JavaScript world. QT, SDL, GTK, Cocoa have very stable paradigms to do UI. Even the DOM api is stable. But in the NPM world, nobody wants to actually stick to an API, instead they insists on supporting edge cases that should actually be an extension or another library.

Re: The Frontend Treadmill

#354

Post by squidsoup »

adamtaylor_13 wrote: post #172

I have fallen in love with the simplicity of Rails recently. Sprinkle a bit of stimulus where you really need it. Hell slap a turbo here or there. And other than that? Pure HTML. It’s downright lovely. And it’ll still work fine 20 years from now.

Sure, but then your company grows large enough to want its own design system, and you have multiple applications that need shared components. How do you implement that in rails?

Re: The Frontend Treadmill

#355

Post by dpcx »

Illniyar wrote: post #313

I love it when people phrase this as a frontend problem. It's not a frontend problem. It's just a "it's a huge ecosystem with new players" problem. I've seen this in Java 15 years ago when it was the front of innovation (I can name dozens of frameworks, and a half dozen build systems coming out in as many years). React 17-18 is quite a minor change then perl 5->6 or python 2->3 For backend instead of "let's use this…

React has been around for 11 years. The amount of stuff that's online that tells you to do something with it one way when the react devs tell you to do it another is _astonishing_. And that's just from the last few years.

Or take webpack that's been around for 13 years. The way things are set up even within the last few years have changed dramatically.

If Apache configs moved as much as these systems did, no one would use Apache.

Re: The Frontend Treadmill

#356

Post by pier25 »

It's not a frontend problem but a JS-ecosystem problem. Happens in the backend too.

The JS landscape is an absolute mess where dependencies have dozens if not hundreds of other dependencies. As an example, this is the dependency graph of Platformatic (a Node framework based on Fastify):

https://npmgraph.js.org/?q=platformatic#zoom=h

Each of those dependencies could be abandoned at any moment. Even huge dependencies like Axios or Express seemed to have been abandoned at one point.

And then each dependency is ruled by whatever their maintainers think is right. Just the other day a dependency I use in prod with aprox 25M downloads per week (React is aprox 26M) and used by 10M Github repos decided it was ok to drop support for Safari versions from about 3 years ago. It's just insane considering Safari has +50% mobile market share in the US.

Re: The Frontend Treadmill

#357

Post by uhoh-itsmaciek »

bloomingkales wrote: post #348
uhoh-itsmaciek wrote: post #336

Earlier quoted context omitted.

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…

I don't believe you want to have a productive conversation about this. It sounds like you just want to be angry.

Re: The Frontend Treadmill

#358

Post by AgentME »

dekhn wrote: post #212

I've proposed an idea several times that I think might resolve this situation, but it's never received any real uptake and I can see some serious issues with the approach. Instead of building a "inner system" ( https://en.wikipedia.org/wiki/Inner-platform_effect ) where the browser uses HTML, CSS, and Javascript to create interactive applications, or attempting to make a sandboxed and highly limited execution environ…

Browsers like Chrome already allow you to install websites that support it to your computer as a desktop app, and a page can already fill itself with a canvas element to allow itself to be programmatically in charge of all the pixels in it. What you describe sounds like a more limited version of what we already have today, other than the suggestion that this should be a responsibility of the OS.

Re: The Frontend Treadmill

#359

Post by skydhash »

bullfightonmars wrote: post #255
qudat wrote: post #233

Earlier quoted context omitted.

This comment is steeped in bias. The front end is not complex for its own sake, it’s complex because APIs are needlessly rigid: https://bower.sh/front-end-complexity

Delete the API, render your html on the server, problem solved.

If you're not building something like Gmail, Docs, or Figma (AKA an app that should be on the desktop instead of the web). Rendered HTML should be the way to go, even if it's just a gateway to a more complex infrastructure.

Re: The Frontend Treadmill

#360

Post by [deleted] »

bloomingkales wrote: post #215
ewzimm wrote: post #171

Earlier quoted context omitted.

That's fascinating, and I had no idea web dev influencers were so big. I checked, and there really are people with millions of followers doing development. Personally, the idea of learning anything related to coding through a video is extremely frustrating. It's a text medium. I want to look at things, take time, think it over, compare code, follow references, look up functions. That people like video formats isn't r…

Here's one: https://remix.run/ These grifters sell entire courses on the product, that's their game. So when you find an unmaintained Remix app at your company, well, the grifters got the ears of your junior devs :( And they just promote it and promote it: https://kentcdodds.com/blog/a-review-of-my-time-at-remix https://kentcdodds.com/blog/why-i-love-remix https://kentcdodds.com/courses Pure grift. But since most peo…

[deleted]
Post reply on HN