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

161–170 of 722 posts

Re: The Frontend Treadmill

#161

Post by Aurornis »

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’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc.

I’m amazed at how much of this is driven by the FE influencers. The FE world has embraced social media, YouTube, and even Twitch to a degree that I haven’t seen in other domains.

Influencers in these areas need to have a constant stream of fresh material to stay relevant, so they’re always driving toward something new that they can produce content about.

This is in addition to the very active conference circuit. FE and JS conferences feel like one big competition to present on some hot new topic.

There’s also a huge market for selling FE courses. These course creators need you to convince your boss to approve a $700 (limited time price!!!) video course to learn the new hot thing, but they can only do that if they get the industry to move away from the old thing that everyone knows already. So they push hard to drive the new thing and deprecate the old thing.

Re: The Frontend Treadmill

#162

Post by yawnxyz »

conorbergin wrote: post #27

When I made my first website I read things online like "svelte is better than react" and "solid-js will be the next big thing", and I thought this was an important part of web development. Newbies should read MDN and ignore everything else.

> Newbies should read MDN and ignore everything else.

I think people forget how inaccessible it is for a newbie to start writing pure javascript directly from the API reference.

People need tutorials and walkthroughs, and need to build a an internal understanding of how these all work.

Frameworks help them abstract all that

Re: The Frontend Treadmill

#163

Post by 0x000xca0xfe »

lelandfe wrote: post #153
0x000xca0xfe wrote: post #120

Earlier quoted context omitted.

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

I know, I've had to revive and make small changes to an old Angular project myself. Which is my point.

If the underlying technology hasn't really changed, why constantly break the tooling and compatibility in general?

This collective lack of discipline is exactly why I don't work in FE. It's just tiresome for no actual reason.

Re: The Frontend Treadmill

#164

Post by dewcifer »

Front-end dev of 20+ years. Plenty of back-end and full stack work in there too. While I definitely agree with the sentiments in this article, I feel it is a bit more nuanced a conversation than this.

While you can truly swap out the UI and ultimately the front-end doesn't matter if the back-end isn't solid long-term - you can equally swap out/automate/just install a rock solid back-end framework, just like you can a front-end.

Furthermore, the front-end is the single thing that customers/users typically interact with - which makes it drastically more important than is let on in the article. We were recently doing a book study on measuring UX and I am pretty convinced that the way people feel about a thing is more important than how well it functions.

I don't really even call myself front-end or back-end anymore.. to be honest I'm not sure it's as useful of a distinction as it has been in the past. Both aspects of an app need to be solid and also bespoke to a degree imo.

Re: The Frontend Treadmill

#165

Post by swatcoder »

DanielHB wrote: post #106
diggan wrote: post #86

Earlier quoted context omitted.

> Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas. The thing is, it's totally possible, but it requires restraint and properly caring about what you pull into your project. Back in the vanilla JS/jQuery days, when I got started, our "dependency management" was basically copy-paste .js files into a `vendor/` directory. Then nodejs/npm appeared (and bowe…

> But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun. This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC mone…

> backed by a SasS service and VC money

While it's valid to distinguish this from "FOSS volunteers working for fun" in a narrow sense, I hope most here recognize by now that this is a very big red flag in exactly the same way.

A highly ambitious business soliticing VC funds will not be prioritizing the stable, long tail support for the boring little users that most of us represent.

By necessity, in their best times, they'll be chasing rocket launch opportunities that may rapidly pivot strategy, and in their worst times, they'll find themselves hunting for costly efforts to prune.

The prior invites radical rearchitecture with deprecations and breaking changes, and the latter is how things just become dusty and abandoned (or -- if a backing service was involved -- wholly inoperable).

If you want your original code to hold up for 3 and 5 and 10 years with zero/light maintenance so you can focus on emerging opportunities ofyour own, rather than endless maintenance churn, (it's reasonable that you might not need this) these "SaaS businesses with VC money" need to be seen as the pied piper luring you into the dark wood.

Re: The Frontend Treadmill

#167

Post by mardifoufs »

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?

Are you using QT 1.0? I don't think any (updated) desktop GUI from 30 years ago has stayed backwards compatible. So yes frameworks like QT are from 30 years ago but they are entirely different from what they used to be back then. Except for maybe some winforms stuff?

Re: The Frontend Treadmill

#168

Post by DanielHB »

diggan wrote: post #122
DanielHB wrote: post #106

Earlier quoted context omitted.

> But already at that point, a lot of us questioned the idea of owning thousands of hidden lines, rather than explicitly owning those, and outsourcing everything to volunteers who basically do FOSS for fun. This is not quite accurate, the libraries you see the most complaints about are the most popular libraries around. OP specifically complained about Apollo which widely used and backed by a SasS service and VC mone…

Yeah, fair enough, you're right, a lot of the churn is created by companies who do FOSS too. But I think the original point stands regardless of how popular the library is, or who is backing it. Just because Facebook today cares about React, doesn't mean I'd implicitly trust them to care about it for as long as I want to care about my own project, and I certainly don't trust their use cases to always match mine, and…

I agree with you, but I think the liability of a dependency is FAR higher if it has a peerDependency to another dependency.

For example, react-router has a peerDependency with react, therefor the liability of adding it to your project is much higher because you can have both of these scenarios:

1) Can't update react without updating react-router because react deprecated some API

2) Can't update react-router without updating react because the new version of react-router is using some new API from react

And it drives me insane that people will just add react-random-small-thing from github handle @NotGoingToMaintainThis. These kinds of small dependencies with peerDependencies to core libs are the devil.

I am not opposed to using dependencies, but your project needs to pick a few core dependencies and stick with them...

Re: The Frontend Treadmill

#170

Post by hajile »

zwnow wrote: post #108
incrudible wrote: post #76

Earlier quoted context omitted.

> The Web needs true change. Here's how that works: Make something better and get people to adopt it. "The web" isn't set in stone, it's a series of tubes. Be warned though, odds are you will fail to gain traction because while we all agree that the web sucks, we all disagree on what the change should be. I for one have the complete opposite take regarding Javascript. Just give up on the web as a declarative document…

How will you scale your take on this? We are currently facing incredible scaling issues and complexity in web dev because of js based systems. Meanwhile companies that ditch js have great success (whatsapp, discord, ...) Js in the browser is fine, but with node and Nuxt or Next we now have it where it doesn't belong.

The big problem with scaling JS on the server is threading. There's simply no way to do it. You can spin up multiple processes, but then the communication overhead gets you.

The spec committee needs to bake in actors and they need to add tuples/records so sharing data across actors is easy and free. Finally, Typescript needs to bake in a warning to tell you when your code is going megamorphic so you can change it so the JIT can actually optimize for you (I think most JS devs would be shocked to find out just how much of their code is incapable of ever getting advanced optimizations).

Post reply on HN