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

121–130 of 722 posts

Re: The Frontend Treadmill

#121

Post by aaronbaugher »

Eric_WVGG wrote: post #105
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?

I think it’s because, on a fundamental level, we have been trying to wedge an app platform into a document reader. Zoom out and think about how mad this is. Like if we tried to build “Web 2.0” inside Adobe Acrobat Reader. Apple has prescribed front-end frameworks like AppKit and UiKit and now SwiftUI, Linux had Gnome and GTK and whatever (I’m not an expert and my knowledge here is out of date)… there’s never been a C…

Absolutely. It took me a while to realize that I hated web development and why: because of all the layers of stuff you have to deal with on top of that document fetching platform. Something as simple as maintaining a login session is a complicated problem, even before you get into validating users, single sign-on, etc. You can put a lot of that out-of-sight/out-of-mind by letting a framework deal with it, but it's still there, lurking, waiting to bite you. And that's just one small aspect of building a web app.

It's too bad Java sucked so much. Maybe we could have had applets that worked like desktop apps, keeping the app-type stuff within applets and leaving the document reader alone. Probably not.

Re: The Frontend Treadmill

#122

Post by diggan »

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…

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 that's OK.

I think what I was trying to get across is that "npm install lib" carries a far bigger cost than most people realize, just because it gets hidden behind "our code" while in reality, as soon as you include a library/framework into your own codebase, you need to see it as "our code" immediately.

Re: The Frontend Treadmill

#123

Post by Secretmapper »

fragmede wrote: post #33
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…

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?

`pnpm` was released back in 2016. It's 9 years old at this point.

I think part of the problem is this thinking that

- you must change things all the time (yarn is still good why switch?)

- the things you change to are somehow really new (pnpm is 9 years old)

Re: The Frontend Treadmill

#124

Post by zero_shift »

only-one1701 wrote: post #59
crab_galaxy wrote: post #34

Earlier quoted context omitted.

Class components and HOCs aren’t deprecated though.

They're very much not "best practices", and will be deprecated soon (if they're not already).

I'm not aware of any indication that class components will be deprecated.

Re: The Frontend Treadmill

#125

Post by croes »

only-one1701 wrote: post #57
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.

React's been around long enough and is dug in deep enough to have decent ROI on knowing fairly well, but the recent obsession with Next.js and SSR...maybe not. Privately I think this might be their undoing.

Which version of react?

Hooks or classes?

Or whatever comes next.

Re: The Frontend Treadmill

#126

Post by ctrlp »

Much of the tech churn in frontend is likely attributable to it being an entry door for beginner coders over other pathways. Most of us got started in web dev and made big messes using frameworks we didn't understand. So e of us got better and changed the framework to make it more x, y, or z. Some decided, I'll build my own that doesn't have those x, y, z problems. And so here we are. TBD if HTML standards can ever replace this cycle.

Re: The Frontend Treadmill

#127

Post by ludicrousdispla »

rambambram wrote: post #95

Good read and I agree fully. Also been doing webdev for 20+ years now and I'm still very happy with the CHAMP stack. CHAMP of course standing for: CSS, HTML, Apache, MySQL and PHP. As you can see, there's no J in CHAMP. I have been doubting my choice in the past, because everybody was using (frontend) frameworks and the like and I'm just a social animal like everybody else. I'm happy I stuck with the stuff I already…

After developing applications using native windowing toolkits for over fifteen years, I looked at React briefly in 2015 and have avoided it since. Currently working on several HTML+CSS proofs of concept to support interactive UIs.

Re: The Frontend Treadmill

#128

Post by zero_shift »

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?

It doesn't. It's just a meme. React has been around for eleven years now, and complaints about frontend churn started with the Angular 2 announcement (in late 2015)

Re: The Frontend Treadmill

#129

Post by megous »

Kerrick wrote: post #115
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?

Hmm... React, Backbone, jQuery. SwiftUI, AppKit, Cocoa, Carbon, Toolbox. WinUI 3, UWP, WinRT XAML, WPF, WinForms, Win32 GDI. --- Of course this is misleading, because React has had so much internal churn. But desktop toolkits also have churn.

You left out other 150 major web frameworks.

Re: The Frontend Treadmill

#130

Post by MrJohz »

fragmede wrote: post #33
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…

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?

npm is not deprecated and is a pretty good choice. pnpm is a bit nicer in some details, but it's a nonstandard tool - use it if you're familiar with frontend development enough that you understand the tradeoffs you're making, but otherwise sick with npm.

npx is a tool bundled with node/npm for running commands in isolated environments. It's mostly useful in two situations:

* You want to run a particular NPM-distributed tool as a one-off, and have the tool installed outside of your current project and then uninstalled afterwards. This can be useful for scaffolding or trying out tools released using NPM.

* You have a local project and one of the dev dependencies provides a utility to e.g. lint the code or run a migration. npx allows you to directly call commands installed locally without having to set up `npm run` beforehand.

If you don't know why you need it, you don't need it.

Post reply on HN