4 ms·
> I’ve held off on diving into front end because it’s just such a circus Its only a circus if you're constantly chasing the new shiny thing. Many of us have be
by squidsoup 2y ago
> I’ve held off on diving into front end because it’s just such a circus
Its only a circus if you're constantly chasing the new shiny thing. Many of us have been productively building apps in react for nearly a decade without significant changes in tooling.
- klysm 2y agoThis is the way
- andyp-kw 2y agoWhile I don't think react is the best frontend framework, it has become the industry standard and therefore is the most peaceful approach to building apps in 2024.
- WD-42 2y agoReact how though? Are you raw-doggin React.CreateElement? Doubt it. So qualify "building apps in react" with whatever bespoke build system, router, state management, etc combination you are actually using. Just because you found yourself a tent inside the circus doesn't mean it's not a circus.
- arvinsim 2y agoHow is that any different from using Django in Python? Laravel in PHP land?
- ywvcbk 2y agoDjango is quite stable and monolithic. If you used it 10-15 years ago and wanted to build something new it wouldn’t take too much time for you to readjust. With JS you’d be entering a new world and chances are that almost everything you can remember is now an “anti-pattern” and starting on a clean slate might be easier.. Frontend is a mishmash of random components and packages, unless you are 100% sure in advance what are you going to use and and do chances are that you’ll run into with issues with the latest version of package X not working with build system Y due to cryptic incomprehensible reasons unless you make sure to stick with the latest “mainstream” trends (which seem to change ever 1-2 years).
- squidsoup 2y ago> Frontend is a mishmash of random components and packages You could say the same about developing in Clojure, or Rust or Golang, but somehow you typically only see this same tired rhetoric applied to JavaScript.
- lenkite 2y agoNo, you cannot say the same about Clojure and Golang. Those are extremely stable languages. Go lang esp has a batteries operated standard library that can be used to develop apps with excellent backward compatibility - you can get back years later, upgrade the runtime and build and deploy your project - and it will work without issues. The comfort you get is soothing. The same is certainly NOT true of JS where stuff breaks from month to month, build paradigms change yearly - causing severe amounts of deep stress. The rhetoric applied to JS is fully valid and justified.
- squidsoup 2y agoThe philosophy of building apps with discrete libraries that do one thing well absolutely applies to js, clojure and golang. I have no idea what you’re referring to when you say things break month to month, that has not been my experience with js. Regarding paradigms changing yearly, also not true - have been building jsx apps for a decade and the only significant change has been from class based components to hooks, which was an easy and welcome transition. Things also change in all language ecosystems. Does anyone use lein these days? Not really.
- lenkite 2y ago> I have no idea what you’re referring to when you say things break month to month, that has not been my experience with js. This is utterly jaw-dropping. There is simply no way to respond to this, since the Everest mountain representing the JS reality directly contradicts this. Its like saying one does not experience Newton's laws of motion. I think you should definitely hold a poll with the community. You would be the super, ultra minority who would hold this position. The only you would have avoided breaking stuff is if you stuck to plain old JS, avoided use of all frameworks, maintained all libraries yourself and did not use any build infrastructure. There is utterly no other possible way you have gone a decade without stuff breaking. React has changed so much - its tooling, libs, best-practices and idioms in the last decade alone. Comparing the JS versus Go ecosystem is like comparing a mad-max kraken with ten-thousand tentacles surfing the waves and wild on steroids vs a boring container freight-ship placidly making its way across the ocean. But yes, it can be fun to surf on the kraken.
- squidsoup 2y agoHave generally favoured picking the most boring and popular tools. Used CRA for many years, and then switched to vite for builds. Vite is essentially the industry standard and painless to adopt. React router for routing, since.. as long as I can remember. This notion that the ground is constantly shifting beneath you just hasn't been true for over a decade.
- ywvcbk 2y agoEvery few years I end up wanting to build some random/hobby webapp and each time the official docs have changed drastically. Use CRA + webpack, now use Vite instead, you know what? Screw CRA you should just immediately jump to Next.js instead (which seemed like a huge overkill initially, but actually seems kind of nice). Unless you’re working on a single project or continuously following what’s new it just seems confusing and overwhelming. If I got comfortable with CRA and came back after a year or two should I still use it for a new project even if it’s bo longer the default? Will new packages/etc. still work with it? Maybe… who knows. I just know that I now have to waste time figuring that out.
- WD-42 2y agoThe official React docs now instruct you to go straight to Next.js: https://react.dev/learn/start-a-new-react-project https://react.dev/learn/start-a-new-react-project When React "is just a library" but the installation instructions tell you to install some large, VC-backed framework immediately - it just doesn't sit right with me.
- squidsoup 2y agoThat is an absolutely fair criticism - it’s unfortunate that vercel has so much influence over the future of react.
- squidsoup 2y agoIt takes five minutes to bootstrap a new react project in Vite or Next. You are significantly exaggerating how hard this all is.