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

181–190 of 722 posts

Re: The Frontend Treadmill

#181

Post by hombre_fatal »

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…

Well, you should compare the JS UI ecosystem to other UI ecosystems like Android and iOS, not ecosystems that run on one machine with no UI.

Then you'd make a more sensible comparison like React versus something like SwiftUI which is constantly changing, constantly breaking, and still basically in beta mode for 10 years, yet it only runs on specific versions of Apple hardware and software. And usually it's so insufficient that you also build part of your app in UIKit/Cocoa in a completely different language.

React is far more stable to build with and far less experimental.

People who have never touched any UI tech until HTML/JS have no clue how good they have it, so they confuse universally hard things about UI tech with something that must be specific to JS, so they additionally assume it's so much better elsewhere.

You should try updating a nontrivial SwiftUI app you made for the iPhone 11 to work on the iPhone 16. Not only have your libraries changed (not just topical ones, but the Promise library you used is defunct and everything now uses Combine and 2021 Swift async features, so you have to migrate all of your async code), but the platform itself doesn't have APIs that you were using anymore. That's not even a class of problem you deal with on browser tech.

Re: The Frontend Treadmill

#182

Post by mystifyingpoi »

upghost wrote: post #157

The article mentions "web fundamentals" and "getting back to the fundamentals". Sounds great! Would anyone care to have a conversation about what this means? Like does the author mean DOM manipulation or TCP stack? I feel like this is pretty broad and even though I've been doing full stack for a bit now I'm suddenly not sure if I know the fundamentals.

I think a lot of people are yearning for the "good old days", where you'd install Apache, drop some .php files into /var/www and start hacking around with only static HTML and maybe a sprinkle of progressive-enhancement JS here and there. I think it's totally okay way to build a dynamic webpage. But web application? Not so sure.

Re: The Frontend Treadmill

#183

Post by yakshaving_jgt »

Raed667 wrote: post #179
yakshaving_jgt wrote: post #81

Earlier quoted context omitted.

Like what? I think the web looked more or less the same in 2015 as it does today.

Wasm, WebGPU, a bunch of PWA features etc...

I mean, we had asm.js in 2013, which ran Unreal Engine 4 in the browser.

WebGPU is new, but WebGL came out in 2011.

Re: The Frontend Treadmill

#184

Post by pc86 »

> If you feel strongly about what framework you want to use, please make that a criteria for your job search. Please stop walking into teams and derailing everything by trying to convince them to switch from framework X to your framework of choice. It’s really annoying and tremendously costly.

We try to screen for this mentality pretty thoroughly in interviews.

Few things are more tiresome than having a product that has been around for years, and that has lots of users, tech debt, edge cases, and business considerations baked into it and having to explain to someone who's been with the company for 2 months that no we probably shouldn't throw out the entire React app and rewrite it in Svelte. An few things are more aggravating than someone who has that idea shot down multiple times and keeps. bringing. it. up.

Any indication in our interview process that you are a language or framework zealot will make it a lot harder for you to move to the next round.

Re: The Frontend Treadmill

#185

Post by curtisblaine »

React 16.8 (the one with hooks) has been stable for almost 6 years and newer React versions are mostly backwards compatible. The real problem are bundler / build tools. Using something like esbuild + tsc goes a really long way and will never get deprecated. If you know the craft enough, you can ignore everything else (save eslint, probably).

Re: The Frontend Treadmill

#186

Post by coffeebeqn »

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

Earlier quoted context omitted.

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.

I also haven’t seen it in any other place. Game dev and backend which I’ve worked in uses the same technologies for decades. It’s like someone trying to write a book but instead of writing a new chapter each month they mess about with their ink choice and their font choice and their paper roughness and get very little actual progress

Re: The Frontend Treadmill

#187

Post by luisgvv »

SamuelAdams wrote: post #15

Speaking of front end frameworks, whatever happened to Angular(JS)? It seemed to be required on every other job posting, but now things seem to only ask for React or React Native.

I began doing AngularJS and have been doing Angular 2 for a while, as another commenter said: there are jobs still out there.

In my experience I get more Angular & Vue offers than C# and React. For what is worth I'm convinced that across the industry React jobs wages are lower. Who knows, I could be closed in my own bubble but am pretty sure the pool of react devs is bigger and this might be the reason.

Re: The Frontend Treadmill

#188

Post by lelandfe »

hyldmo wrote: post #173
lelandfe wrote: post #153

Earlier quoted context omitted.

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 will note that Bower’s last non-hotfix release was 8 years ago :)

I’ve got big hands!

Re: The Frontend Treadmill

#189

Post by czk »

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.

Post reply on HN