31 ms·
Solid.js feels like what I always wanted React to be
- parhamn 5y agoIf theres one React recommendation I'd make is: use Mobx.
- smt88 5y agoThis is interesting because it's a bit like Svelte, but it doesn't use the Svelte "language" (which looks like JS and HTML but, in some crucial ways, sometimes isn't). It's a little disheartening to see that it's 3+ years old and has only had a single significant contributor though[1]. It's impossible to avoid single-contributor projects in the JS world, especially with Node, but the alternatives (React, Vue, Angular, and even Svelte) are orders of magnitude more popular, so it's one area that we can play it safe if we need to. 1. https://github.com/solidjs/solid/graphs/contributors https://github.com/solidjs/solid/graphs/contributors
- armchairhacker 5y agosolid.js may only have a single contributor but i believe it’s been battle-tested and used in some larger projects (don’t have any examples off the top of my head though)
- jamghee 5y agoI have no idea if it's in the creator's interest but I'd love to see Solid get backed by a company the way React, Angular, and Svelte are. That might make people take it more seriously as an option but, as-is, it certainly feels like a risky option to use professionally.
- lhorie 5y agoFWIW, the author joined the Marko core team at eBay a while back. But from what I hear, he's still pretty responsive on Github.
- ConsoleTVs 5y agoSolid is sponsored by Vercel, Cloudflare and Netify
- ryansolid 5y agoI'd also look at other repos. Admittedly for the core code it has been mostly me. I think there is an intimidation factor. When you create a library this performance oriented it is hard to get people comfortable working on the core. But things like the site, docs etc.. are much more contributors making more substantial submissions: https://github.com/solidjs/solid-site/graphs/contributors https://github.com/solidjs/solid-site/graphs/contributors https://github.com/solidjs/solid-docs/graphs/contributors https://github.com/solidjs/solid-docs/graphs/contributors We would have never gotten the docs translated into 15 languages otherwise. I do agree that one should be cautious regardless. But I don't want to underplay the contributions of many contributors putting in improvements every day.
- mst 5y agoThere are projects of mine where I'm the only relevant core contributor but the ecosystem is developed by many other people and it's largely worked out fine. I would hope that if either of us got hit by the proverbial bus that people involved in the ecosystem would pour themselves a strong drink and dig in to the necessary maintenance anyway. Projects I've ended up moving on from have regularly worked out that way, and I think that while solid might not be as popular as some people would want for something to bet their production code on, it does seem to me that it's popular -enough- that I don't believe you're a truly dangerous single point of failure here. (if this comment read as negative rather than an attempt at a clear eyed analysis, I apologise for phrasing it wrong)
- thex10 5y agoAs someone who doesn’t feel so enamored with React’s hooks, I find this compelling.
- jamghee 5y agoReact hooks are footguns
- adam_arthur 5y agoVue hooks avoid the closure/scoping issue mentioned in the doc. Very similar conceptually, but I find Vue's implementation a bit nicer to use
- MarcelOlsz 5y agoTook me 30 minutes to get up and running in Vue. Week 4 of this job and I still can't unfuck myself with React.
- kevinmchugh 5y agoI'm missing some toes from the old react lifecycle methods. The vanilla hooks were easy to use, reason about, and robust against misuse in a way the lifecycle methods weren't. I could see custom hooks being more dangerous and difficult, but Higher-Order Components are too.
- preommr 5y agoI swear we're just going around in circles because people only have a surface level understanding of these front-end frameworks, and the challenges with building at scale. react isn't about 'hooks', 'jsx', 'top-down-state', or 'component-driven architecture'. All these frameworks are component-based, can have top down state only (or do bottom up in react), can use things like jsx/hooks because it's just syntactic sugar (vue has jsx support). react is fundamentally about 'inputs changed, render this'. This got rid of a lot of issues with poor code because frameworks had crappy DX (angluar 1 scope nonsense, and overengineered DI concepts), and people were bad at tracking side effects because a lot of people just wanted a search bar with some cool features and not everyone was building sophisticated products. That setInterval example is fundamentally against what react is, and is basically svelte/vue/(react + mobx).
- rk06 5y agoThe thing is that While react is against side effects, javascript is not. Which result in these impedance mismatch where what devs want is against react itself. Vue/svelte/solid do not fight against js, hence they do not end up in similar situation
- riwsky 5y agoReact lets you build DOM with normal JavaScript loops and .map; solid requires its own For element. How do you define “does not fight against js”? Because the above feels likes solid fighting against js.
- benatkin 5y agoDon't forget about having to pass key to each element in React. The simplicity of using map() is an illusion. SolidJS splits it between <For> and <Index>. <For> is equivalent to passing the object as the key and <Index> is equivalent to passing the index as the key. https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_for https://www.solidjs.com/tutorial/flow_index https://www.solidjs.com/tutorial/flow_index
- KrishnaShripad 5y agoRegarding the example under "Reactivity, not lifecycle hooks": Does the <Counter /> component reference the same outer "count"? So is "count" here global or local to the component? In other words, what is the scope of "count"? Does it change based on where it is placed? If I create multiple <Counter /> components, do they all reference the same "count" or is it different for each component? Sorry this question might seem naive if you are experienced in SolidJS. I haven't given SolidJS a shot yet (though it is on my list of things to check out).
- manmal 5y agoI think the count variable is quasi an Rx subject, it has identity and any code using it is keeping a hard reference on it. It would probably be GC‘d if nobody referenced it. In my understanding, yes, multiple components would use the same instance of count.
- ryansolid 5y agoYeah this is correct. The trick to this is that the subscriptions happen in our JSX and hooks. And really is just a nested tree of `createEffects` if one ever re-evaluates or is disposed it releases its child computations. So while the lifecycle isn't tied to components it is still hierarchically structured. Ie.. places where logic can branch becomes the owning scope, like conditionals or loops. So Signals like count don't really matter where they live and will live as long as in scope or referenced, the rendering still largely defines how long things are around.
- deleted 5y ago[deleted]
- lpghatguy 5y agoNew JS frameworks always make for compelling hello world examples. Can you branch on state or use loops over data in Solid.js? The reason _why_ React has a virtual DOM is to enable more interesting relationships between your data and your presentation. Anyone can make a framework that makes the source code for an incrementing number look pretty! As an example of this point, check out the "Simple Todos" example for Solid.js[1]. In React, we render lists by using regular JavaScript idioms like loops, arrays, and array methods like map. However in Solid.js, much like traditional templating languages, we get a construct like <For> that reinvents a concept that's already in the language. I've been writing React and React-alike code for a long time. I think that fine-grained updates avoiding reconciliation are a good idea, especially for performance. At one point, I built a React-like library for Roblox and Lua whose most novel feature ended up being "Bindings"[2], which look sorta like Solid.js state containers. They create little hot-path data dependencies, but the bulk of your components still use normal React-like rendering. [1]: https://www.solidjs.com/examples/todos [2]: https://roblox.github.io/roact/advanced/bindings-and-refs/
- pier25 5y ago> we get a construct like <For> that reinvents a concept that's already in the language Isn't this optional? Can't Solid use regular JSX loops?
- latchkey 5y agohttps://www.solidjs.com/docs/latest/api#control-flow https://www.solidjs.com/docs/latest/api#control-flow For reactive control flow to be performant, we have to control how elements are created. For example, with lists, a simple map is inefficient as it always maps the entire array. This means helper functions.
- thatswrong0 5y agoThis feels like we're trading complexity here for complexity there, and it seems impossible to judge which way is actually "better". I use loops in React all the time but only have used `setInterval` in a component a handful of times..
- mdoms 5y agoWhat was wrong with the class component? It was very understandable and predictable.
- thatswrong0 5y agoClass components are fine for the simplest examples, but the moment they start increasing in complexity, they become a bit of a mess. Sharing functionality across multiple components becomes tricky with class components (with the only real option being HoCs / render props). You necessarily have to spread logic across different lifecycle methods. Hooks allow you to bundle code together by functionality, and consequently allow you to easily extract and share said functionality in a very composable way. This is my go to for visualizing the difference: https://i.imgur.com/e9K8vfz.gif https://i.imgur.com/e9K8vfz.gif
- ctvo 5y ago> Hooks allow you to bundle code together by functionality, and consequently allow you to easily extract and share said functionality in a very composable way. You’re using React. The mechanism that enables code reusability is through composing components. There’s nothing wrong with class components even for the most complex logic. The only downside is the community has moved on and mostly adopted hooks and functional components.
- thatswrong0 5y ago> The mechanism that enables code reusability is through composing components If you think that this: return ( <Apple> {({ apple }) => ( <Slicer slice={apple}> {({ sliced: slicedApple } => ( <DinnerPlane contents={slicedApple} /> ) } </Slicer> )} </Apple> ); is more desirable than this: const apple = useApple(); const slicedApple = useSlicer(apple); return <DinnerPlate contents={slicedApple} />; Then go for it I guess. Although you'd have to somehow ignore the fact that you'd end up with an even bigger mess if you want these intermediate functionality steps to interact with the parent component in a non-trivial way, .. Needless to say, I have written such render-prop and "renderless" components in the past, and I see very little upside compared to hooks.
- dheera 5y agoEvery time I see stuff like this componentDidMount() { I get driven away from React. It looks haphazard. Seriously? What about componentDidntMount() { componentWantedToMountButDidnt() { ... I'm used to clean naming conventions like void Component::on_mount() { .... }
- cosmotic 5y agoMaybe the name is trying to communicate it happens after the component mounted instead of just before
- yuchi 5y agoThe reason behind this different naming convention comes from the diversity in experiences of the original team. This will/did prefix instead of “on” comes from Mac OS X/iOS patterns and allows the name to convey the “when” of the listener. It is not “during component mounting” it is “after it did”.
- Jach 5y agoI guess this is just a limitation of JS the language showing itself. Other languages have actual aspect-oriented support where before/after/around methods are very clear name-wise and semantics-wise (if not always so clear without tooling support what happens if you come across a 'mount()' call). Maybe it's time for a new JS framework! /s
- vertex-four 5y ago
- fatih-erikli 5y ago"That’s a lot of code to write for an auto-incrementing counter" In reality, you will never need to write an auto-incrementing counter :) React gives you a mental framework, you draw a page based on the state in a declarative way. The clever abstraction you make, the less you write the code, so it's a little bit pointless to compare it with an auto-incrementing counter application, in reality has no use case at all.
- steve76 5y ago
- hsn915 5y agoThis feels a lot like knockout.js but with a jsx syntax.
- drewrv 5y agoKnockout.js was/is wonderful, I'm not sure why it never took off the way angular or react did. I do appreciate jsx though so I'll be looking into Solid.
- leonardopainter 5y agoThe problems with knockout were: very hacky syntax embedded into html. Sometimes you had to even use some kind of comment notation because there was no entry point into the html to add data properties or whatever it had. it was slow. the observables weren't variables you could use like plain JavaScript variables it has the same problem as React - state-based algorithms are not very good ways to solve problems (if (showDialog && !open && ranOnce). You have to keep creating more variables to represent more states instead of using normal programming language concepts, and then all of the observables ping around and become complicated.
- hsn915 5y agoAs far as I could tell, around that time (and even now to some extent) the amount of activity on StackOverflow is used to measure the popularity of a project. Angular had a "made by google" kind of logo on its website, indicating to many people that it's of high quality and worth adopting. But Angular was also so convoluted and had so many problems that so many people kept running into random problems all the time and had to ask questions about them on SO. This signals (incorrectly) that Angular is popular, driving more people to believe it's worthwhile to adopt it. Knockout had neither. It was not sponsored by a corporation. And it was so good that you hardly ever run into random problems. Ultimately it was eclipsed by React and Typescript because lack of type checking for the html templates means it's hard to scale it will to large projects.
- orenelbaum 5y agoIt kinda is, but it's more than just JSX. Solid was basically born out of Knockout and is in many ways a continuation of Knockout, but it has some relatively significant changes and additions to make this approach more viable, especially for large long standing projects. JSX is more of a quality of life thing, you don't even have to use it, Solid's runtime exists completely separately of JSX and can work great without it or even potentially be integrated with other templating languages.
- e-dant 5y agoI hate the whole javascript ecosystem to the core. Hey I just finished my progressive web app with these 10 cool react components I found on NPM which fit surprisingly well into our startup’s cloud-native Vue interface. I tried to put the code up on GitHub but it wouldn’t let me upload a 10gb repository (and that was without our proprietary fork of mysql :)
- e-dant 5y agoI am fundamentally skeptical of anything that needs a runtime for anything other than security and profiling. I am extra skeptical of any framework that needs 50mb memory baseline. I am triple skeptical of anything that uses brand-new packages and components like legos. *Iterations on React are welcome.*
- ajkjk 5y agoWell, you can be skeptical, and the enterprise front-end engineers are going to go right on using that stuff because it scales to large codebase.
- e-dant 5y agoYes, right up until said startups and enterprises 1. cannot afford the outrageous cloud expense or 2. Need to scale to low-power devices (such as wearables) and to customers who are security conscious
- ajkjk 5y agoDon't worry, they're doing fine. Anyway, we were talking about React, to which none of those objections apply.
- jorroll 5y agoLike the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary because of the way react was created, but strikes me as fundamentally flawed. Having used Solidjs for some pet projects, I've come to strongly prefer Solidjs over React. It's an evolution of react, so I've found my existing skills/knowledge transfers. This being said, Solidjs is brand new and the ecosystem is minuscule compared to React. For this reason, I plan to continue using React for the foreseeable future. One of the biggest weaknesses of Solidjs is the lack of a "nextjs" like framework. It appears work is being done in the solid-start[1] repo, but it looks like it's still years away from being fleshed out. I want Solidjs to succeed, but I'm not interested in being an early adopter. [1]: https://github.com/solidjs/solid-start
- aidenn0 5y ago> Like the author of this post, I appreciate Solid's API because component's only render (i.e. run) once by default and then you define which sections of the component should re-render on changes by using "signals" provided by the library (e.g. `createSignal()` and `createEffect()`). In react, the entire component re-renders on every change and you need to specify which code should _not_ re-run. This was necessary because of the way react was created, but strikes me as fundamentally flawed. I don't particularly like React, but this strikes me as the one thing it got right; the only "always correct" thing to do is to rebuild the VDOM on any change, so that's the default. Then you can be more selective about which parts as performance dictates.
- tobyhinloopen 5y agoI always wonder why all JavaScript client-side frameworks have such distinct design. No other dev environment for building GUIs has react-like components. What’s so special about the web that we keep creating frustrating frontend frameworks for?
- gman83 5y agoFlutter, Jetpack Compose, and SwiftUI all have React-like components.
- pevey 5y agoI personally love the front end frameworks, and I don’t find them frustrating at all. Knockout was a workhorse until angular came along. And then vuejs. And now I use sveltekit for pretty much any web app. The frameworks are popular because you can build things incredibly quickly once you know the ins and outs of your framework of choice. The component-style design, the endpoint design, so much is just driven by the needs of web-based development and the framework creator’s preferred way of abstracting away some of the challenges.
- rk06 5y agoBecause there are a lot many js devs than others. Hence js ecosystem is significantly larger.
- Scarblac 5y agoThe browser was intended to render documents, not applications. In particular, HTML has a tree structure, which means that things that are semantically related on the page and update together are often miles away from each other in the tree. And the page in the browser is part HTML, part CSS, part Javascript. Frameworks try to let the developer work in JS only and generate the rest. And finally, much of the application's state is often kept in a backend, and access to it a asynchronous. I think that's why Web development is so distinct from other UIs.
- leonardopainter 5y agoOne reason is probably that creating UIs programmatically was historically very cumbersome in JavaScript due to various issues that are no longer relevant. That means everything had to be HTML-based hybrids of some sort.
- llamataboot 5y agoHonestly my hope (and I admit as a full-stack but leaning back-end developer to be biased against JS) is that the future is in things like turbo-stream, stimulus reflex, phoenix liveview etc - or in things like all_futures (essentially an ActiveRecord wrapper around kredis) - that we move towards building reactive-apps by firing off events from the back-end and figuring out how to subscribe to them on the front-end the amount of confusing boilerplate I've seen to keep updated and maintained when a JS framework is loading front-end state by making API requests against a backend and then trying to figure out how to keep those in sync when we could just be firing off SSR HTML over the wire and/or very thin events that FE components can subscribe to or emit for literally no gain in functionality is beyond me even better, just add reactive sprinkles over what you need reactive and do the rest with standard MVC/REST patterns, if most of what you are using react for is glorified forms, you don't need react for that! user your reactive sprinkles of notification toasts, and chat channels...
- rezonant 5y agoWhat about apps that have no backend? What about apps that should work both online and offline?
- lawrencechen 5y ago^ What about Figma? Photoshop? Not everything is only a CRUD app.
- mst 5y agoThose are very different applications and the trade-offs involved are completely different. In the -common- case OP seems to me to have a valid point.
- rezonant 5y agoFor forms-over-data business applications, sure it's fine. It's tradeoffs around the system use cases, potential/realized functionality, and team. But I think that serving to public users with server-driven MVC for an application that goes beyond a pure content app has immediate and obvious limits in terms of what can practically done, and the more you try to overcome those limits the more you simply rebuild what is already available in the SPA side of things. It's also inherently monolithic, meaning that if you want or need to support a mobile/native app for your public-facing app, you'll now need to develop a new "interface" (an API), when you should have already done that to enable the web app in the first place. Is it really worth skipping API/UI separation on day 1 when you know it's going to be needed on week 2? You might say, it's fine, we're going to just make API calls for the Javascript, but then you've got an inconsistent availability of the functionality, and the second you hand that to another team to consume you will have wished you had simply built out all of the needed functionality directly in the API anyway.
- namuorg 5y agoFor anyone who wants a thorough understanding of how to think about React hooks in the context of things like setInterval, Dan Abramov wrote a great piece breaking it down in detail several years ago: https://overreacted.io/making-setinterval-declarative-with-react-hooks/ https://overreacted.io/making-setinterval-declarative-with-r... This post helped hooks "click" for me, and once it did, I've absolutely loved them and now thoroughly enjoy writing custom hooks that greatly simplify my code.
- atom_arranger 5y agoOne of the most compelling things about Solid.js is that it integrates some of React's most important (IMO, probably aside from the central idea of UI as a function of state) ideas for writing applications, Suspense, ErrorBoundary, useTransition.
- valtism 5y agoI've used React for ~3 years, primarily with function components and hooks. I think that hooks were a wonderful addition and I think the framework has made smart choices with checking object equality to decided if components re-render. That said, I think that easily the most difficult aspects of react revolve around how re-renders are triggered. Maintaining referential equality to stop unnecessary renders gets tricky when you are passing functions or objects. Suddenly you need to be using `useMemo` and `useCallback` and passing dependency lists that all have to be primitive values unless you want to memoize them as well. It can become such a headache that the official line around it mostly seems to be "make the render fast, don't worry about unnecessary re-renders" – good advice, until you hit a use-case where you need to worry. Solid takes these problems and just vanishes them. UI state knows what its dependencies are automatically and only updates when they change – even in a sub-component level! To be fair, I've never used Solid in anger, and moving to it would be a big ask when there is such a good ecosystem built up around react. That said it is easily one of the most exciting projects on my radar, and the developer Ryan Carniato seems extremely knowledgeable in the area.
- stocknoob 5y agoFor the other Americans, “used xyz in anger” means “used xyz in production”. https://english.stackexchange.com/questions/30939/is-used-in-anger-a-britishism-for-something https://english.stackexchange.com/questions/30939/is-used-in...
- lgvld 5y agoThank you! ;-)
- LAC-Tech 5y agoWeird. I'm not British by I say "used xyz in anger" because I read lots of other programmers saying it. Had no idea it was regional, thought it was hacker lingo like "grok".
- madeofpalk 5y agoAustralian living in England as a dev for 5 years. Never heard of "used in anger" in any context. Weird.
- TekMol 5y agoWhat feels like complete insanity when it comes to React is that it needs compilation to work: render() { return <div>The count is: {this.state.count}</div>; } This is not Javascript and it will need to be compiled into Javascript before it gets executed. But you can do the same in Javascript: render() { return `<div>The count is: ${this.state.count}</div>`; } Using regular Javascript makes my life a thousand times easier than having to go through a compiler to make things work in the browser.
- orenelbaum 5y agoThis is another area where Solid has an advantage over React. With React you could use Hyperscript functions so the above JSX would be React.createElement('div', null, `The count is: {this.state.count}`). With Solid you get the choice, you could use JSX, Hyperscript functions or template literals like in your example. Solid does recommend using JSX because there are some tradeoffs to using template literals without compilation, but it still maintains almost all of its qualities AFAIK and in the big framework benchmark Solid with template literals is the fastest template literals implementation. With Solid you don't even have to use any templating languages, you can take care of rendering yourself using the tools that the framework gives you. Solid at its core is more of a capable state management library similar to MobX but designed to be used as the only reactivity engine unlike MobX which is usually used on top of React.
- leonardopainter 5y agoUsing template literals to represent html is a security issue. If the state comes from the user, they can add script tags into the html. People try to solve this with tagged templates, but then if you forget the tag, you have a security issue again. Lit checks for this, but the fact that it has to check means it is less secure than not using tagged templates. There are libraries on github for creating sql using tagged templates which have the same security issue. The problem is that if your function works with both tagged templates and plain strings, when you forget to add the tag, you will never know.
- 5y ago
- aryehof 5y agoAs with any new JS framework technology, it will feel great until its flaws, warts, deficiencies and limitations are inevitably discovered as complexity rises, and which are then addressed in the next JS framework.
- lawrencechen 5y agoThe author of Solid.js (Ryan Carniato) also does weekly livestreams about a range of JavaScript topics: https://www.youtube.com/c/RyanCarniato9 https://www.youtube.com/c/RyanCarniato9
- unfocussed_mike 5y ago> That’s a lot of code to write for an auto-incrementing counter. Is it though? I mean I happily write more code for a single-page Vue component for something like this. Terseness is not always a virtue.
- orra 5y ago> Terseness is not always a virtue. This is a subjective thing, right? Personally, I hate boilerplate: either it's a distraction because it's boring and superfluous, or worse it's long and it's wrong. Regardless, it adds to the cognitive load when maintaining code.
- unfocussed_mike 5y agoYeah, definitely, hence the "not always" in this case. There are several terse syntaxes I really like. I'm just not convinced it's a virtue in this context.
- strangeattractr 5y agoThe vue code for this is pretty terse anyway to be honest. A single variable in data, a call to setInterval in the created hook and a few lines of html with template formatting. It's extremely clear what's going on too.
- unfocussed_mike 5y agoI agree. I think the single-page .vue model is also really amenable to whitespace and consistent formatting.
- sprobertson 5y agoThis looks a lot like my current favorite state framework (which yes is done by Facebook people), Recoil - https://recoiljs.org/ https://recoiljs.org/ Your naming however reminds me of the RxJS and general reactive programming paradigm I've always pined after... some combination of the two would be my UI state management holy grail.
- deckard1 5y agoMany devs have succumbed to the siren song of event sourcing. And many code bases have sank on those rocky shores.
- masterofmisc 5y agoSo, its React with the sharp edges smoothed away. Interesting. I am not a web developer, so forgive me if this is a stupid question, but can someone tell me, if you decided to use Solid.js as opposed to React, can you still make use of all the 3rd party React UI frameworks out there? Is it compatible with React in that sense?
- jorroll 5y agoUnfortunately, you cannot use React code inside Solidjs[1] so you cannot make use of the huge ecosystem of react UI components/libraries. It isn't compatible in that sense. However, there is an "official" option[2] for including Solidjs code inside React. [1]: https://www.solidjs.com/guides/faq#is-there-react-compat%2C-or-some-way-to-use-my-react-libraries-in-solid%3F [2]: https://github.com/solidjs/react-solid-state
- masterofmisc 5y agoAhh right. I see. Thanks for the info and the link.
- parentheses 5y agoThis article hits on something I've felt for a long time. The idea that "hooks are superior" to me is ridiculous. If a linter is required to tell me when I'm writing a bug that is not immediately obvious, that is a failing in the framework to round those edges. Lints are not rounded edges! Solid is nice and _seems_ to fix the issues with hooks, but as another comment mentioned, the challenge is with building at scale. It's unclear to me how this scales and where the sharp edges are. React IMO trades off performance in exchange for ergonomics. These ergonomics bear fruit early on, but you start dealing with this debt very quickly. As "nice" as Redux is, I shouldn't need it so early. React is designed in a way that results in pretty terrible performance. I once wrote a React app, and discovered perf issues 2 weeks in. Any UI framework I used in the past would have scaled beyond this point without having to have the data layer rewritten. Frameworks of the past also had what seemed like way less "magic". I totally accept that it's seriously nice to write, but how many trees has React alone burnt?
- ipnon 5y agoReact would work well as a compiled to metal language. Instead we end up with React on Typescript on ES6 on ES5 on the browser that still only has one language targetable. We're shackled to a rocketship in motion desperately monkey patching the engines.
- mwcampbell 5y agoWe can at least eliminate ES5 now that IE is dead.
- oaxacaoaxaca 5y agoI have the same complaint about hooks. Most people seem to ignore that tidbit, but to me it's really frustrating. Plus I recently hit more hook issues when putting a setInterval inside a useEffect. There's no way to do a normal didMount/willUnmount workflow without other hacks (i.e. useRef) just to set up a simple timer. Maddening! Edit: after writing this I went and read the article. Same scenario I was bitching about lol
- 5y ago
- deweywsu 5y ago
- alephnan 5y agoThis is the same code in Svelte.js # Counter.svelte <script> let count= 0 setInterval(() => { count += 1 }, 1000) </script> <div>The count is: {count}</div>
- ryansolid 5y agoWhat does a reusable (ie import from another file) `useAutoCounter` look like in Svelte?
- alskdjflaskjdhf 5y agoProbably the equivalent would be a custom store, something like this: <script> import { writable } from "svelte/store"; function autoCounter(interval, initialValue = 0) { let { subscribe, update } = writable(initialValue); setInterval(() => update((n) => n + 1), interval); return { subscribe } } let counter = autoCounter(1000); </script> <div>The count is: {$counter}</div>
- ryansolid 5y agoYep. Looks sort of like the Solid example in the article. It's basically my auto-response to Svelte syntax. Once you do anything in Svelte it is more or less the same thing. Just different priorities. In Solid you can take that code as is in the component and hoist it out to a function above and presto.. store. It's all the same thing everywhere. Same patterns, same usage, same building blocks. No new APIs, no new syntax. It is nice when first learning not to worry about Svelte Stores and use the convenient syntax. It is also nice to learn something once and use it everywhere.
- brendan-csel 5y agoWe've used React with Mobx in commercial apps for 5+ years now. React has been good for us BUT Solid is so much cleaner (and leaner). Porting most React code to Solid is pretty easy - mostly involves deleting things that are no longer required (useCallback, useRef, etc) and moving prop access into the JSX to enable just those specific attributes to be updated when state changes. It has come to the point where I really begrudge going back to working in our React code. Unfortunately those apps will still be around for a long time - but we won't be using React for green-fields projects.
- mst 5y agoAs somebody who's quite enjoyed mobx I would encourage you to write up your experiences. I would hope that while -me- reading any such blog post is almost certainly going to be irrelevant, it might pay off enough in recruiting/marketing/pure nerdery to be worth the effort to write it up.
- andrewstuart 5y agoI tried several React alternatives. At this stage, size of community is a really important factor, overriding many other factors. It's just incredibly important for there to be tools support, questions answered on stack overflow and a community of people developing related software. At this stage there's only really VueJS, Angular and maybe one or two others with community large enough to justify changing.
- rglover 5y agoJust started back in October, but you can talk to me directly and get questions answered pretty quick: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
- fabiospampinato 5y agoI've spent the past month kind of rewriting parts of Solid in an attempt to better understand it, and coming from React the way Solid works is just so much more beautiful, it feels liberating. There's no rules of hooks, no dependencies arrays, no stale closures, no wildly different resulting performance depending on where exactly you put your components boundaries, no VDOM at all, no props diffing, when I change the state corresponding to an attribute or property that just gets updated immediately, the way deep DOM nodes structures are created is sooo much more efficient... it's amazing!
- andix 5y agoDid anybody use Observable Hooks yet? https://observable-hooks.js.org/ https://observable-hooks.js.org/ This seems to be quite a good way to compute and apply complex state to a component. In my opinion better than useReducer(). But to be honest, for most components useState() and useEffect() are totally enough. And if you do something wrong like in the counter example, you see it right away.
- alephnan 5y agoAs part of my annual routine, I'm exploring the "latest and greatest" JavaScript UI library. Solid.js's performance seemed compelling. 15 minutes into documentation and this is what I encountered. Can you guess which one of the ChildComponent* updates when the text input on the parent component is updated, and the props passed to the child? export default function ParentComponent() { const [value, setValue] = createSignal(""); return ( <div> <ChildComponent value={value()} /> <input type="text" oninput={(e) => setValue(e.currentTarget.value)} /> </div> ); } const ChildComponent1 = ({ props }) => <div>{props}</div>; const ChildComponent2 = (props) => { const value = props.value || "default"; return <div>{value}</div>; }; const ChildComponent3 = (props) => { return <div>{props.value || "default"}</div>; }; const ChildComponent4 = (props) => { const value = () => props.value || "default"; return <div>{value()}</div>; }; const ChildComponent5 = (props) => { const value = createMemo(() => props.value || "default"); return <div>{value()}</div>; }; const ChildComponent6 = (props) => { props = mergeProps({ value: "default" }, props); return <div>{props.value}</div>; }; const ChildComponent7 = (props) => { const { value: valueProp } = props; const value = createMemo(() => valueProp || "default"); return <div>{value()}</div>; }; const ChildComponent8 = (props) => { const valueProp = props.value; const value = createMemo(() => valueProp || "default"); return <div>{value()}</div>; }; The answer is 3, 4, 5, 6. My takeaway is this: there are multiple ways of doing it right, but also a handful of gotchas. The only way to be safe is to keep the mental model of these partitions while you develop, test, debug, and code review. As a code reviewer, you can easily accept the wrong code. For now, I remain skeptical of Solid.js as solving the complexity woes of Reactive programming. I'm not sure React.js is better.
- ryansolid 5y agoOr Vue either to be fair. Similar rules in the Vue's setup function. It's how reactivity works in JavaScript. Basically don't destructure or access values out of of primitives or JSX. That's basically the gotcha. Unfortunately it's the price you pay for portability thus far. You can build your own language around this like Svelte but then composability is limited (need to rely on other mechanisms). You can make the updates coarser grained like React but then you need a different mechanism(like VDOM diffing) to apply updates granularly. I imagine this situation improves in the future but we haven't gotten there yet.
- fuzzy2 5y agoSlightly OT: I’m always amused coming to discussions like this one, where people are (basically) complaining about the Virtual DOM and its implications. It’s bad for performance at scale, updates aren’t minimal. And other stuff: SFC are hard to wrap your head around, I don’t want to write explicitly reactive code and so on. Some framework solves this by looking (somewhat) like React but in the end doing something entirely different. May I interest you in Angular? It certainly isn’t cool and I really do hate it. But especially since the AoT compiler has been implemented, performance is quite good. There’s templates, which some folks seem to love. Angular keeps in-memory references to all dynamic elements in a template so they can be updated with high efficiency. It has class components. It has a lifecycle method that is called OnInit. So maybe give it a whirl.
- awr 5y agoI've been using Angular in production for 5+ years. There was a year where things were confusing, state updating all over the place, and general frustration. But once I grokked pure components, and embraced "data down, actions up", it all clicked and just made sense [0]. I find React obtuse in comparison. Angular front-end, Nestjs backend has fast become my stack of choice. It greatly minimises context switching by having such similar paradigms across frontend and backend. [0] - blog series I wrote detailing Angular best practices that I learnt along the way: https://link.medium.com/ncYgWgnK2nb https://link.medium.com/ncYgWgnK2nb
- ramoz 5y agoThe whole "I hate angular" is a bit old at this point. The latest versions are really quite simple/powerful. We act like it's still 2015 and we're jumping from angularjs 1.x to React. The jump was nice, yet turns out production-grade engineering in React was not so nice.
- fuzzy2 5y agoI don’t like the separation between template and code, I don’t like the developer experience (slow and often malfunctioning VS Code extensions and slow builds, bad in-browser debug helpers), I don’t like how creating “ad-hoc” components is basically impossible. I think Zone.js is insane. I know Angular very well. That’s why I’m confident I can create high-performance applications using Angular. I firmly believe Angular has far too many pitfalls for inexperienced developers. So yeah, I hate Angular.
- egeozcan 5y agoI find Solid.js a "better" React as well. In a new project that needs to be used by a lot of team-members, however, I still chose React. Why? Because of the ecosystem! Do I need accessible, headless components? Use React-aria from Adobe! Do I need state management? There are many established ones, I just need to follow their best practices. Everything supports React, every hire speaks React, and it works, not like "just works", but "... works" and, disappointing to the engineer inside me, this is not something I can trade in big projects.
- pictur 5y agojavascript ecosystem is truly a shithole. I say this independently of the article.
- deleted 5y ago[deleted]
- activitypea 5y agoIsn't this just the Vue composition API dressed up to look like React? I haven't done frontend in a minute, so apologies if this is ignorant.
- ryansolid 5y agoMostly except there is no VDOM, the reactivity applies right down to the DOM binding. And it predates Hooks and Vue's Composition API.
- kkarpkkarp 5y agoand the same in Svelte: https://svelte.dev/repl/767f2d2fefc34bb6ae0b54b5aec5e947?version=3.46.4 https://svelte.dev/repl/767f2d2fefc34bb6ae0b54b5aec5e947?ver...
- progx 5y agoAs a svelte developer i could really not understand the problem of TypeOfNaN.
- solididiot 5y ago<cynic>Yeah React is already so last year.</cynic>
- samrocksc 5y agoIt's cool, I like this methodology a lot because it can piece together functionally really well.
- leonardopainter 5y agoThis article points out how ridiculous React is. This is just a simple timer, yet there are so many things you can get wrong. This article doesn't seem to even clear the interval so it runs forever. Solid solves some problems, but I don't know why everything has to be reactive. I have never understood it, I just noticed that from knockoutjs onwards, every front-end framework was based on automatically updating views based on state. I create a library at github.com/thebinarysearchtree/artwork. To be honest, I don't know if it is going to work or not. It is just javascript with no reactivity. When I rewrote a fairly typical large application that you would find at most corporations (not a giant tech company application), every component ended up being about 50% of the code of react, with excellent performance. The problem I have with it that makes me uneasy is that ultimately you are creating content in JavaScript, which I don't think is ideal. The lack of HTML structure isn't a problem as devtools and so on show that. The problem is things like: const label = label('Email:'); I want the HTMLLabelElement variable to be called label... but that is the name of the function that creates it. Then there is the setText example on the github page... I just didn't want to write label.innerText.. h3.innerText... etc etc .innerText. Variadic arguments are not ideal though, and when you have lots of elements with lots of attributes, eg: const content = div({ className: 'content', title: 'whatever', innerText: 'something' }); it doesn't look like art, which is the point of the library. It is just hard to create content with JavaScript and not really the tool for the job. If I could solve that, I would be very happy with the library. It kind of needs JSX, but then it is back to having the JSX variable auto-update the state and well.. I guess that is why knockout and so on do it. Maybe I could do just plain HTML without state. So yeah, I don't know. I mean, it does end up being half the code. If you look at the todo example on my github page, and compare it to the one on React's homepage or solid's homepage, it is literally half the amount of code with native hand-written performance. This continues on to real-world components, it is just that.. I am a perfectionist I guess, and I want it to be elegant always. anyway.. I haven't even finished writing the documentation.
- torginus 5y agoCan anyone explain the point of the virtual DOM and why it’s not a source of huge performance issues? What I mean as soon as you retain a reference to a DOM element, it’s lifetime becomes managed by the JavaScript gc - let’s say you build a paginated gallery app in pure HTML and an spa - in the first case, the browser knows that as soon as you navigate away from the page, all those image thumbnails are free real estate, at the latter case it first needs to wait for the spa to release references to the underlying html objects, then the gc needs to run, at which point it can get rid of it.
- Kuinox 5y agohttps://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead It is a huge performance issue. I tried to do a pokedex in react, you have to use a virtual list, because react/virtual dom is too slow, doing any operation on a plain list with 1k element, like filtering lead to multiples seconds freeze. This also lead to a lot of issues, like not being able to ctrl+f text being out of screen in a virtual list.
- mlajtos 5y agoI also did sort-of Pokedex a long time ago [0], but haven't seen any performance issues. No virtualization whatsoever. Code [1] is rather simple. [0]: https://mlajtos.github.io/lb-pokedex/build/ https://mlajtos.github.io/lb-pokedex/build/ [1]: https://github.com/mlajtos/lb-pokedex https://github.com/mlajtos/lb-pokedex
- Kuinox 5y agoI ran a profiling tool. I searched "zz" then deleted these. Deleting it caused a 120ms UI freeze (and I notice it :p): Profiling report: https://share.firefox.dev/3C3OhIq https://share.firefox.dev/3C3OhIq Given I had slightly more entries (a hundred more) and that I had way more node per entry, it led me with way worse performance. Instead of a plain list I have a little summary card per pokemon (which is why I have more node per entry). The naive implementation in Vue run flawlessly(sadly no preview): https://github.com/Kuinox/kuinox_pokedex/ https://github.com/Kuinox/kuinox_pokedex/ Note that the react implementation do weird thing because I tried to get around the issue without success.
- simon83 5y agoI've been using React since around 2016 and when Hooks were introduced I played around with it but didn't like it at all exactly because of the reasons mentioned in this article. Sure it reduced quite a bit of boilerplate code that came with class based components and enabled better code re-usability outside of class inheritance or mixins but the disadvantages were too big for me personally to really consider using Hooks in a "greenfield" setting. In my current project I'm using Vue with Composition API which gave me the exact same "aha" moment the author of this article had with SolidJS. Vue + Composition API is way more similar to SolidJS in principle than React + Hooks.
- mst 5y agoPure function components in React with MobX for state management rather than the hooks system has worked out quite well for me. I do, however, keep finding myself wondering about jumping to Vue and VueX instead. Ask me in five years, I guess.
- _ezrr 5y agoThis reminds me a lot of Clojurescript's Reagent https://reagent-project.github.io/ https://reagent-project.github.io/ (link also has a counter example) I've tried using bare React in the past (after using Clojurescript), because I wanted my project to be more approachable for outsiders. But I couldn't really handle the (to me, and the author) unnecessary complexity that's added. I would even say the Reagent version is even simpler than the Solid.js version, because you're using Clojure's Atom API rather than creating read / write functions. For the adventurous hearted I'd definitely recommend giving it a try! Edit: Someone posted a Reagent counter example on codepen a few days ago: https://codepen.io/Prestance/pen/PoOdZQw https://codepen.io/Prestance/pen/PoOdZQw
- dhucerbin 5y agoImagine if we could have runtime characteristics of solid, dsl of hiccup and simple semantics of clojure atoms and refs!
- torginus 5y agoI wonder if there's an immediate mode framework for Js, in the vein of IMGUI for C. If people are wondering what that is, it's basically this: function renderGui() { label('hello') if(button('click me')) { console.log('I have been clicked') } }
- antihero 5y agoThis seems like a huge step back from declarative UIs, any reason why you would say it’s preferable?
- torginus 5y agoPerformance, for one. This method can easily avoid allocating an object for every div (since it turns into a method call, not something that needs to return an object), compared to React's render() method. Another scenario outlined in the article of rendering a row of buttons, each with it's own click handler, that needs to allocate a lambda for each button every render. Alternatively, using map() and filter() also allocates lambdas and temporary arrays. All this can be replaced with a simple for loop like: for (item of items) { if(!item.isClickable) continue; if(button(item.name)){ console.log(item.name) } } Compare this to the React-ish pseudocode: items.filter(item=>item.isClickable).map(item=><button onClick={()=>console.log(item.name)} >{item.name}</button>) Readibility-wise, it's sort of an acquired taste, I'm not saying it looks better than JSX (but it's a hell of a lot readable than React.createElement, so some syntactic sugar might be put on top of it).
- mst 5y agoI suspect that the nature of the DOM means that being able to do that in the first place would actually require a virtual DOM w/diffing assuming you're targeting browsers. However that's probably obvious, so: Assuming you're considering greenfield / blue sky thinking here, it's worth noting that v8 has had so much money and engineering hours sunk into it that the react-ish pseudocode probably doesn't make nearly as many allocations as a naive reading of the code might expect. (a good friend of mine was very surprised to discover that v8's JIT is good enough that naive javascript code was basically competitive with FFI-ing out to C++ just because the node FFI layer introduced sufficient overhead that the JIT managed to catch up ... I am not a compiler wonk so please don't take this as a remotely expert pronouncement but "it is, in fact, quite difficult to overestimate v8 these days" seems to be a solid heuristic)
- iamleppert 5y agoThis article perfectly captures the essence of why I no longer work in web development. Never again!
- christophilus 5y agoOut of curiosity, what do you do now?
- devmunchies 5y agoGoogle search says senior eng leadership.
- prohobo 5y agoI'm proficient with React hooks and functional components, but I will never bullshit anyone by pretending that they make any kind of intuitive sense. Classes may have been more "code" but were clear to understand. I don't dispute that functional components are probably more efficient though. Anyways, I've never had this problem with React hooks. I've been building complex dynamic UIs for years, and maybe I've grown to get around these kinds of things, but it seems like Solid.js is solving a niche problem at the cost of making hooks even less understandable?
- imtringued 5y agoThey literally don't. For some reason the developers think that storing state in hidden global variables (linked list indexed by hook call order) is a good idea. You know, they could have at least defined useReducer inside the class. Of course that would sort of break the pretentious ability to define hooks as global functions that access component state. After all, you would have to pass the current component as the first parameter, imagine the horror!
- schwartzworld 5y agoI love solidjs, but the similarities to React are the hardest part for me. The semantics are so similar, but the mechanics are the polar opposite. In react, everything is a function and all your code runs on every render unless you specifically tell it not to. This really encourages a certain style of writing code and provides a lot of guarantees about safety and scope. Solid is literally the polar opposite, your code runs once, and only the parts that you specifically make reactive are reactive. This allows for much finer-grained updates and performance. The mental models are so different because they are optimized for different things. React allows for developer sanity (cue all the people who worked on one lousy react app telling me that it doesn't) and Solid optimizes for speed and simplicity. Solid is very well designed though. One of the features I loved is that Ryan specifically built it to work as possible to vanilla html/js so you can copy old stack overflow answers.
- deepstack 5y agoand Solid JS runs very close native JS speed! Any one making a Reactive Native Connector for solidjs? Vue Native was already using that connector. with that, Solid JS will be ultimate isomorphic lib to use.
- christophilus 5y agoI had the same problem: spending time trying to figure out why something didn’t paint. You also can’t use restructuring the way you might expect. It’s a cool library, though. I think you just need to keep a different set of nuances in mind when using it.
- schwartzworld 5y agoAgreed, and typescript is essential. I'm still new enough to the patterns used in solid that I can't always tell whether a prop is a value or a signal, but with TS it's trivial.
- MaxMoney 5y ago
- lbj 5y agoAlmost every criticism of React that I've read, goes away when you drive it from Clojurescript. If you haven't had the pleasure I suggest you take it out for a spin. Example of a full blown React component in Clojurescript: (defn counter [] (let [state (r/atom 0)] (fn [] [:div {:onClick #(swap! state inc)} "The count is: " @state])))
- imtringued 5y agoReminds me how vanilla hibernate is unusable but Grails'/Groovy's GORM (built on Hibernate) is absolutely fantastic.
- code_runner 5y agoI just dove back into react after a while in vue and deep in some backend systems. I love the new ergonomics (hooks, useEffect, redux tools) but I definitely hit the exact issue OP mentions almost immediately. I don’t feel that the solution react provides is too out there, but agree it could be better. The react ecosystem still makes it worth the one or two “could be betters” for me.
- bayesian_horse 5y agoYou may need to think about how you implement asynchronous side effects. Declaring them with useEffect quickly gets annoying. Look for things like thunks or saga. Or when not using Redux, at least think about using async functions. In general I want to keep async logic out of my components as much as possible. I also don't want the component rendering to drive the async logic.
- code_runner 5y agohave you had any success using the useReducer hook totally outside of redux? I feel like its bulky for certain operations but I still haven't found that "perfect" use-case for it yet that makes it click for me
- bayesian_horse 5y agoSo far not. But I can imagine things. For example imagine a Game of life component with two actions, "evolve" and "set_cell". Basically any time when it is awkward to have exactly one mutation function (setter) for a piece of state. Other examples are a minesweeper game. Basically any time it is too awkward to compose different mutations on top of a single setter. The other big benefit is that you can test the reducer without the component. And compared to redux, it still has a smaller footprint. So it doesn't have the dependencies, you don't need to setup a store etc.
- bayesian_horse 5y agoThe issue is more about not understanding how React works and how to use hooks. The setInterval example is easily solved. No, you can't just half-assedly guess your way to a correct solution. Also, composing asynchronous behavior with useEffect is also not a good idea. Don't abuse useEffect as an Event Handler (too much). Think about using Redux (+ thunks/saga) or something similar.
- continuational 5y agoHow is the setInterval cleared when Counter is no longer rendered? It seems like a leak.
- bgirard 5y agoIt's certainly a leak. That setInterval is going to be holding the closure context alive which will reference the component in many frameworks. The setInterval will also keep firing causing, wasting CPU and battery. It's hard to take any examples here seriously without showing proper cleanup that would pass code review.
- sanitycheck 5y agoGood to see other people spotted that, I noticed it immediately and had a "there's a bug! a bug!" alarm bell ringing in my head throughout the rest of the article. I may have some sort of setInterval related PTSD.
- StevePerkins 5y agoThe author lost me in the introduction. > "Ohhh, an OO pattern with a couple of one-liner lifecycle methods is just WAY too much code! Higher likelihood for errors and worse developer experience." ... > "So instead, I'm going to replace this with a functional pattern, that crams a couple of lifecycle functions into a closure, and is riddled with edge cases and common developer mistakes." This article perfectly crystalizes why my career has tracked toward the backend over the past decade. All of the virtual ink in this article, and honestly most of the complexity in the field overall... and it seems to really all just boil down to, "I think this looks cooler."
- nawgz 5y agoA factor of two reduction in LOC and an elimination of almost all boilerplate is justifiable in itself. I don't know where the author said "I think this looks cooler"
- thomascgalvin 5y agoUI development seems determined to repeat every mistake we've made on the backend over the past thirty years, while adamantly refusing to ask us about any of those mistakes.
- pier25 5y agoCare to elaborate? What mistakes are you referring to?
- nawgz 5y agoNone in particular, it's just a classic jibe from those who dislike UI frameworks because they don't use and thus don't understand them
- jakelazaroff 5y agoI don’t think there’s much overlap between the two, besides general programming best practices. In my experience, backend development is often simpler because you can move any state out of your own code into dedicated external components, like databases and queues. With frontend code, you have to manage state; there’s nowhere else for it to go.
- bstar77 5y agoThis is really interesting. I'm happy the author covered the effects side of things because this is where I've had some challenges with non-trivial React apps. Sometimes effects can be very complicated and result in React getting stuck in an infinite loop. Before you say it's because I'm "doing it wrong", Material UI's website had this problem for quite a long time. That issue required doing manual refreshes to not trigger the infinite loops (something you would only see in the debugger). This problem in reactivity is a issue in React that even the best devs can struggle with. My solution was simple... use useEffect less. Depend less on reactivity. The bottom line for me is that I feel like I can accomplish anything in React, but the devil is in the details. There are so many scenarios that I would need to vet with Solid.js, but if it works better at managing a complex app's reactivity, it could be very compelling.
- nateroling 5y agoAfter years of using Knockout and Angular/RxJS, I'm not at all convinced that adding Observables to React is going to lead anywhere interesting.
- prea 5y agoI worked in React for a few years, although not enough to ever feel like I was an expert. This article resonated with me because I also got off the bus because of React hooks. I've been using Lit.js for about a year now and something about it just clicks. I just wish it were more mainstream.
- frolicker 5y agoWait what's the problem here? Because you didn't like adding [count] as a dependency to setEffect(()=>{},[...count goes here...]) you wrote an entirely new framework?
- recursive 5y agoIt's not just that one case. Everything in react is like this. I find react code hard to reason about because this type of friction exists almost everywhere. Solid is what I always wished react was, but had a hard time articulating.
- notpachet 5y agoSips tea and happily keeps writing class components with Redux
- reactopinion 5y agoI prefer the very explicit first React example. While I'm not a web dev, on a larger project with a larger team, implicit stuff generally makes things harder to understand and more error-prone. I don't see the boilerplate as a negative, I see it as documentation.
- dimgl 5y agoI'm surprised to see so many negative opinions about React. Surely, I can't be the only one that truly likes React and finds myself being extremely productive and making impressive apps with it.
- rk06 5y agoHave you tried solid/vue? If so, consider adding your perspective of what react does better.
- dimgl 5y agoI haven't used Vue in a really long time. Last time I used it, Evan You had just shipped Vue 2.0. Using Vue was honestly a fantastic experience, and a great stepping stone to get off of Angular 1.x. I really enjoyed its approach to data binding and single file components where the styling, functional logic and templating was all contained in a single file. At the time the promise of React was very far-fetched: using JavaScript generate your HTML markup. I actually was really adamant to use React and held off on it for a long time. However, once I gave it a fair shot, I was blown away by how intuitive it felt to use. I think the mental models it champions really helped drive its adoption. While it was a pleasure to use, I was always wondering about other frameworks. But where React really locked me in was in its support. `create-react-app` was an incredible achievement, tbh. It made it so easy to start using React and have all of the bells and whistles out of the box without ejecting. And then, once you do eject, all you have to do is modify your Webpack configuration and you can get all of the additional stuff you want. The community also made incredible packages, like Downshift and Emotion, which further made React an attractive tool. Over the years the React team has kept innovating it. Hooks made it so much easier to just write functional components, which has always been a core tenet of React (admittedly, Solid.js was using hooks before React). More recently, React added the concept of SSR/hydration to its framework. Initially a lot of people made fun of it because it was like we went back to HTML generation on the server, but then developers realized that you get the best of both worlds: immediate markup from the server with the reactivity and snappiness of a single-page application. Because of SSR we now have innovative frameworks like Next.js and Remix. I know Vue 3/Nuxt.js exist now, and I know Solid.js exists now, but now that I've started using Remix I'm trapped in React land again (and honestly, couldn't care less). Remix is so freaking good and it's such a freaking improvement from when I did SSR in 2019 that it's hard to see myself using another framework. This is kind of a bad answer, but at least I can show you why I'm locked into React I haven't tried any other framework (I also genuinely enjoy using React). There are some things I don't enjoy about React. I don't enjoy how prevalent Redux is when developers think about global state. I also don't think contexts are a good enough solution (having a good reactive model would have definitely helped here). There are other things I don't like about React: I don't like how often it calls functions; it's extremely wasteful in large applications if you're not careful. And the semantics of `useEffect` are really murky for newcomers (and even sometimes for experienced developers). If there is something like a Remix equivalent for Solid.js I'll give Solid.js a shot. But right now I'm in love with Remix. Maybe I can use Remix with Solid.js? I'll take a look.
- c-smile 5y agoInstead of vDOM, solid.js uses <template> - real DOM elements + cloneNode(). And that's doubtful decision. Each live DOM element is about 100-200 bytes in memory. While in React (PReact, Mithril) this JSX expression: <div>a</div> is this: ["div",{},["a"]] 5 or so times less. In other words: needs to be tested on large DOM structures.
- infensus 5y agoThat's just a component template though. When you produce large DOM trees, you usually do so by rendering your components a lot of times, not by having a lot of different components
- darepublic 5y agoI'm used to react and hooks,and right now I can't do any better. Doesn't mean I like it. The solid example here seems to have a similar complexity and implicit knowledge as hooks just a slightly different syntax
- rglover 5y agoThere's light at the end of the tunnel. Don't fret, traveller: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.
- rglover 5y agoEscape the nightmare, embrace the zen, use Joystick: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.
- dhucerbin 5y agoGreat majority of my projects are data dashboards and I struggled with React for some time because of its top-down model - it can hinder performance really badly. If one of your points on scatterplot should be marked, you need to carefully pass this prop through few memoization layers, so any other points won't try to re-render. I've been on this quest for a long time, because I like React model. So I had fun with putting observables in my app (kefir and karet from calm-js and my own thing with xstream), I tried custom selectors with redux and all 'like-redux-but-simpler' libraries, I also tried recoil. These solutions can work and worked for my apps, but it felt like I was fighting against React. Solid was nice. It provided necessary tools to write interactive data visualisations with ease and in performant way. It has quirks but they are manageable - my team also learned and contributed to projects in Solid. First, the concept of "component functions" that are more like factories. It is not groundbreaking (reagent had this idea long ago) but is quirky. Thankfully, half hour with Solid playground and everybody can see what code is generated and how it works under the hood. It is really predictable but also tangible - you can play with just part of your app in playground if something is unclear. Second quirk is props object. I understand the trade-off but it trips users (me included) that you can't just treat it as regular object. Sadly, only solution for this is lint rule - yuck. But it is much simpler rule than hook rules - just don't destructure props. In the end, Solid is great tool for "web apps". Think about dashboards or diagram editors. Cheap components, fine grained reactivity, focused updates yield great performance results without jumping through hoops.
- Shorel 5y agoI don't know. I used Vue.js for my last development, and I see no need to trade Vue.js for something that's both more complex and has less performance.