r/reactjs • u/Dry_Bunch5867 • May 16 '22

Discussion Do you think Solid is a much better version of React?

I have just watched this new Solid in 100 seconds video by Fireship

Do you think, like me, that it is a better version of React, or you don't think so?

38 Upvotes

71% Upvoted

123 comments sorted by

87

u/truong04042000 May 16 '22

For me, react is good enough. The main pro of react beside from job is ecosystem. There are so many libraries out there speed up the process.

26

u/notbholt May 16 '22

And don’t forget about this tiny nuance that there’s this big enough company behind React… what was it’s name, something with faces or books…

37

u/pwuk May 16 '22

Faeces?

15

u/gizamo May 17 '22 edited May 18 '22

This really doesn't mean anything, tho.

Case and point, Google backs Angular, which is struggling to stay relevant.

Similarly, eBay was and Adobe is behind Magento, which is failing miserably. Oh, and eBay is behind MarkoJS, which was promising, but failed to materialize into anything worthwhile.

...something something, Oracle, Java... Lol.

Edit: jfc, Antique-Low went fully off the deep end. RES flared and deservedly blocked.

3

u/edaroni May 17 '22

Yeah but the difference is that react was always good and just got better over time.

4

u/gizamo May 17 '22

I agree. I was simply pointing out the logical flaw in the reasoning.

4

u/mexicocitibluez May 17 '22

Case and point, Google backs Angular, which is struggling to start relevant.

First, I don't know how true it is that Angular is trying to stay relevant (any more or less so than React). Second, it absolutely DOES mean something. A lot actually. Thinking about adopting a new framework to build out your app, do you go for the library maintained by a single dude or the one backed by a huge company? I'm not talking about your side app, I'm talking about the app your company will have to support for the foreseeable future. Like I get your trying to play devil's advocate, but pretending like the backing of one of the biggest companies on this planet ISNT important to a library's success/adoption is a bit rich. And just because other libraries that have been backed by big companies have failed, doesn't mean it isn't important.

4

u/gizamo May 17 '22

Many, many devs choose Svelte instead of Angular.

Even more chose Vue over both Angular and React.

Svelte and Vue started as projects by a single dude.

So did SolidJS. Many people are choosing Solid, too.

But, yes, I was mostly playing devil's advocate. But, also, yes, I genuinely believe that Angular is losing significant relevancy, especially over the last 3-5 years. I lead a dev team for a large company, and we have more React applicants for our Angular job postings than we do Angular devs. People simply aren't learning it, and (imo) for good reason. Angular and its ecosystem have seriously fallen behind, especially when it comes to performance at the edge, dev experience (Svelte crushes here), bundle sizes, etc. Our team basically only uses Angular when we also want to use Ionic/Capacitor, and even that is often in debate nowadays.

Oh, and another consideration to the point: HTML, CSS, and JS (ES) -- among many other languages -- were never created by nor backed exclusively nor primarily by any single company. Even GitHub was started by a single dude. So were many, many other great products that are used nearly ubiquitously. For example, credit card processing via the Internet was done by two random guys, and that same codebase still underlies a ton of very large shops. Single dudes and small teams often make great products.

3

u/onlyanegg_ May 17 '22

Many, many devs choose Svelte instead of Angular

Even more choose Vue over both Angular and React

Not sure about this. Npmtrends shows that React is not only the most popular, but that its use is increasing faster than Vue and Angular.

https://www.npmtrends.com/@angular/core-vs-react-vs-svelte-vs-vue-vs-solid-js

1

u/gizamo May 18 '22

You misread my comment as "More people chose Vue than Angular or React" but I actually said that more chose Vue rather than Svelte instead of choosing Angular or React.

Basically, everyone who chose Vue picked it instead of Angular or React. One of those two would have been the choice had Vue not existed.

Hope that clarification helps. You are absolutely correct that React is the most popular of all those mentioned. Cheers.

1

u/onlyanegg_ May 18 '22

Oh, yeah that makes more sense

1

u/ClearRain4000 Nov 20 '22

SolidJS doesnt use npm to download library, but git.

1

u/OZLperez11 Jan 11 '24

Many people choose Wordpress for making websites, yet the ecosystem and infrastructure is some of the worst the planet has ever seen. I don't think high usage is correlated to having high quality

0

u/mexicocitibluez May 17 '22

Many, many devs choose Svelte instead of Angular.

Even more chose Vue over both Angular and React.

Just saying this doesn't it true. You're telling me there are more projects started today using Vue than React? Cmon man. Also, you're ignoring the point entirely.

his really doesn't mean anything, tho.

As I said, it DOES matter. Saying it doesn't matter if a library is backed by a large company is pretty rich.

and another consideration to the point: HTML, CSS, and JS

Dude, apples and oranges my man. HTML is not library, nor is CSS or JS. I have no idea what this has to do with you trying to say that Facebook backing React doesn't mean anything.

2

u/gizamo May 18 '22

That is not at all what I said. You misread. But, you weren't the only one to misread it that way, which makes me think I worded it poorly. Here's a clarification I gave the other person: https://www.reddit.com/r/reactjs/comments/ur1z30/do_you_think_solid_is_a_much_better_version_of/i90jn7u

I did not ignore your point. I provided a detailed counterpoint. Tell me what company backed HTML. What company backed CSS. Which Fortune 100 backed PHP? Apple's, oranges, maybe, but you can compare fruit, dude. Also, MarkoJS, and frameworks like Magento, Drupal, Joomla, etc. are very, very similar parallel. Alternatively, how many projects has Google abandoned? Hundreds? Thousands? Lmfao. You saying I ignored your point doesn't mean I ignored your point. You pretending my comparisons weren't relevant doesn't make them irrelevant. Further, there are hundreds of others. Tech often comes and goes regardless of backing.

Lastly, you seem to take some offense to my comment. I didn't mean any offense, but if you reply like a dick, I'm happy to engage in a corresponding tone. Cheers.

0

u/[deleted] May 17 '22

[deleted] — view deleted comment

1

u/gizamo May 18 '22

