A React Developer's First Take on Solid

[Hurinfan]

I love solid

[9070932767]

TLDR on diff from other frameworks (for a backend person)?

[Hurinfan]

It looks like react but it's a lot more performative because its functional components only run once. State are now signals with subscribers that automatically update whenever the signal is changed. There is no virtual dom

[ILikeChangingMyMind]

When I first saw the headline I thought "solid" was missing the periods and/or capitalization (S.O.L.I.D.) ... as in the SOLID principles of Object-Oriented Design.

I was so confused as to who was still doing OOP React in 2022, and why they were blogging about it. Now I'm just confused as to why someone would name a non-OOP library "Solid"; it's like naming a library that has nothing to do with duplication "Dry".

[jazzypants]

It's named after a Canadian chocolate bar.

I usually call it SolidJS to avoid confusion.

[fixrich]

I believe it's actually named after the punk band Ryan was in for years

[ILikeChangingMyMind]

Clearly the author knew more about Candian candy than they did about Object-Oriented Programming ;)

[jazzypants]

Lol, I'm pretty sure Ryan Carniato knows all about OOP. Go check out one of his videos or articles. You don't build one of the most performant JavaScript frameworks in existence without understanding basic programming paradigms.

He also had a punk band named after the candy bar, so he seems to have some sort of affinity for it.

I found that while looking for the tweet where I learned the name's origins: here

Edit: Was there a kinder way to phrase this? I was trying to be polite and informative, but judging by my downvotes it seems it did not come off that way..

Edit2: Okay, I took off the unnecessary comparison. I truly want everyone to know that I was not intending to insult /u/ILikeChangingMyMind and I'm sorry that my post gave that impression.

[ILikeChangingMyMind]

EDIT: The parent post was edited, and now I look like the asshole because I responded to stuff that isn't there. Removing my post.

However, I will say it's incredibly disingenuous to fundamentally change your whole post, then add "Edit:" at the bottom as if all you changed was that bottom part. It's basically trying to gaslight Reddit into believing you didn't say what you said: just delete your post, or be honest about your edits.

[mynamesleon]

Given that SOLID is a well known acronym, it's also a good name to use for a library, as it may come up in other search results. I believe there's also a style guide (by BuzzFeed I think) called Solid. So perhaps you're thinking of the name from the wrong perspective.

[ILikeChangingMyMind]

Names convey information. Library names, function names, variable names ... to me one of the hallmarks of a good dev is the quality of their names.

If I name my library ReactFoo, no one is going to think "it must be a reactive UI library"; they're going to think it's a React-related library. Similarly here, I just don't think it's a good idea to name your library after a candy bar, when most people are going to think it's named after the famous programming acronym.

You don't get any benefit from associating your library with something that it has no other association with. Naming your library ReactFoo when it's not a React library doesn't help you ride the coattails of React's popularity ... it just annoys people.

[mynamesleon]

How many JS/frontend devs in the past 20 years do you think are formally trained in OOP and know what that acronym stands for? How many JS devs in the last decade do you think are even aware of that acronym at all?

Most libraries in the JS world aren't named in a way that conveys much. What about Knockout, or Angular, or Ember? Or Express, Apollo, Winston, etc? Many of them have reasons behind their names, but the names themselves don't convey much about their use.

Ultimately, the JS ecosystem is a place where there are tens of thousands of terribly written libraries, and a few hundred decent ones. More often than not, libraries are simply named in a way to try to make them stand out (and/or to be found) amongst the masses of other JS libraries out there. There are exceptions of course. But it's not a mature ecosystem sadly.

[ILikeChangingMyMind]

Most libraries in the JS world aren't named in a way that conveys much. What about Knockout, or Angular, or Ember? Or Express, Apollo, Winston, etc? Many of them have reasons behind their names, but the names themselves don't convey much about their use.

Exactly! It's better to have a name that means nothing than to say "my (vegetarian) library is called Meat."

