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

201–210 of 722 posts

Re: The Frontend Treadmill

#201

Post by Sateeshm »

TimTheTinker wrote: post #29
ng12 wrote: post #5

> Whatever framework you choose will be obsolete in 5 years. I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.

How many dependencies does your package.json file declare? Which versions of node/npm does your team use? If you're on recent-enough versions and are using any popular libraries, you will have seen the deprecation notices pile up during npm install for downstream dependencies.

Dependencies issue is not exclusive to frameworks. If you don't want to reinvent the wheel, there's no way around using packages, even if you go with vanilla JS.

Re: The Frontend Treadmill

#202

Post by powersnail »

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…

That matches my experience as well.

Google something, find the documentation, go to the documentation, and "We have moved our documentation to a brand new experience", and the link is to the home page of their new website, so you need to redo the search.

X has been deprecated; Y is the replacement; and they provide the same functionality with a completely different API. It just does not make sense to me why Y is created, rather than having X's implementation replaced.

A lot of documentations/discussions are also written with the assumption that you are migrating from the previous approach. So if you just dive in and don't have the context of what used to be the way, it's sometimes difficult to understand what they are talking about.

Re: The Frontend Treadmill

#203

Post by coffeebeqn »

localghost3000 wrote: post #148

> And if you’re an engineer, you will be able to retain much higher market value over time if you dig into and understand core web technologies Been working in FE for nearly 20 years and lived through several major paradigm shifts. I think I am qualified to have an opinion here: I definitely think that you will be a more well-rounded engineer if you know all the core web tech. So strongly agree there. I am skeptical,…

I’d rather have my FE friends learn about API design, Unix tooling, networking, testing, hundred other things than keep re-learning a framework doing the same thing over and over

Re: The Frontend Treadmill

#204

Post by wiseowise »

ewzimm wrote: post #171
Aurornis wrote: post #161

Earlier quoted context omitted.

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

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…

> That people like video formats isn't really surprising to me since it's everywhere

That’s because those “people” are either larping students or kids that want to become programmers. I have never in my 10 year career met a person who said “yeah, I learn my craft from Fireship videos”.

Re: The Frontend Treadmill

#205

Post by Sateeshm »

czk wrote: post #189

I don't disagree with the point being made but it should also be noted that React and Vue are both 11 years old. Hell, even Meteor.js (anyone remember this one?) is still around and being updated.

Even Svelte is going to be 10 years old in about a year.

Re: The Frontend Treadmill

#206

Post by WorldMaker »

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.

WASM makes things worse because now "rewrite it in hip new frontend framework X" has more options. Tired of React? Try Blazor WASM (C#) or any of the exciting new Rust-based front ends or any of the up-and-comers in Swift, Go, Perl, Befunge, Intercal, and other favorite languages or flavors of the month. Dart's not just a thing for people installing Chrome Extensions, now you can use it in WASM almost like Father Google intended when Dart was originally envisioned.

Most of these languages can at least use Web Components for some sort of interoperability. At least the ones doing FFI to JS for DOM manipulation. Of course the "new WASM hotness" for "performance" is "do everything in a canvas and avoid the DOM altogether".

Every WASM "app" is an opaque VM to itself. Many WASM languages bundle a lot of things the browser already provides (beyond the ones also building their own DOM engines for canvas-based UIs) including things like GC. Maybe future proposals like WASM GC will start to break down the barriers between WASM languages/runtimes, and open up more instances of memory sharing and data structure reuse. Maybe. The flipside is every GC is special and not every language wants a weak version of JS' GC underpinning their memory management. Hopes for real convergence of WASM language runtimes seem very optimistic to me. (Especially in a world where even the JS DOM is being skipped for canvas apps because some languages want that control.)

WASM may be the final state of the web in terms of being the diaspora of too many languages running on the web and the true death of the View Source web.

Re: The Frontend Treadmill

#207

Post by dmix »

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.

100%, Turbo and stimulus will save projects from React/Vue hell for 95% of cases. The other 5% you can make isolated fancy JS stuff without it eating the entire frontend.

Re: The Frontend Treadmill

#208

Post by ninininino »

Aurornis wrote: post #161
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…

I'm only recently getting into some of the dev influencer stuff (and enjoying watching some!), I've discovered Primeagen and Theo but that's about it. Are you willing to name some names? I am trying to still form my mental model about these people and what I should pay attention to and what I should ignore.

Re: The Frontend Treadmill

#209

Post by justinrubek »

kerkeslager wrote: post #23
ng12 wrote: post #5

> Whatever framework you choose will be obsolete in 5 years. I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.

I've been writing React professionally for over a decade and React from 5 years ago is obsolete. Like, literally won't build with current tools. To their credit, I think the React code itself has maintained reverse compatibility pretty well (it's not React's fault), but the build systems I was using 5 years ago have all changed and broken reverse compatibility. EDIT: Forgot about component lifecycle methods... Even a…

If it's a 5 year old project, you probably shouldn't be building it with the current versions of tools. You need to pin your dependencies and use the same versions of the tools as before. It'd be the same thing with libraries if you didn't have a lockfile. Your development tools need one too.

Re: The Frontend Treadmill

#210

Post by Eric_WVGG »

Kerrick wrote: post #136
megous wrote: post #129

Earlier quoted context omitted.

You left out other 150 major web frameworks.

I also left out Qt, Swing, etc. on the desktop. I'm comparing a direct lineage of replacements, not showing diversity of choice.

Hi, I've been a web front-end dev for 25+ years. I have no idea what Backbone is/was. There's no direct lineage there, I think that's a sort of forced reading. Also the whole notion of a "front-end vs back-end" division only covers part of the web's history.

imo a real "lineage" would be something like…

- pre-AJAX, server-rendered sites (PHP, JSP, ASP, ColdFusion; no division of front/back-end)

- the monolithic framework era (Drupal, Ruby on Rails, Laravel) with some AJAX Javascript and jQuery sprinkled in

- the modern era of reactive frameworks (front-end fully decoupled)

Even within the most popular modern framework, NextJS, the first question a developer has to ask is “how do I manage state?” Actually that's the second question; the first is “how do I manage styling? should I use Tailwind, or something that doesn't suck?"

Immediately you're looking at dozens of conceptually different choices, which makes one wonder if it even makes sense to call NextJS a framework at all. A real framework would have prescribed methods.

This is why there's front-end churn, there's never been a right way to do any of this, because the web wasn't designed to be an app platform. It's all hacks, from top to bottom.

Post reply on HN