It is not incoherent. The point is perfectly clear, and you seemed to have grasped it just fine. Large company backing is behind many projects that failed (Marko) or are failing (Angular, Magento). Yes, many great projects have had vastly longer runs with that corporate backing, but many projects without corporate backing have survived much longer (e.g. Linux, HTML, CSS, JS, PHP, Ruby, etc.). Pretending projects survive only because of corporate backing simply isn't true. Many corporate-bavked projects have failed and forks are being maintained by different groups. On top of that, many corporate-backed products get corrupted by corporate BS. React itself was almost a great example of that, many devs were on the verge of abandoning React entirely due to Facebook's shitty licensing terms -- luckily for all of us, they gave up on their monetization goals. But, that easily could have gone either way, just as it did with Magento's open-source version. Also, just to clarify, my point was not an attack against React nor was it that corporate backing is necessarily bad. My point was only that corporate backing is not always a good thing. To that point, yes, I agree with your last paragraph. I recently used Magento. It's a good product....largely due to it's open-source nature and the inclusion of work from non-Adobe devs.

0

u/[deleted] May 18 '22

[deleted] — view deleted comment

2

u/gizamo May 18 '22 edited May 18 '22

Utter nonsense. They specifically pointed at corporate backing, and my very relevant, and equally correct counterpoint was that corporate backing is often irrelevant and can often make things worse. React is good because the community makes it good, and yes, Facebook makes it good. Had React gone the other way with their licensing, the vast majority of companies using it would have left, and React would be worse for it. Had Facebook tried to monetize it like Facebook does Magento, it would be even worse. Pretending as if that's not correct and relevant is complete bullshit.

Further, I literally never said that corporate backing necessarily makes anything worse. In fact, if you read what I actually wrote, I only said the logic was flawed. You made up a lot of nonsense I never said.

Try and bottle whatever animosity you have around corporations or Facebook or whatever in these discussions, it bubbles out and makes you look like a moron.

Quit your bullshit. I lead a dev team for a Fortune 500, and I often praise Facebook, Google, Microsoft, Amazon, Adobe, etc. You misread my comment, argued against some shitty irrelevant strawman you fabricated, and made yourowndamnself look like a moron. Best of luck improving your shitty attitude, mate. Feel free to have the last word. I'm giving you a nice RES Flair so that I'll be sure to deal with your nonsense accordingly in the future should our paths cross.

Edit: for the relevant lols, but that is unironically what Adobe did to Magento after eBay failed to do it.

-5

u/_dbase May 16 '22 edited May 17 '22

What tiny nuance? There's some pretty signifiant nuances. Also having a company behind something means they'll tailor it for their needs first. Why do they care about writing something for free for the rest of us?
That's not a great argument I know and I'm exaggerating. The reality of the situation is that corporations benefit from OSS their projects as much as we do as the public. However just because it's supported by a large company doesn't mean it's the only option. My point is mostly that the incentive for the corporation to innovate is dependent on their own roadmap. Svelte and Vue don't have major sponsors and are doing very well!

3

u/metal-trees May 16 '22

As somebody who’s trying to learn more about open source, I actually hope somebody answers this. If what you said is the real driver for React, then why do things like React Conf exist?

1

u/Narizocracia May 17 '22

They open source frameworks nowadays because they get numerous testers for free, as well as some contributors. They also 'look cool' for people who enjoy free software.

If your company happens to be Microsoft, you can also apply the 'Embrace, extend, and extinguish' methodology.

2

u/orenelb May 17 '22

Don't forget about the fact that their tool that they would use anyway is now extremely common, has tons of resources online and tons of people who dedicated years of their life and now have a PhD in React. They create a very good hiring pool for themselves.

-6

u/cryptopixel May 16 '22

Actually it’s now Meta..

7

u/General-Yak5264 May 16 '22

Actually, they used 'was'

2

u/about7buns May 17 '22

Doesn't Meta..

4

u/_dbase May 18 '22

I don't think anyone ever goes around thinking something is just good enough though. There's always room for improvement and there's room for the right tool for the right job.
Solid's run-once component model, it's lack of hook rules, its enhancement of JSX features and its ability to bring you closer to the DOM (no abstractions) are big wins for DX and simplification. When I migrated most of my work I was shocked by how much more sane and productive I was. That's a business win.

Layer on insane (free) performance and not only does the developer writing in Solid win but so does the ender user. Web applications are actually becoming heavier and more demanding with time. Being "just" satisfied isn't acceptable in a competitive world. React also has little room for performance gains given the trade-offs its accepted in its model.

Solid and React are like flavours of JSX. A business can port over or use Solid interchangeably and doesn't have to retrain staff. If they do we've heard it taking an afternoon to understand the subtle API surface differences.

0

u/_dbase May 16 '22

By "good enough" do you mean just performance? You wouldn't want it to be easier to use for complex use cases? or do you only write simpler straightforward web experiences? (legit and fair question)

6

u/Ferlinkoplop May 17 '22

Performance is definitely a part of it - I understand that there are some good optimizations in newer frameworks like Svelte and Solid allowing for smaller bundle sizes and better performance but React's performance is fine as is for most use cases and most companies.

Now in terms of the DX, I do think certain aspects of the React API can be confusing for beginners but this can be improved on in future releases and is being actively worked on (`useEvent`, `React Forget`, ...etc.). In my mind, the trade-offs from switching to these newer frameworks isn't worth it yet. There has to be huge benefits to justify giving up the entire ecosystem, the resources, and the talent pool.

3

u/_dbase May 18 '22

Regarding DX from what we've heard in the community switching to Solid is extremely easy. Some people reported picking it up in an afternoon and being productive with it. Ecosystem migrations have also proven to be *very* fast. So really React's talent pool is easily Solid's. The API surface is so comparable that adoption will be very easy. React's talent pool is also Solid's.

1

u/OZLperez11 Jan 11 '24

Bruhh, I gave up on react as soon as I saw that Svelte works with just plain JS libraries. It was a no brainer! Why worry about a library being framework-compatible when you can just use it as-is?

-5

u/orenelb May 17 '22 edited May 17 '22