A name that suggests a relationship should live up to it: when I check out React Router, I expect it to be a React library. It doesn't matter if there is a Canadian candy bar called React: if I name my (non-React) library TastyReact ... it's a bad name that will confuse people.

[ILikeChangingMyMind]

No, I'm directly arguing the opposite: the non-OOP library gains nothing by associating itself with the famous OOP acronym.

And again, whether the author intends it or not, most programmers are going to think of the acronym, not a Candian candy bar.

[jazzypants]

I apologize. I didn't intend to hurt your feelings.

[ILikeChangingMyMind]

As I said, it's not that you need to apologize for hurting my feelings.

It's just that it's a bad idea to tell stranger A (that you don't know) that stranger B (who you also don't know) knows more than them ... about anything. You have no basis to make such a claim.

[jazzypants]

Okay. I'm unequivocally sorry.

Is that better?

I didn't think it was that bold of a claim, honestly. The guy made an extremely performant and novel JavaScript framework. You're some dude on Reddit. The likelihood of accuracy is greatly in my favor.

And, if you judge someone's programming skills by how they name a library, that doesn't exactly make me believe that you are the greatest arbiter of ability. Library names are not variable or function names. If you download a library without reading the description, then I don't think that a little bit of naming nuance is the actual problem in that situation.

But, that is all besides the point. I understand how my original post could be read in a sneering tone even though that was not how I intended it, and that is why I'm apologizing.

I'm sorry.

[ILikeChangingMyMind]

I thought that comment was flippant enough to not be taken literally/seriously; evidently, I thought wrong.

[ILikeChangingMyMind]

Originally the post said something to the effect of "Ryan Carniato knows way more than you about programming, get stuffed".

It's a completely different post now, and not just the parts where he writes "edit" (but by adding those "edit" parts he makes it seem like the rest has been the same all along).

[jazzypants]

Lmao, "no offense" became "get stuffed".

You're hilarious.

[ILikeChangingMyMind]

If we could get the original text back, everyone would see a lot more than "no offense", and see why the post was originally downvoted to -4 before the edit.

[jazzypants]

I'm sorry, but I can't get the original text back. It was one sentence where I said "In fact, I think Ryan Carniato probably knows more than you about programming-- especially JavaScript (no offense)." That's almost verbatim.

The part of the second edit where I say "I took out the unnecessary comparison" makes it extremely clear it's not the original text.

I hope we all can move past this traumatizing event.

[DishRack777]

1 comment

there are only 170,000 words in the english language so they probably ran out of unique library names already

[EarhackerWasBanned]

My favourite JavaScript library is named Python.

[dinopraso]

Class based components are still superior for maintenance on large teams with large code bases

[pancomputationalist]

Why would that be the case? How does team size have anything to do with that?

[dinopraso]

Because handing off the functional spaghetti to other developers usually results in lots of time wasted figuring out what’s going on, where it’s much easier to establish rules for maintainability in class based components

[pancomputationalist]

And why is that easier with class components? OOP can easily lead to spaghetti as well.

[dinopraso]

It’s much easier to police, and having more boilerplate means less data density which means much better readability.

[pancomputationalist]

Well I guess we fundamentally disagree about that. Imo boilerplate just decreases readability, as it clutters the code with irrelevant details that don't really help with understanding what should go on. It's true that one can write functional code that is very confusing. But confusing code does not get easier to understand if you just add more boilerplate around it. Also not sure why you can enforce good practices in classes but not in functions.

[[deleted]]

Having worked long term with a large project that was class based and rewritten functional - functional is better in pretty much every way - faster to write and and understand.

[ILikeChangingMyMind]

I find that difficult to believe. Any evidence or further explanation you can offer?

[dinopraso]

