271–280 of 289 posts
Earlier quoted context omitted.
Meanwhile React will continue succeeding the test of time
React is on the downfall because of NON-functional hooks. API becoming too large and the direction is unclear - at least to me.
https://insights.stackoverflow.com/trends?tags=reactjs%2Cvue...
Earlier quoted context omitted.
React is almost 10 years old, if you used React in the last few years you haven't really been changing more than the average backend. The "frontend changes so often" meme made sense years ago but doesn't seem to be that different than backend nowadays. I mean in the last ~10 years we had the new hotness of moving from cloud hosted servers -> docker images -> kubernetes, C# made a massive move when going to .net core,…
But if you picked C and Unix 50 years ago…
Of course old technology exists. You could still make your frontends in Jquery if you'd like.
Earlier quoted context omitted.
Same. I normally prefer boring old tech, but I’ve migrated all my projects over to Sveltekit. Yep, breaking changes are annoying but it’s worth it. It’s got the point where you’d need to pay me lot to work on a Vue or (especially) React project.
Yeah I look at it this way: - Angular introduces structure, people realize that Directives are awesome but dirty checking is bad. - React re-focused frontend on components (to be fair Backbone/Marionette and some MVVM stuff was going this way already but whatever), people realize they really mostly just want big hierarchies of components and to minimize everything else. The Flux data flow pattern is alluring too but…
What a long strange trip it's been
Earlier quoted context omitted.
Yeah I look at it this way: - Angular introduces structure, people realize that Directives are awesome but dirty checking is bad. - React re-focused frontend on components (to be fair Backbone/Marionette and some MVVM stuff was going this way already but whatever), people realize they really mostly just want big hierarchies of components and to minimize everything else. The Flux data flow pattern is alluring too but…
Plain JS -> Angular -> React -> Vue -> Svelte What a long strange trip it's been
It feels like it was
Plain JS -> jQuuuuuuuuuuuuueeeeeeeeerry -> Angular -> React -> Vue -> Svelte
Earlier quoted context omitted.
Excellent observation. This right here is what a senior frontend engineer, that has gone through a couple rewrites and hype cycles, looks like. The fact that they used a popularity contest as justification is laughable: if you have more than 3 years in the field you have experienced the pattern that the new kid on the block, often untested and with smaller mind share, jumps to the top of any "which framework would yo…
Seems like a rewrite for the sake of a rewrite. New frameworks are exciting but if you're building a product you have to realize that's not important to your customers. Sure if you were on PHP, a rewrite to a JS framework would be worth it, because you could deliver features to your customers faster, less bugs, etc. But once you're in the JS ecosystem, it gets much harder to justify a lateral migration like that. Lik…
That sounds just as much like a cargo cult thing and not actually making sense.
Earlier quoted context omitted.
I find your points rather weird. > e.g. how to make a piece of state inside one component accessible from another. That is logically the same with every component framework, there is only one correct way to design it, flowing inside data are props, outgoing data are events. Was always the same. > Then when I saw Vue3 was adding a new, apparently separate way of > doing things (the composition API), but also not depre…
I’m kinda confused by this and your other replies in this thread. You seem to be defending Vue, specifically Vue 2, in almost a drive by fashion. You don’t seem to be considering any of the points actually being made. No bystander is interested in hearing the drive by argument of someone without an open mind.
Earlier quoted context omitted.
Imo, makes it the best bet for building anything. There's still a new JS framework everyday but if you ignore all that noise and for production-quality software just have a look at React and the most popular meta framework on it, Next.js, you'll be more than alright.
Next.js is not a good general purpose React framework. It is good for static sites with sparse dynamic pages but nothing more complex. And the documentation is still woefully inadequate. Don't be like me, choosing to build an entire app on Next.js and hating every moment of it after the honeymoon period ended 2 weeks in. Live and learn.
However, I would strongly disagree with you on the part about it not being suitable for complex applications.
If you feel that way, you can choose to have a decoupled backend (which is what I do with Django) or go all in with full-stack integrations (tRPC in conjunction with edge functions) on top of Next.js.
I have seen great apps built with both of those ideologies.
Earlier quoted context omitted.
JSX is not JavaScript, so if you're using it, you're wholly in the "new syntax" camp.
Sure, you're right about that. It's just that everybody, for example, has the option to use React.createElement directly without JSX, as it's just a syntax sugar and people use it because they prefer it over the other option. Let's consider Vue's syntax: {{ todo.name }} Genuinely, do developers have the option to "just use JS" here (for looping and conditional)? I personally think this Vue example is very inferior to…
Earlier quoted context omitted.
I see that as an advantage. Everytime I see components passed as props or a callback passed as child in react I regard it as a big red flag that something is wrong with the architecture of either the app or react itself.
It's funny; I often see it the opposite way. Passing components as props enables inversion of control and usually helps split responsibilities up more easily and generally avoids prop drilling or super components that do everything.
If you compare xml style syntax to s-expressions there is a clear distinction between child nodes and attributes (a "bi-partite tree", not sure if the term exists). For markup like html where the child-data is the content and the attributes are meta-level annotations this makes sense. Even when looking at guidelikes for "how to design an xml schema/doctype" the responses are often like "use child elements for alle business data and attributes only for technical meta-data".
So from syntactical perspective there is a clear distinction between attributes and child elements. The main one I would say is that attributes are limited in the sub-structure they can contain (only primitive types or space separated lists).
The way react adopted the html/xml like syntax for the creation of javascript objects to allow the declaration of DOM nodes in a nicer way. On top of that react allows the creation of custom elements as functions and allows their usage via the same xml-like syntax.
But now as soon as these custom components have more complicated dependencies between each other the xml syntax gets (imo) misused as a poor dependency-injection layer. It's only possible because JSX allows for non-primitive attribute values and it sticks out like like a sore thumb because the semantics do not match the syntax (like defining a "+" operator that is not commutative).
In my opinion a better way would be curry the component creation or to introduce a real DI-layer for component configuration that is then used to load fully configured components that can then simply be composed in jsx.
The very first paragraph leads me to believe this is just a rewrite into svelte for the sake of it - I get it, Svelte is the new hotness on the FE-js-block, but this entire post stinks of "someone on the dev team advocated and fluffed enough figures to convince us. So now we're going to tell you why it was the right choice!" I say all this pretty confidently as someone currently maintaining a massive legacy vue2 app…
In what way is being on Vue 2 painful? Using it in production, zero problems, everyone understands it, does everything we need. Plan to migrate to Vue 3 for the nice to haves and to keep up to date, but Vue 2 is not painful at all. Considered React but I think Vue will be more productive for the team as a whole in the long term. Vue is more intuitive, better designed, and structured. But totally understand React has…
I think others have offered sufficient/agreeable takes on this, but as the OP, I'll firstly point the pain finger at our own development and blame far too much state/ui/biz logic existing in the web in very tangled and inappropriate ways (part of the nightmare I inherited). Beyond that, the actual vue2-related pain points are typically ecosystem-related support (packages, etc.), and specifically being able to adapt to typescript (this project was initially done in early vue 2.x with just javascript, and attempting to reimplement in typescript to address some of our pain was not fun)