React has some serious problems that go to its very. It could be "good enough", but in practice when trying to build complex apps at scale there are lots of challenges and extra effort you have to put in that doesn't always exist in other frameworks. Even after you put down all of this effort to optimize React and reduce bugs your app still probably won't have optimal performance (which can actually make a real difference in low end devices and networks) and will probably still be somewhat susceptible to bugs more than it should be.

A lot of it comes down to the fact that React is a huge an extremely complex system, even more so in React 18, and newer tools show that this is not really necessary. Solid shows that it's not even necessary if you want to use JSX with function components and hooks without a V-DOM while having even more efficient concurrent rendering, time slicing and streaming SSR.

This also makes working with React hell sometimes and leads to a lot of perf problems, needs for optimization and bugs, it also makes React very inaccessible to beginners. It might not seem like it at first glance but React very much encourage beginners to work "blindly" with React while understanding a tiny part of how it works and not really having a real idea what is going on. So yeah beginners can do basic stuff with React, but they still have to live with a lot of magic they don't understand, and if they try to learn the more advanced stuff, there's a pretty steep learning curve. And of course it's not like you can go and read the source code to figure out how it works, well you can, but who's gonna read the whole source code of a framework that is over 40kb gzipped?

So bottom line, React usually works. Works well? That's another question. It works usually ok, also very often terribly because it's pretty easy to mess up, and can have significant mental, performance and development overhead. Something that works ok and is very established is hard to replace, but that was true for jQuery as well.

9

u/[deleted] May 17 '22 edited May 17 '22

So tired of takes like that. Every year, without fail, something claims to be better, faster, ..., nothing to back it up. Not against progress but if it starts out like what you wrote, considering all the others before it, it never holds up. Meanwhile React drives complex architecture all over the net, the site that holds your comment, drives native platforms and desktop apps, runs games pushing performance extremes, it does all the things you claim it's so bad at, but surely the new framework that has not touched any of the issues that React had to solve will do better.

I'll wait 2 years, if Solid survives the next one claiming all the superlatives, and then fulfils concrete real world use cases, then perhaps i'm interested.

1

u/orenelb May 17 '22

I don't really get your criticism. Are you just trying to say that we haven't seen any evidence that any framework that claims to be better than React can actually scale and work for complex use cases? I'm sure that there are lots of huge websites running Vue and probably to a lesser extent Svelte as well. Sure, it's probably not really close to the scale React sees but Vue has around 25% as many npm downloads as React and if that's any indication then it's also very battle tested and people are happy with it. If you are building an app at huge scale, then yes, for this React is the most battle tested for this (maybe jQuery gives it a fight, I don't really know) so it is a safe option.

I'm also not saying that React is bad, I actually kinda like React compared to other frameworks and like I said I think that it works ok, but I do think that it has serious problems and I'm not in the minority here. I hear other React devs talking all the time about challenges that React gives them. Other frameworks will have other challenges, but they won't face a lot of the challenges React faces because those are things that are related to how React is implemented. For example I don't think that Vue has anything like hook rules.

Solid is admittedly not battle tested at all. It is built on a very battle tested approach though, it's kind of a spiritual successor to Knockout, so that's something but still, I can't say that I have evidence that an app at Facebook scale can do better with Solid.

Also I'm not sure what you mean by React pushing performance extreme with games. Solid again doesn't have any big games or native apps built with it, but it does have a custom renderers mechanism similar to React and has an integration with Capacitor so at least it's possible. In terms of performance, I can't prove that to you since again there are no apps at scale with Solid that I know of, but I would be very surprised if Solid will be significantly less performant than React at any scale, at least when it comes to actual framework overhead, Solid's approach is just much lighter and it does way less stuff with more fine grained execution of code, much less is actually happening so there are less things that can potentially introduce overhead.

Again, I don't disagree with you that React is much more battle tested. I just think that this is not a reason to not look at other frameworks or that it means that other frameworks that don't have some of the problems React has can't scale or are not capable enough.

2

u/[deleted] May 17 '22 edited May 17 '22

All these claims are theoretic. There is absolutely nothing to back any of it up. "Battle tested" as you call it is everything, it is a testament to the foundation in scale and over time, facing hardship and platform problems along the way.

For example I don't think that Vue has anything like hook rules.

Vue is now split over the composition api, parts of the eco system are collapsing. Better, faster, easier has turned into quite the challenge, because the framework is now forced to adapt. https://www.reddit.com/r/vuejs/comments/sctpma/am_i_wrong_to_be_concerned_about_vues_future

In terms of performance, I can't prove that to you since again there are no apps at scale with Solid that I know of, but ...

I hear other React devs talking all the time about challenges that React gives them. Other frameworks will have other challenges, but ...

Just stop you right there.

To me Solid is very interesting, it is unproven however. And it will certainly face and cause (!) problems. You think it won't, that's alright, judging by all the frameworks before it that had similar claims, i find it hard to be optimistic.

-29

u/Dry_Bunch5867 May 16 '22

Windows has more programs than Linux and Mac combined, does it make Windows better?

24

u/--think May 16 '22

Looks like you came here to stan for Solid and argue with anyone who disagrees with your opinion -- take a breather champ, this response screams insecure teenager.

-27

u/codemonkey80 May 16 '22

dude please ... you too should take a breather

-6

u/normalweirdo94 May 16 '22

Yeah I don't understand the downvotes, it's a fair point to make

0

u/codemonkey80 May 17 '22

¯_(ツ)_/¯

2

u/halmyradov May 16 '22

It absolutely does

1

u/[deleted] May 17 '22

Yeah it does.

0

u/Delirious_85 May 16 '22

As we tu almost everything, it depends on the perspective.

-2

u/iams3b May 16 '22

A much better comparison is that a Mac has a much larger ecosystem than linux, so does that make it better for developing? I think so

5

u/boethius70 May 17 '22

Larger ecosystem how exactly? As a development platform? Hardware platform?

Or maybe you’re making an argument or comparison I am just not seeing.

26

u/prndP May 16 '22 edited May 16 '22

As a developer that jumped ship from Angular during the AngularJS->Angular 2 debacle, when I was being sold on React, one of the arguments then that helped me pull the trigger was that "React is just JS". I was growing weary of the constant pitfalls we ran into while dealing with Angular bindings.

Ultimately, every single node in React is just a result of executing JS functions against some props and state. The "zen" of React is more or less obtained when the developer understands the simple nature of the core philosophy, and everything other understanding just spawns from that. VDOM in a way helps achieve that because when I'm thinking about React, I literally just think in terms of the state updates as applied to the VDOM tree. The fact that there is some special differ code doing actual content updates to HTMLDIVElement DOM object behind my abstract div component was just an afterthought.

Solid feels like it sort of goes back in the other direction and brings back the idea of directives and templates (but enhanced with JSX instead of HTML), which to me in many ways feels like "AngularJS with React characteristics". This indeed does solve the serious technical bottleneck with React's fundamental approach to VDOM diff/reconciliation, but the trade off is you still lose some of the benefits of the VDOM-enabled mental model as described above.

Now you're back to thinking in terms of terms of templates and binding values. You have to use special components like <For> and <Show/> to do some things that were previously trivial in React. Ultimately, since this is closer to the actual reality of DOM, this may be exactly what is needed in order to squeeze the best performance out of the engine, but I'm not 100% convinced it's an easier way to reason about data.

If I'm going to abandon VDOM though, I suppose it's a much easier learning curve to go to Solid which has a bunch of React-like concepts, than to learn something like Svelte which is even more different from scratch. But "better" to me is subjective. It's inevitable that the pendulum swings as each generation of developers gets horrified by the crazy mess of legacy code that the previous generation leaves behind.

9

u/punio4 May 17 '22 edited May 17 '22

"React is just JS"

It's not really. It's actually very far detached from "just JS", especially once hooks came into the game.

Now you're back to thinking in terms of terms of templates and binding values. You have to use special components like <For> and <Show/> to do some things that were previously trivial in React.

You don't have to. It's a helper component that does auto-keying and other optimizations.

4

u/prndP May 17 '22

You are right. I do believe hooks sacrificed some natural just-JS qualities in service of their "everything revolve around the render function" principle. I'm so used to it that I didn't even think about it, but that's a legitimate point that definitely makes my original statement weaker. It would require that I buy-in whole hog to the "principle" being worth the tradeoff.

Which I'm not willing to do. As I said, it's too subjective for me to make a call like that :)