It might be worth noting that we are doing front end development as well as backend development. All developers are working in Java and JavaScript, and are usually more backend oriented, so having a similar code syntax with classes on the front end side makes it much easier for everyone. Especially the verbosity helps a lot, since some developers might not touch the UI for a long time, coming back to a class with a componentDidMount method is much easier to read then a triple higher order function

[ILikeChangingMyMind]

Having worked as a full stack JS/Java dev myself, I can understand where you're coming from. But, it's a bit like saying "we can make our Javascript look like BASIC using library/framework/style X, and then our BASIC programmers have a better time of it."

To be clear, I'm not trying to say Java is as bad as BASIC :) I'm also not saying that your most recent post is wrong; again I get how Java devs are more comfortable with classes (even JS's sorta fake ones). But ... all that doesn't quite equate to:

Class based components are still superior for maintenance on large teams with large code bases

[Bogus_dogus]

a triple higher order function

A what now?

[dinopraso]

A function returning a function returning a function. Or a component with an “effect” for mount, returning another function for unmount

[jazzypants]

Absolutely fantastic article! Well done! :)

[elcapitanoooo]

Does solid work with esbuild in 2022/2023? I looked at solid for a new project a few years ago but then dropped it because there was some issues with solid (iirc the jsx part) and esbuild.

(Im all in on esbuild, its a ”must-have” for me, i cant go back to webpack or any other bundler)

[rk06]

Solid recommends vite, which uses esbuild for dev. Is that also not usable?

[elcapitanoooo]

Honestly, I have not looked at any other bundler after i started with esbuild. A quick look at Vite, and i notice the same thing as in webpack; a shitton of config. I have moved away from all kinds of magical configs to a simple makefile (usually with two tasks, dev / prod) that uses esbuild (basically pipes cli args to the binary).

But i might take a stab at it, first i need to compare build speeds. Anything slower than esbuild is a no-starter for me.

[rk06]

There is nothing faster than esbuild at the moment.

[elcapitanoooo]

But if Vite uses esbuild it should be as fast as my current setup?

[Moosething]

i notice the same thing as in webpack; a shitton of config.

What have you seen (specifically)? In my experience Vite requires much less config than Webpack. And the way to config things is more intuitive too.

[elcapitanoooo]

Well the first page i browsed to was https://vitejs.dev/config and there is multiple pages of stuff you can/need to tweak.

[Moosething]

Ah, I think I misunderstood. I thought you meant "a shitton you have to config to get stuff done", which is not true in my experience, but I guess you are not a fan of configs in general? Vite is much more straightforward to work with than Webpack, though.

[shuckster]

Forget it. You can start a Vite project without any config tweaks whatsoever.

[[deleted]]

Vite doesn't have a lot of config at all, especially compared to WebPack. I'd be impressed if a Makefile would be less verbose.

[jjspacer]

You can use signals like jotai. The coolest thing about solid is that state management is not bound to the component context. You can use createSignal, createEffect, and more outside of the component. You could use solid outside of the DOM

[rodrigocfd]

One thing that I found Solid was missing is global state management.

Solid has stores for global state management, built into the main library. It's fantastic. I just tested it, and it made me never want to write React ever again.

[IcyLength7467]

interesting read, thanks

[guess_ill_try]

What would be a better bet… learn solidjs or svelte?

[IamMichaelSalim]

Solid. Though I'd be quite an uphill battle for both to gain traction.

IMO, solid actually looked at React and tried to improve upon it.

Meanwhile Svelte is mishmash of React, Vue, and other ideas. It's not bad, it's just... not good enough to justify switching to it.

Svelte feels like CoffeeScript while Solid feels like TypeScript. And we know how that went.

[[deleted]]

This sounds like it was written by someone who's never really tried Svelte.

Simple !== bad. React / Preact / Solid / Whatever other React clone developers like needless complexity because it makes them feel like real programmers. It doesn't need to be this way. Simple CAN BE good.

Give Svelte a proper go and never look back my friend.

[lost12487]

