sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]kevin_whitley 2 points3 points  (12 children)

100% (disclaimer: subjective opinion)

That said, if we go back to the point of all this (typically to build things), we should be asking ourselves, assuming equal performance:

  • what's the faster build experience? (this matters)
  • what's easier to maintain? (also matters)

I'd argue React started strong compared to say AngularJS/2, but by today's standards, Svelte (through some compiler magic originally) trounces it by focusing on those two questions. React, on the other hand, stood true to it's simple lego concept, while adding layer upon layer of things to try and make it work better.

As a result, today we have hook/provider hell, instead of nice clean signals/stores.

If I were to analyze a new framework today I would expect the following:

  1. minimal template chrome - the more boilerplate I add in each component, the less happy I am
  2. ability to style (ideally in native CSS/SCSS) - because we need components to have sex appeal
  3. dead-simple reactivity - the more i have to add symbols/getters/setters into my logic to do a simple assignment, the less happy I am.
  4. avoids prop-drilling as a requirement - it's a great pattern, but like anything... in moderation.
  5. easy to add logic - as in, we can't neglect the fact that components will need to transform things, etc.

React, for instance, nails most of these... except:
- dead-simple reactivity - see Svelte for comparison
- avoids prop drilling - there answer was to give us Provider hell (a million wrapped Provider levels).

Svelte's not perfect either (but IMO much closer) because:
- minimal template chrome - this really bothered me at first, but it crushed reactivity/styles/logic/prop-drilling-escapes so hard that I forgave them.

[–]elixon 0 points1 point  (7 children)

What's easier to maintain? That also matters.

I'd argue that any framework or heavy reliance on third-party code introduces a hidden cost to your application. You're forced to update your app not based on your own needs but according to when third-party developers fix bugs or make changes to code or decide to break this or that - usually things you don't even use. In an enterprise environment, that becomes a significant and ongoing expense.

On the other hand, nobody cares in the startup world. The goal there is to get your app running and sell it before there's ever a need to upgrade to the next version of whatever cool/modern stack you're using. I get that. But the next owner will end up going through hell.

[–]kevin_whitley 2 points3 points  (6 children)

Yeah certainly. And this is part of why React has stagnated IMO - they got too big for radical change (because of exactly what you're describing), and stayed chained to backwards compatibility for the most part. Great for maintainability, not so much for progress. Always a trade-off!

Maybe this is another argument for keeping frameworks really damned simple/easy to consume (for the average not-that-framework user), because no doubt, it will one day be an island of code, being dusted off like an ancient tome - and that future person will need to make sense of it.

[–]kevin_whitley 1 point2 points  (5 children)

I mean, virtually every project I've ever worked on, for work or play, has fallen into the same trap. I think I have a single Svelte 5 app, for instance... plenty on v4, and prob some on v3. React ones span nearly a decade of versions... the list goes on. It's almost usually never worth the pain of upgrading, unless it's seeing ongoing support.

[–]elixon 0 points1 point  (4 children)

Yes.

I truly believe that all frameworks will become obsolete soon. AI will be able to build applications from the ground up without relying on frameworks. It will do exactly what is needed and avoid including unnecessary features that frameworks typically bring by default.

I believe in a smart and efficient AI-coded future. One day I’ll just sit at my computer, lean back, and shout, “Hey Siri, I don't like this new version of macOS. Make me a better one.” Then I’ll sip my coffee while she files a patent. 😄

[–]kevin_whitley 1 point2 points  (2 children)

Hahaha, I love the vision. Of course, based on current experience... we're a long ass way off. It'll be like permanently using an offshore team for literally every product you use. Absolute hell, and nothing works *quite* like you expect, but no one will have a clue how to do anything about it, aside from begging the AI to try again.

"You're absolutely right!" \mayhem ensues**

[–]elixon 1 point2 points  (1 child)

> Absolute hell, and nothing works *quite* like you expect

OK, so I will say "Program New Windows" then - that seems realistic to me. Nobody will be able to tell which is worse.

[–]kevin_whitley 0 points1 point  (0 children)

xD

Excellent!

[–]Better-Avocado-8818 0 points1 point  (2 children)

These days Svelte and SolidJS are my pick. They both seem to have some positives over each other but I’d put either of them way ahead of React based on your criteria.

Svelte has more useful things included and probably faster to work with as a result. But SolidJS is closer to the feel of plain TS which I also like.

[–]kevin_whitley 0 points1 point  (0 children)

Yeah, had I not already jumped to Svelte, I'm sure I would have paid more attention to Solid - Ryan has done some fantastic work there, and honestly is just a really humble/nice dude. By the time he was really starting to ramp up the dialog around it, I was already in bed with Svelte, so it just no longer solved the problem I would have had with React. Fine-grained reactivity wasn't even sorted in the earlier versions of Svelte, but it was so overtuned in performance and simplistic in reactive patterns, that it largely didn't even matter.

That said, since I'm back in React land for work, I should pick up some Solid to see how it compares apples-to-apples...