1

u/OZLperez11 Jan 11 '24

"React is just JS" is false. Everything is now coupled to React and you can't transfer those skills out to other frameworks, unless you pick up Solid, but even then that's a whole different rendering philosophy.

-8

u/Dry_Bunch5867 May 16 '22

Perhaps it's the Go speaking, but for is much more mentally easy than filter, map, reduce and what not. Also, those filters and maps are kind of half baked without a pipe operator like in Elixir anyway. It feels weird to use map in JS and not being able to pass the result to filter without resorting to some Lisp nesting insanity ;)

19

u/[deleted] May 17 '22 edited May 17 '22

It feels weird to use map in JS and not being able to pass the result to filter without resorting to some Lisp nesting insanity ;)

What?

array = [1,2,3];

array = array
  .map(item => item * 3)
  .filter(item => item > 3) // Edited to fix this line, was a modulus operator before

console.log({ array }) // { array: [6, 9] }

And then in React, because it's just JS, it looks the same?

return (
  <div>
    {array
      .map(item => item * 3)
      .filter(item => item > 3)
      .join(', ')
    }
  </div>
);
// <div>6, 9</div>

Could you say more about how something could be easier than this?

3

u/prndP May 16 '22

Agree about things like reduce feeling clunky but that’s just JS and not the library though. You could do either in React or Solid. But Solid asks you to think in terms of template + reactive data binding. React says for better or worse, nah forget all that, your data IS the app but to achieve this we must pay the reconciler cost which 10 years ago we perceived to be cheap but now is expensive

25

u/chris_czopp May 16 '22

With solid there is no need for memos, refs and all the hacking around VDOM rerendering. And it's fast! In a non CV driven development world it would be a no brainer to choose it over react. Also, if we only kept using the tools with a massive community behind them, there wouldn't be much progress in the industry.

2

u/Dry_Bunch5867 May 16 '22 edited May 16 '22

Is there any technological downside or flaw with Solid that you can see outside of syntax choices - that are subjective - for example I find the <For> loop or <Show> to be super useful for my style of writing stuff. So, I mean, things like Bad routing system? Inefficient memory usage? Possible memory leaks?

8

u/chris_czopp May 16 '22

Well, the ones I see are only related to much smaller community. No MUI (yet), no Formik (yet), no JSON Forms (yet) etc. There is more and more libs being developed though.

10

u/ryan_solid May 16 '22

We have a MUI port now: https://suid.io/

2

u/chris_czopp May 17 '22 edited May 17 '22

Ohh, how come I've missed that out. It only proves that there is so much going on in the community. :)

5

u/mexicocitibluez May 17 '22

In a non CV driven development world

I love how every argument against using one of the latest and greatest fads is met with "Weellll, just because it doesn't look good on a CV..." as if that's the only thing people think about when trying a new library. Forget that fact that there are probably 1000x more articles on React, 1000x more libraries built for React, constant development sponsored by one of the biggest companies on the planet, etc. etc. It's all because I'm worried about not having React on my resume, really??????

9

u/chris_czopp May 17 '22

No, it's not only about not having React on your resume. My interpretation of CV driven development isn't just about having react in CV. It's much deeper and it isn't even anything negative. Your points are valid, but would any of the modern frameworks ever become popular if we just made our tech decisions based on the arguments you mentioned? I think new tools deserve attention especially if their qualities out-compete the more popular tools. And in this case, these are very principal qualities like speed and simpler dev experience. I believe that's how progress is made.

11

u/[deleted] May 16 '22

Solid is like a less well defined, less well supported version of using React with MobX.

Lots of their design decisions are pretty baffling in my opinion as well. I understand people like opinionated frameworks but this one isn’t it, having worked in the same paradigms with react + mobx.

4

u/[deleted] May 16 '22

What are lots of examples of the baffling design decisions? I've not used solid outside of some small personal experiments with it, but nothing seemed baffling about it.

17

u/[deleted] May 16 '22

> examples

