All these frameworks assume you’re writing stuff from scratch. Most commercial software, both internal and external facing, have legacy to deal with.
Even with a brand new app, you have to succumb to npm/webpack/babel stuff. It feels like building a castle on stilts. Inspires confidence, it does not. Back to jQuery I guess.
I mean.. should you though?
0: https://www.npmjs.com/package/lit-html
2: https://github.com/codewithkyle/supercomponent/blob/master/s...
The thing about Vue is that it spans the whole spectrum of a simple <script> tag à la jQuery all the way up to a fullstack app with server side rendering, jsx & typescript support, IDE plugin, browser debugger, and build system.
But the *great* thing about Vue is that you can start off with the simple <script> tag and add it to an existing project (built with other frameworks) and slowly build up to more Vue features if/as you need them.
It's learning curve is also incredibly smooth so you can ramp up the features to your specific needs.
Some examples:
- There's multiple well respected guides and video series out there to port old legacy enterprise Angular.js applications to Vue.js bit-by-bit until only Vue.js remains
- Laravel (the well known backend php system) has decided to use Vue for it's front-end integrations.
- Wikimedia (the foundation that runs Wikipedia) has decided to adopt Vue.
Everything on a web page does not need to be interactive. It's a document first.
Web applications are cool. Maybe React makes sense there. _But every site does not need to be a web application!_ And yet somehow, React and company became the industry default.
Obviously that's not at all how it's used in practice (or even in the create-react-app template), but I do think there's a place for something like React
This use case hasn’t been particularly well supported by many component libraries (React among them; Marko being a long time notable exception), but it’s an area that’s currently having a bit of a renaissance: there is of course Marko which has supported this model for years, joined by other notable frameworks like Astro and Qwik. Even React is moving more in this direction with Server Components, just targeting other use cases.
The component model will continue to thrive, not because everything is interactive, but because components are an excellent abstraction for developing for the web (and a lot of other formats).
No they aren't. Developers think their a painful domain because they are the ones that introduce the complexity in the name of the customer who doesn't care, to increase the developers salary in some kind of crazy Ponzi scheme.
The tools we have in the browser are excellent up to a point. I think the challenge comes when you need to create reusable abstractions around them several layers deep.
There are tools which help manage these challenges really well, like state charts, but they aren’t perfect and they come with their own challenges. The reality (I think) is that UIs can present quite incredible complexity, and creating tools with approachable APIs to help tame the complexity is a legitimately huge challenge.
It could be that I’m a bad software developer (most days I’m pretty sure there’s some truth in that), but I’m passionate and spend a lot of time deep in this space and exploring ways to make it better. It isn’t rocket science, but it isn’t digging holes either. The react team is a bunch of smart people and they’re doing good work on solving a tough challenge.
I don’t see a Ponzi scheme at all. Sorry if I’ve missed some sarcasm or something here - feel free to disregard if that’s the case (or if it isn’t, too)
--
1: https://dev.to/this-is-learning/how-react-isn-t-reactive-and...
Are the people building React completely oblivious to the nigh-unbearable code smell that this is? Why is it so difficult to reason about whether or not code will have side effects?
I'm no frontend developer, and certainly don't have experience with React, but after stopping in at their homepage to see what it does for me and finding out about "JSX syntax"... jesus. I don't know how you parse something like JSX, but I would be willing to bet the implementation is a dumpster fire of completely unnecessary complexity.
I would really like to believe that the people building this stuff aren't amateurs, but the more I learn, the more convinced I am that this is the case. The modern web is bloated, slow, and riddled an assortment of issues that is different depending on which site you're on. Will my back button work this time? It's anybody's guess!
It only seems appropriate to lay the blame at the feet of those who thought the best course of action was to make web development ten times more complicated than it needs to be.
Perhaps the people criticizing it so flagrantly are oblivious to the goals motivating their design choices.
No one is forcing you to use it.
Kinda depends on where you work / what you do.
I wasn't intending to imply that it was the React team's fault.
Personally, I like React and think it has its uses. I was loosely referencing an old coworker who was successfully and comfortably using jQuery for over a decade.
> Blame the employer
I do. They wanted cheaper labour so they had a revolving door of junior developers straight out of online React boot camps and since it's all they know it's what they used on every project regardless of other technologies that were a better fit. Turnover can be expensive so the company caved in and turned every project into a React project.
> or yourself for not switching
Sometimes easier said than done. It can be hard for some people to up and leave when they like their boss/company that they've worked with for 20+ years.
I’m not sure exactly what you mean here, but I can’t think of any reasonable way to write a JavaScript framework that invokes developers’ JS code containing functions, closures, etc. and makes it simple to reason about whether that code will have side effects. This seems like a basic consequence of Rice’s theorem. I suppose you could have a compiler that only supports a strict subset of JavaScript and makes side effects easier to reason about, but arguably that would just be its own separate language altogether.