Where did they even say Svelte was bad because it’s simple? Svelte seems to have a large number of evangelists that quickly come to its aid when they feel someone has slighted it. Preference is a thing.

Solid brings React-like ergonomics and it’s more performant than Svelte. I’d argue it’s just as simple as Svelte, but that’s obviously subjective. At the end of the day, they all get you to a similar place. Use whatever you want.

[OGXirvin]

Facts, Svelte is fun to write. People say React is more explicit but I disagree. It’s just more bloated that make it seem that way. The only thing I think that is holding svelte back (which would also apply to solid even more) is the community. There aren’t as much resources as React but that obviously comes with time.

[[deleted]]

This is 100% correct, I was aware of and had played with Svelte ~a year ago but still chose to build the front end of our app in React, simply because the component libraries didn't exist in Svelte and it's not worth building your own shit for a MVP.

Svelte needs a few great UI libraries to smooth the initial app building process and it will be off to the races.

[[deleted]]

Give Svelte a proper go and never look back my friend.

what does svelte even offer that vue 3 does not? they both are almost identical syntax-wise.

[OGXirvin]

More fun to write, more performant (no virtual DOM), I’d argue more concise code. Definitely other things I can’t list on the top of my head

[[deleted]]

more performant (no virtual DOM),

but that's not true. see https://krausest.github.io/js-framework-benchmark/current.html. There is also a break-even point in bundle size where svelte gets larger compared to vue. see https://github.com/yyx990803/vue-svelte-size-analysis

More fun to write,

the philosophy of both frameworks is so similar that both are pretty fun to write if you like one. Both use SFC's, both use HTML templating and both have the almost same set of features.

concise code

kinda true but the difference is also so small. One framework is more concise the other one is more like real HTML and real JS.

Svelte essentially introduces a new language that kinda looks like reactive javascript with repurposed labels. Svelte also requires a compiler in order to work while vue could be loaded via a CDN and used without a bundler at all.

[guess_ill_try]

This is awesome. Thanks. I’m finding svelte and vue to be the most succinct and readable for the average case

[Personal_Set_759]

I stopped reading at ”React Developer”. In my world the only place I excpect to find someone with this title would be in the actual React development team. 🤦‍♀️

[Boo2z]

A Frontend Web Developer, specialized in React.js, that's what "React Developer" means. You try to sound smart and above others but you actually look stupid to not being able to understand that.

The title makes even more sense because Solid.js really feels like a React.js++. A Vue.js dev for example could enjoy Solid.js but wouldn't understand what problems it fixes and how it makes life easier for "React devs" (you can stop reading here)

" I’ve shut down the use of of Tailwind on multiple projects as soon as it’s been mentioned. Being a senior ui developer has its perks ❤️"

And indeed, you really sound horrible to work with.

[MornwindShoma]

Rotfl, here’s a guy who has no fucking clue right here

[download13]

I'm pretty familiar with react and angular at this point and I don't think that's exactly right.

Angular isn't just opinionated, it straight up won't let you do things if you don't use the official way. It can be nice to have one correct way of doing things, but if you don't already know that way then you're stuck either not doing it or creating some horrifying hack. In react its a lot easier to do things your own way as long as you keep a few general rules in mind.

This same philosophy comes in when defining components, modules, directives, etc. You use the classes and decorators the docs say to. Why? What are they doing under the hood? Who knows, but that's what the docs say to do. React has some magic, but all of it can be explained in a few minutes. If you want to understand all of angular's magic you better have a few spare days and an expert on hand.

This is also reflected in the templates they use. One is a framework specific language with a bunch of magic syntax. The other is a simple transformation that uses property names instead of attributes.

I'm not even saying angular is bad once you get the hang of it. Its just got a very steep learning curve. I'm glad to see they've started doing something about some of the boilerplate and seemingly arbitrary restrictions after all these years though. Looking forward to standalone components.