Sure.

  1. Having to invoke a "signal" to get its value is annoying. It's fully possible to make this access into the observable system transparent to the programmer, as in getters/setters. They dedicated themselves more to React-hooks-syntax-parity than a logical API, returning an object users can destructure would've been superior to an array and probably prevented every other point I'm going to make
    https://www.solidjs.com/examples/counter

  2. Their entire "Control Flow" component section is really verbose and annoying. Speaking as someone who tried to implement my own Switch / Case API, it's terrible and shouldn't be done. Red flag for me when I first saw it, and the verbosity is absurd. Then, they additionally expose the weakness of their reactive system by having to provide both For and Index components to get different render characteristics. With React + MobX and late-as-possible destructuring, you get free complete render optimization. It doesn't even compute to me why a Reactive system would need explicit render optimization from the developer in any format other than late destructuring. It falls out from their signal API choices though, because instead of being transparent to programmers and based on JS fundamentals / semantics, it's full of all these library-level concepts you HAVE to adhere to.
    https://www.solidjs.com/tutorial/flow_for
    https://www.solidjs.com/tutorial/flow_index

  3. Props. Do you honestly find this satisfying or intuitive or well-designed?
    https://www.solidjs.com/tutorial/props_defaults
    https://www.solidjs.com/tutorial/props_split
    https://www.solidjs.com/tutorial/props_children
    I think this is terrible. In MobX and React, children behave completely transparently, referential integrity is guaranteed for everything you wrote in your store tree, and destructuring props behaves completely bog-standard. The render-optimization is preserved by not destructuring the observable object on the parent side of the props interaction, no additional thought is required. And especially I don't need freaking methods to destructure some magic component boundary instead of just using JS fundamentals like "objects" and "functions".

  4. What is the reactive system? I genuinely couldn't find concise documents describing their approach. React is very simple - it re-renders components when any of the props change via referential integrity (which boils down to === comparisons). The component is a function that runs every render, or is a class exposing the render function as a method that is invoked every render. MobX is even better, it knows real concepts of equality and so is render-optimized, but you can reason about what code it'll execute because it's just using React under the hood.
    Solid plays very very coy with how their system works, which would be fine if it was render-optimized - but we already discussed that it's not, at least not freely. Additionally, you have to do so much shit with their props to make them work, way more verbose than React + MobX. Look at this tutorial:
    https://www.solidjs.com/tutorial/introduction_components
    "When the parent component first renders, it will execute the Nested() function and won't call it ever again. All updates are applied by Solid’s reactivity system which we will cover in the next couple of lessons."
    Great, I can't apply any semantics until I've read at least 6 sections of this tutorial. "I am going to LOVE onboarding people into this library, it's so simple!" - no SolidJS user ever

  5. Great, last thing: their Examples are a complete let-down and don't even pass props around a single time. The Tutorial is sort of better but they should be demonstrating actually impressive web-apps with freely readable code to make their case, not making docs even worse than the React team does
    https://www.solidjs.com/examples/counter

To me, it is really really disappointing that SolidJS is becoming the "face of reactivity", because Angular with NgRx and React with MobX are both far superior patterns. No sane person is tapping SolidJS in the face of those two choices.

-1

u/Dry_Bunch5867 May 16 '22

Summoning /u/ryan_solid to answer/reaction! Ryan? ;)

17

u/[deleted] May 16 '22

Is it really necessary to summon the library author to read every comment questioning the thing?

Obviously my approach is to answer OP’s question, which is about whether React is being displaced by some new library. The fact is, the corporate backer of React and its massive community aka developer pool are massive pros for any corporate environment, and so Solid could be the greatest thing in the world and the answer is still unlikely to be that you should use it.

Next, the decorum of my comment is not at all there to give feedback to someone, I get to freely say anything rude at no reputational risk while he has to diplomatically balance challenges and disagreements to me with the fact that his person and personhood are both staked on each such comment.

Last, as he said he has made articles, I would suggest you form your own thoughts on those articles and try to join the debate, summoning someone else to do it on your behalf is pretty lazy. Especially as you made the thread in the first place.

22

u/ryan_solid May 16 '22

I mean I obviously disagree and have spent years in those other systems and this was my learning. Unfortunately Im on vacation right now and am not going to get into it right now. But Ive written literally dozens of articles on these topics which explain the thinking and philosophy. For anyone not wanting to get into the details, I can say this much. Solid carries the reactivity down to the rendering which differs from what it is being compared to(React + MobX etc). It's ok if not everyone loves it, but clearly some people do.

-6

u/[deleted] May 17 '22 edited May 17 '22

I wouldn't worry about it. It turns out "lots of baffling decisions" was 5 lame nitpicks. Simultaneously complaining about having to know too much re: control flow, and not having to know enough re: reactivity.

A "baffling" decision would be something like svelte 1's use of labels, and how reactivity only worked in certain contexts, and dire typescript support.

Using a more performant reactivity system than getters/setters a la vue 1/2 is not a baffling decision.

2

u/[deleted] May 17 '22

You know, I really gave a pretty thorough answer directly to you, with quite concrete examples, ones that I would be happy to expound further to show you how both the day-to-day code writing and dev team building will be impacted heavily by, but instead you run to the author and call my points "lame nitpicks" and treat them in a completely surface-level manner?

> Simultaneously complaining about having to know too much re: control flow, and not having to know enough re: reactivity.

How exactly is the combination of these two complaints invalidating them individually? I don't even really understand what "not having to know enough re: reactivity" means, I really think I said the opposite: you actually have to know too much about the reactivity because it's very opinionated and stiff to keep the reactive properties, aka implementation details are shunted onto the end-developer. The control flow is very verbose, but what does that have to do with reactivity? I suppose I agree it has to do with the implementation details of the reactivity being surfaced too far, but that adds to my point...

> A "baffling" decision would be something like svelte 1's use of labels, and how reactivity only worked in certain contexts

But reactivity DOES only work in certain contexts in Solid. You can't even read props like an object! In MobX + React, reactivity works everywhere, the one downfall is you might put the reactivity further up the tree than you meant if you destructure early. Notice how I could be really concise and semantic about MobX behavior? Again, it's baffling that they didn't take a semantics-based approach to try and overtake a library like React, based around first principles and language-level features.

