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

101–110 of 722 posts

Re: The Frontend Treadmill

#101

Post by PaulHoule »

move-on-by wrote: post #18
breckenedge wrote: post #6

Earlier quoted context omitted.

That comes from the theme they’re using, and there’s a noscript directive immediately after it. https://github.com/Mitrichius/hugo-theme-anubis/blob/main/la...

Which is now deprecated and no longer receiving updates! Haha, that’s hilarious in context of the post. It’s also maddeningly frustrating as someone who regularly has to update things on awful frontend projects no one else is willing to touch. Frontend work is cursed.

If they weren't in that morass they'd be writing about how happy they are with Common Lisp or Pony or something.

Re: The Frontend Treadmill

#102

Post by hajile »

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).

You still can't add features like error boundaries in React without class-based components somewhere in your app. Even if they added these features to functional components today, it would be years before they'd consider them safe to remove.

HOC still exist and builtin features like `React.memo(MyComponent)` along with the like of more functional styles means they aren't ever going away.

Re: The Frontend Treadmill

#103

Post by zwnow »

fridder wrote: post #85
zwnow wrote: post #4

Based on the first paragraph alone, almost all devs I know think that a complete rewrite will solve all the issues, thats not only frontend but backend too. Web development in its current form is a beast and if we want true change we need to fix the biggest issue there is for all of webdev: Forcing everything into Javascript and incompetence. I wont claim I am competent, but at least I acknowledge that SvelteReactVue…

Basically we are in this scenario: https://xkcd.com/927/ Honestly though I think WASM might be the final state of the web.

I'd be fine with pure HTML Websites, just give me a way to make auth extremely secure.

Been ditching js based things outside of work and I'm really enjoying BEAM. It is puzzling to me why companies prefer having 200 microservices orchestrated with Kubernetes if they could have it so much easier by ditching js...

Re: The Frontend Treadmill

#105

Post by Eric_WVGG »

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 Correct Way to build a web app because the browser doesn’t have an Apple Microsoft or Linux Foundation, so we’ve been winging it all along.

I’m similarly tired of framework churn, NextJS server components might be the breaking point for me. But there’s no way I’m going back from component driven architecture, and I’m not sure what a vanilla js answer to a static site builder like Next (back when it was good) or Gatsby would be like.

Re: The Frontend Treadmill

#106

Post by DanielHB »

diggan wrote: post #86
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…

> 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 money. React also deprecates APIs quite often (although they are usually the more obscure parts of the API, the widely used stuff doesn't get deprecated nearly as often).

It gets worse when you add smaller libraries who do come from "volunteers who basically do FOSS for fun" because they often have peerDependencies with the big libraries but don't get updated as the big lib deprecates stuff.

Re: The Frontend Treadmill

#107

Post by smrq »

PaulHoule wrote: post #66

I think of the strange case of react-router which has been through 7 versions, many of which were complete breaking rewrites. It's hard not to come to the conclusion that since they kept rewriting it, they didn't believe in any of them. Lately they made big changes because they want to support SSR but I couldn't give a flying F because we're not using SSR any more than I care about React Native support because we're…

The only explanation I have for the React Router team's behavior is that it's a funnel for their consultancy gig. I've never seen another project so developer-hostile in my life.

Re: The Frontend Treadmill

#108

Post by zwnow »

incrudible wrote: post #76
zwnow wrote: post #4

Based on the first paragraph alone, almost all devs I know think that a complete rewrite will solve all the issues, thats not only frontend but backend too. Web development in its current form is a beast and if we want true change we need to fix the biggest issue there is for all of webdev: Forcing everything into Javascript and incompetence. I wont claim I am competent, but at least I acknowledge that SvelteReactVue…

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

Re: The Frontend Treadmill

#109

Post by gryn »

mangodrunk wrote: post #45
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.

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.

As someone who's been on teams/products that did away with the front/back separation back in the php era I think that's a terrible idea.

When things go wrong, which they will given enough time, size and complexity, the blast radius is much bigger.

I still remember trying to change an onboarding page on a website only to find code with goto statements that jump to places that does db calls, messes with code for c processes that supposed to run on an embedded devices (they shared the same codebase), the include statements that executed stuff and had a non trivial call graph that made it hard to refactor, etc.

Meanwhile when things went real wrong on team/projects with bad frontend you could just nuke it (and maybe the people who made it) and restart another frontend in parallel, instead of preparing an excavation taskforce to carefully split the back from the front.

Now I know the first reaction would be duh just have a separation between the concerns and don't write shit code, but I'm talking about when things go wrong (maybe before you got there). The FE/BE split is one of those lessons that I'm thankful managers learned.

Re: The Frontend Treadmill

#110

Post by schindlabua »

mplanchard wrote: post #92
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…

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're still in a discovery stage in the frontend. Though now that I'm not doing much FE these days I get a feel for how frustrating it is to keep up to date. The current metaframeworks also solve interesting problems (that I'm not sure I had tbh) and no doubt new web standards will follow from them. But yeah if you're a new developer who doesn't have all those years of context it must be insanely confusing to swim in a sea of libraries and frameworks without having a good grip on the core web platform.
Post reply on HN