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.
There's no direct lineage.
The Frontend Treadmill
141–150 of 722 posts
Re: The Frontend Treadmill
#142Earlier quoted context omitted.
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.
You can still write class-based components in React, no problem. It might not be in vogue, but for the most part, you can still write React 18.x roughly the same way you wrote React 0.x.
Re: The Frontend Treadmill
#143Frontend has always been a pain for me.
Just switched from React to Vue since it's getting harder to stay with React.
then I was thinking maybe just the old bootstrap(alpine.js,htmx) with SSR approach? it's simpler and more importantly, can be maintained a few years down the road without a revamp(due to frontend breaking changes).
In the end, I still stick to Vue.js, as the SSR approach has its own problems, nothing is ideal.
Re: The Frontend Treadmill
#144Just use Ruby on Rails. Problem solved.
I can't imagine having to build a frontend in React... I'm doing everything from mobile app to extensive frontend using Rails... no React anywhere. Just plain vanilla Rails and it's been a godsend!
Re: The Frontend Treadmill
#145> Whatever framework you choose will be obsolete in 5 years.
I am predominantly not a frontend dev, but when I do do frontend work, (and I don't avoid it by any means,) I have been using React for the past... 10 years now? And while some sentiment has been moving towards Svelte, by the time Svelte overtakes React, it will have been in production for just as long probably. And Angular might eventually run out of steam, but it's been around even longer than React, if you want to count the Angular1 and Angular2+ days together. So honestly I think this is out-of-date logic. While frontend dev moves fast, it really isn't that bad. Pick boring choices and you get boring results.
Re: The Frontend Treadmill
#146Earlier 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…
I don't think it's a Javascript problem in the sense that it's due to intrinsics properties of Front-end developpement, or of NPM, but I do agree that's in a cultural problem in the Javascript ecosystem, especially around React.
My theory is that there was a perfect storm around 2015 where everyone and their dog was encouraged to learn to code, especially by going through a coding bootcamp where they were mainly taught Javascript and React. At the same time there was a general enthusiasm for Open-Source, and of using Github as a sort of alternative, better Linkedin in order to get your first job as a software engineer.
As a result lots of silly packages were created (and used !) by well-meaning junior developers, who were told that coding is very simple but also fraught with peril, so if they are serious then they better should use packages such as 'is-odd' which is clearly more professional than doing it yourself, cause it follows the DRY principle and also get updated test by lots of people, etc...
Re: The Frontend Treadmill
#147Earlier quoted context omitted.
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.
Could you name any of these "150 major web frameworks"?
Re: The Frontend Treadmill
#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, however, that it will make you more attractive on the job market. It's not that knowing this stuff doesn't matter, it's that folks that make hiring decisions tend to pattern match. The fact is that if you want to maximize your "market value", you still need to be _very_ good at React. This is table stakes. Everything else is great, but if you don't have that foundation, you're limiting your options.
Maybe that is what the author meant and I am just misreading.
Re: The Frontend Treadmill
#149Earlier 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.
I build simple applications for personal use like issue tracker, day planner, etc,. By default if you ask Claude it will generate React for frontend but I ask it to use HTML/CSS/JS instead. Because as a backend developer that makes sense to me. I find it hard to read the react code and want to avoid having dependency on npm. It's surprising how well the core technology works without fancy front end frameworks. Claude…
Yeah it's surprising how easy many things really are. I asked Claude to spice up another vanilla JS/HTML app with a Material UI like touch ripple effect and... it simply did.
Was just around 100 lines of CSS/JS. No need to rewrite everything.
Re: The Frontend Treadmill
#150To 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.
No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.
You would probably be decent at frontend if you did it at least 20% of the time. Obviously you can't be an expert at everything, but there is enormous value in being able to work on most things end to end instead of having to handoff every time.