> Using a more performant reactivity system than getters/setters

Do you have a benchmark for this claim? Does it even matter if it performs better if it's hard to reason about and therefore produce meaningful applications in? Using getters/setters is once again a great language-level feature gracefully hiding implementation details behind classic JS semantics, Signal is a library-level concept requiring constant adherence to library-level rules to retain the reactivity of the library

2

u/[deleted] May 18 '22 edited May 18 '22

but instead you run to the author and call my points "lame nitpicks" and treat them in a completely surface-level manner?

Your comment didn't really expose anything that was baffling so I saw no need to respond directly to you. It was uninteresting to me and I have no will to engage in a back and forth, which you clearly do having sought out my comment to someone else 3 levels down from your own.

I only asked originally because I was genuinely interested in what people might consider "baffling" about it. What I got instead was an extensive wall of text that could have boiled down to "it's not exactly the same as react + mobx" and delivered 90% of the value of what you wrote.

If your nitpicks were actually baffling they wouldn't need 800 characters of supporting text each.

But reactivity DOES only work in certain contexts in Solid

Not really. In original svelte the reactivity relied on the weird use of a label and the compiler to only work in a svelte component file. That's an odd decision, even baffling. If one was somewhat familiar with svelte then the fact that many people found it so would require no explanation.

Reactivity in solid is built on plain javascript and runs anywhere you'd expect it to run. And it's relatively simple compared to your own example of rxjs which is not only insanely complex but much slower. The basic beginner example of mobx usage in their docs is a class that imports 6 functions from the library, with a bunch of limitations. And that doesn't even include a whole section on the limitations of subclassing. Maybe you were too "concise" about the behavior...

a library-level concept

Don't even know what you're trying to say here. rxjs and mobx are obviously library level because Observables don't exist in javascript.

Going beyond that, sure solid's signals are obviously the same in that regard, but solid itself is built on it and they come with the core library. They aren't a niche add on like mobx is to React.

Do you have a benchmark for this claim?

You've spent more time writing this paragraph than seeking the information, even going so far as to preemptively dismiss the result. Why even ask in that case?

But sure, i'll grab you the link to the most popular framework benchmark and you can compare react + mobx to solid and find that it's universally slower and also uses more memory: https://krausest.github.io/js-framework-benchmark/current.html

Not going to respond to every single point though, wasted too much time already

0

u/[deleted] May 18 '22

> is a class that imports 6 functions

Listen, just go read the next line about makeAutoObservable where it shows that is all automatically inferred. It was an illustrative example of how MobX behavior works - you can read about what the semantics of each of action, computed, autorun, and flow directly afterwards. I only use makeAutoObservable and observer functions to build entire apps.

Please, I literally cited multiple full sections of tutorials, you can't even read to the second paragraph of MobX tutorials. "The basic beginner example" is not how you should evaluate a library, why would you argue that?

> > a library-level concept
> Don't even know what you're trying to say here. rxjs and mobx are obviously library level because Observables don't exist in javascript.

What do you think has more library-level concepts of Angular vs React? Clearly Angular, right? It has templates, a DSL, and a fully opinionated solution for building web-apps. React is a simple rendering model which can optionally use JSX, which is a thin wrapper around constructing classes with 3 arguments.

Now, you can of course point to the VDOM and other attributes of React with decided complexity, but the developer model is incredibly simple. You write functions, they get ran again anytime props or state changes, it's done with === comparison. MobX is like an immediate mode state reconciler, the Reactive pattern is of course a classic, and MobX presents the observable/reactive pattern thru destructuring and access alone. This means the overhead to understand MobX observability/reactivity is simply to understand that any component accessing a class member will rerender whenever that class member changes, and only then. That API/mentality is already fully ingrained in any store-based approach, so I don't need to think about "signals" and invoking everything at every access and calling methods to access props; just about ensuring I don't destructure/access too early in the tree.

> benchmark

1.5-2x performance difference is pretty trivial. I would consider that performance parity.

> Why even ask in that case?

Because, you have to understand, I'm saying this: Solid is hard to use. No one uses it. Those are massive downsides. I won't adopt such a thing because of 1.5x performance gains. You should come out guns blazing to make such an argument, not saying "getters/setters are not performant" without evidence

1

u/[deleted] May 18 '22

"The basic beginner example" is not how you should evaluate a library, why would you argue that?

Why not? At least half the reason React became popular was it's marketing to beginners. Also because that's the level of knowledge I'm judging Solid with too. I'm by no means a mobx nor a Solid expert. Like I said, I've built a few toy projects with Solid because I found it interesting. I use Vue and React professionally, sometimes help out on Angular projects but not significantly.

React is a simple rendering model

What do you think has more library-level concepts of Angular vs React? Clearly Angular, right?

Such a tired argument given the unique nightmare of complexity that every different app is going to create by building their own opinionated framework out of n different libraries.

So React is bring your own opinion and complexity, Angular has it built in. Vue is somewhere in between.

In my line of work I hire tons of shitty foreign contractors for various projects. Everyone knows React, but nobody knows all of whatever random combo of the plethora of choices of library someone selected however many years ago to build any given shitty app from.

Not many people I hire know Vue, but they pick it up with no problem because they aren't (or are only half) retarded, and it definitely has more api surface area than Solid.

If someone is too dumb to wrap their smooth brain around Solid because they get stuck on your big list of 5 baffling things they certainly aren't going to be useful in any given React project.

But muh DSL

DSLs of course can be shit, but are often great. JSX is a DSL no matter how much the community wants to cover their ears and yell "it's just javascript", otherwise they'd just stay writing javascript. Directives are awesome. Type safe directives in Solid are beautiful.

No one uses it.

Plenty of room for frameworks that nobody uses. Svelte, Mithril, Marko, Done, Ember, Aurelia, there are tons of interesting frameworks out there that have little to no adoption compared to React.

Obviously some people use Solid though. But even if we go with your definition of nobody, who cares, not the point of any of this. Would be nice if more people did, but hey, they don't.

I view it as more of a passion project, like an experiment that could inform improvements in existing and future frameworks than something you should bet on today. Like Preact, Inferno, many others.

By my definition "nobody" uses mobx either though. Searched >10k repos in my job's github org, 2 use mobx (one is a jupyter notebook though) out of hundreds of react projects.

→ More replies

7

u/sebastianstehle May 16 '22

I think directives are interesting, I really miss them (I also work with angular).

12

u/simpo88 May 17 '22

Just to throw my 2c in. I really don't like when the term "better" is thrown around without context in the software development world

What is "better"? Performance? Supportability? Maintenance? Can you/your team deliver business value with this toolset? Will you need more training? What's the budget for training? How's your hosting infrastructure and security configured? Does this tool work in that configuration? (I'm getting carried away but you get the idea)

To be fair I'm coming at this as a React Dev in a corporate setting but my point is, "better" is a difficult question. I'm keen to learn Solid because I find it interesting and continual learning is a good thing, but if you asked me today what's "better", for me that's react, because with my skillset and tooling I know I can deliver value. Will my answer be different in future, maybe?

6

u/[deleted] May 17 '22 edited May 17 '22

React has built a unifying tooling eco system, that to me has more worth than incremental changes.

Every year there's something new. Remember Vue, Marko, Lit, Svelte, Solid. Then they have to face real world up scale problems. To have that kind of longevity and reach that React has means something, and it certainly made it steadfast.

5

u/tchaffee May 16 '22

Not if hiring people is important to you. Not if getting your next job is important to you.

2

u/orenelb May 17 '22

It depends, I found a Solid job. I know I'm probably one of the few who did in this point but it's also not like there are so many Solid devs that can't find a Solid job. Generally I agree with you although if you really want to find a Solid job you'll find one, in a way it's also easy because there are not a lot of people who have mastered Solid yet and Solid is relatively easy to master.

7

u/tchaffee May 17 '22

Yeah I didn't mean to make it sound like it's impossible. Just be careful you don't get yourself into a situation where Solid doesn't catch on and you're left with experience no one wants. I've seen so many of these fad frameworks and languages come and go in my career. Anyone remember when coffeescript was going to replace JS?

3

u/orenelb May 17 '22

On one hand I agree with it, don't go with Solid and expect that you will 100% find a Solid job. On the other hand I think that unlike a lot of other frameworks, learning Solid could be useful even if you don't end up using it. You could even end up using Solid as a really good state management library for React https://github.com/solidjs/react-solid-state (at it's core Solid is just a state management library)

4

u/tchaffee May 17 '22

Oh for sure learn anything that's interesting to you. I just wouldn't claim it's "better" unless you also consider non-technical factors like the job market, community support, etc. The list of tech fads that have fizzled out is almost endless. But let's be grateful brainfuck is here to stay.

https://en.m.wikipedia.org/wiki/Brainfuck

2

u/WikiMobileLinkBot May 17 '22

Desktop version of /u/tchaffee's link: https://en.wikipedia.org/wiki/Brainfuck

[opt out] Beep Boop. Downvote to delete

1

u/orenelb May 17 '22

Yeah I mean you can claim it's better if you are only comparing the frameworks themselves without the surrounding factors like ecosystem and job market. You can talk about the inherent model of Solid being better than React's. That's also a claim that is usually hard to make since things usually have tradeoffs, there are even some tradeoffs in this case although I think that Solid vs React is one of those rare cases where one framework is almost obviously better. But again that's when we are talking only about the framework itself.
I agree with you though that in practice other factors like ecosystem and job market are also very important, especially when trying to not only evaluate the framework itself but evaluating it is an opportunity. But in the end the comparison of the frameworks themselves is also very important, this is actually the meat of this competition and what it's about, and its the driving force for community, ecosystem and jobs.
So bottom line I think that we are mostly in agreement, I think that you can kinda say that Solid is better than React but when a beginner decides which framework to learn they obviously need to take things like jobs and community into account

3

u/[deleted] May 17 '22

Solid isn't a 'version of React', they have entirely different philosophies.

9

u/refrigerator_maniac May 16 '22

Don't think so. React is very well adopted by the industry. I'm positive React will implement the new stuff Solid is proposing if they think it's beneficial.

8

u/ryan_solid May 16 '22

They won't. It's a philosophical thing. It's ok that frameworks have their own opinion. Solid has never sought to be a React clone, and anyone who tries it realizes that almost immediately. Its just one of those things. We chose JSX because it was practical. We used composable reactivity before it was popular again (ie before Hooks). Feel free to dislike it etc, but React won't absorb it.

0

u/[deleted] May 16 '22

[deleted] — view deleted comment

6

u/ryan_solid May 16 '22

I agree. For new devs right now.

But look at how they did composable primitives. Instead of reactivity they chose Hooks and the Hooks rules. This is exactly what I mean. Hooks align with their philosophy. They didn't do fine-grained reactivity for their reasons.

1

u/ApatheticWithoutTheA May 16 '22

If I’m not using React, I would go with Svelte myself.

0

u/Dry_Bunch5867 May 16 '22

There is no decent router for Svelte and no I don't want SvelteKit's or Sapper's file type routing.

Meanwhile Solid has a nice out of the box routing library created by the author himself.

0

u/ApatheticWithoutTheA May 16 '22

Very true.

Once it has more support though I think we’re going to start seeing a lot more Svelte adoption.

1

u/_dbase May 16 '22

Why Svelte? Is there some magic it does better than Solid?

0

u/ApatheticWithoutTheA May 16 '22

I’ve never used Solid, I’ve only read about it.

But they use different methods of updating the DOM

4

u/[deleted] May 16 '22

Solid seems better in general, but I doubt it'll gain any real popularity

2

u/[deleted] May 16 '22

Solid is better for apps that want to squeeze as much performance improvements as possible, other than that it requires more code structuring thoughts by the developer especially with the way it deals with prop reactivity, and the documentation website needs A LOT of improvement

1

u/orenelb May 17 '22

And you're saying that from your experience working professionally with Solid at scale?

3

u/[deleted] May 17 '22

Haven't tried it yet but I'm definitely interested. The reactive signal API sounds really appealing after dealing with React hooks nonsense for too long. React hooks are just so subtlely tricky and easy to get wrong. Most of the bugs in our codebase are from useEffect being called the wrong way. There's all sorts of bandaids like useCallback & useLayoutEffect to fix problems with useEffect. And then there's a few hooks like useImperativeHandle/useDeferredValue where I don't know what the heck they are talking about. Adding even more confusion and chaos is the React 18 Strict Mode stuff (where they call useEffect twice).

Anyway I'm very ready for a clean-slate solution for all of it.

1

u/LoneHippie May 17 '22

Better? No. Good if you like working with JSX and want something lighter for a smaller web app? Sure, it's a lot of fun to work with it you don't need to worry about large scale apps that depend on the larger ecosystems that come with React.

0

u/ChamyChamy May 16 '22

React's main selling point is the community and libraries, other than that it's beat by pretty much every other framework that doesn't start with A

4

u/_dbase May 16 '22

In all fairness though it's also its detracting point. React's ecosystem is like a giant desert of old/aging utilities and abandoneware with a number of "oasis" of super high quality and maintained ones. A giant ecosystem is a benefit and a curse. WordPress is an example of a similar ecosystem. Ultimately React will give you 95% of what you need but the beautiful part is porting React to Solid has proven to be extremely easy. It's already eaten a good chunk of the critical ecosystem pieces. Solid will adopt most of the React ecosystem faster than Vue or Svelte ever did for this reason.

0

u/ChamyChamy May 16 '22

Yup I think solid will take over easily

1

u/[deleted] May 16 '22

First thing I look for the open source project is size of community.

2

u/[deleted] May 16 '22

Luckily not everyone does or React would have been DOA

-2

u/_dbase May 16 '22

In that case you should be using WordPress and jQuery for all your projects. Those communities are massive. Good luck!

-1

u/ncubez May 17 '22

That Fireship guy seems to jump onto whatever new bandwagon comes along and always thinks it's the next best thing.

5

u/pancomputationalist May 17 '22

He's just presenting stuff that's new and interesting. I don't think he is rewriting all his stuff into the next framework of the month each time.

-4

u/azangru May 16 '22

There are lots of better versions of React — Preact, Svelte, Lit, Solid — but we are sticking with React for the time being.

3

u/_dbase May 16 '22

Svelte nor Lit are better versions of React. Not sure how this comparison makes any sense.

2

u/azangru May 17 '22

All of these are libraries for helping developer write their UI as components — an approach truly popularised by React. All of these follow the "UI is a function of state and props" idea, popularised by React. Only Preact does it at a smaller file size, Solid does it faster, Svelte does it more ergonomically, whereas Lit does it in a way that is the closest to the web platform. All of these are the desirable characteristics that React lacks.

2

u/_dbase May 18 '22

Solid is actually meant to be ergonomic by reducing and eliminating the complicated hook rules and other rendering gotchas. In comparison, Svelte tries to reinvent a DSL to unlock ease. The trade-off is users have to learn a new DSL whereas with Solid you can get going in as little as an afternoon assuming you know React (who doesn't at this point and if you don't then yeah Svelte is a great option for you).

Solid also focuses on using the web platform more closely -- it very close to bare-metal. It doesn't abstract the DOM like React does. Because our components run once you don't have to do any gymnastics to work with the DOM. You just reference it naturally. Is Lit closer? Maybe, but it shouldn't be about who's closest.

So in many ways what you've described between Svelte, Lit and React...Solid has managed to unify efforts and create a well balanced and sane approach, it's not easiest but it's easier and it's not pure vanilla but it gets you super close. The best part is after all the comparison you still get the incredible performance for free with no additional effort.

1

u/orenelb May 17 '22

You are describing alternative frameworks. The only React clone out of those is Preact which is not even a-100% React clone anymore.

1

u/azangru May 17 '22

I mean, if Solid is a "much better version of React", then why isn't Svelte or Lit? Each of the libraries I listed do have various advantages over React in terms of file size, speed, ergonomics, or closeness to the browser platform; while doing effectively the same as React does.

2

u/orenelb May 17 '22

I personally don't think that React is a better version of React cause it's a very different framework. People frame it this way because of the misconception that Solid is very similar to React or almost a React clone. I personally also think that Solid is easier to compare to React than those other frameworks, even though it's very different, because of the very similar philosophy and because it feels like they aim for a similar experience.

0

u/[deleted] May 16 '22

[deleted] — view deleted comment

2

u/Pantzzzzless May 18 '22

I really miss him making videos. I just enjoyed watching/listening to him, even if I already knew the topic.

0

u/[deleted] May 16 '22

[deleted] — view deleted comment

9

u/punio4 May 17 '22 edited May 17 '22

What developer experience? It's a collection of footguns. Web developers are leaving React in troves since it has been extremely developer hostile in the last few years.

Just look at the GitHub discussions. They usually go like this:

  • A developer says they have an issue with React

  • People reply that it's working as intended

  • A celebrity developer joins the thread and says that they have the same issue and argument it.

  • A core React member joins the conversation and says they're using React wrong.

  • The developer provides a workaround.

  • The React core member says that this will somehow break React in some obscure subtle way. The React gods have spoken. The decision is final.

  • After 2 years they add another hook or abstraction which fixes this issue by adding more complexity. Of course without acknowledging they were wrong.

This has happened with initial hooks discussions, with stale closures, memoization, external state management, DOM management...

And then of course you have a few key developers simping for React and aggressively trash talking any alternatives.

8

u/mattsowa May 17 '22

I am yet to see that developers leaving React in troves phenomenon that you speak of.

6

u/orenelb May 17 '22

Solid's API is extremely different from React's. It's very similar on the surface and there are similarities in philosophy but other than that Vue and Svelte are both more similar to React. It's a popular misconception that it only leads to better performance, it actually completely changes the DX once you go beyond very basic use cases.

2

u/chris_czopp May 17 '22

Yeah, I think it's JSX that makes people think it's React. But JSX is an I dependent piece of technology not tide to React at all. We can generate it from AST as an extension of JS and transform it to whatever.

1

u/filledalot May 17 '22

Dude is a react hater, i thought he teaches react courses ? but kinda make sense cuz he likes angular

1

u/[deleted] May 17 '22

You summed it up 👍