If you want to compare Solid to Vue, I think it is easier to just compare React to Vue. If you like React better, then you can compare React to Solid and see which you prefer. SolidJs is 90% similar to React in terms of DX, with only a coupler major differences.
Things the same as React in Solid: function-based components with hooks, JSX, overall "JS-first" (vs Vue which I'd describe as "HTML first")
Things different from React in Solid: "signals" instead of state (observer pattern), built-in components for rendering control flow (<Show />, <For />, etc), direct manipulation of the DOM. All these differences combine to the overall main difference, which is that React kinda revolves around an immutable re-render cycle where a function is re-run in its entirety to create a new vDOM representation each time, while Solid renders a component once then only selectively re-reruns parts of the component / mutates the DOM.
So I'd say pretty much the only similarity between Vue and Solid (contrasted with React) is the built-in components for control flow. Everything else is the same differences or similarities that Vue has with React.
I disagree, both Vue and SolidJS share the same underlying signal mechanism. Vue hides it a bit more, and has different default primitives, but they're both doing essentially the same thing under the hood. In both, you can think of a component as an entity that exists continuously for as long as it is mounted, and connects sources (i.e. signals) to outputs (i.e. HTML values).
React, on the other hand, is very much focused around the `UI = f(state)` paradigm, where the `f` (i.e. the component/render function) gets called afresh every time the state changes. You can avoid that somewhat via memoisation etc, but this is conceptually an optimisation rather than how the framework works.
The JSX vs SFC aspect is still significant, and SolidJS definitely tries to use some of the affordances that React developed initially. But the core idea in the framework is much closer to Vue than to React.
It isn't necessary. Solid has a similar custom renderer, with Pixi, three.js, terminal, etc... integrations. Solid is actually used a lot in embedded applications since it is low memory and performant. It powers Comcast's TV application applications like Peacock.
Both use signal-based reactivity, both are heavily optimised at compile-time to ensure only the parts of your app that need to well change at runtime.
Vue uses single-file components, SolidJS uses JSX. That has a surprisingly large influence on how you develop with the frameworks, because it's a lot easier to create new components if those components are just regular Javascript functions, as opposed to being new files with boilerplate. But the boilerplate also provides some standardisation which might be useful for larger teams.
Vue has a much larger ecosystem. Partly that's about pre-built components and utilities, but it's easy enough to build things yourself in both frameworks, and SolidJS in particular makes it very easy to incorporate vanilla JS libraries when necessary. However, if you've got a weird setup, it's more likely that someone in the Vue ecosystem has tried out that setup before and either documented it or raised all the necessary bug tickets to get it working.
Personally, I really like SolidJS - it's pretty small, it's very simple to understand once you've got your head around signals, and it scales up well from single interactive elements on a page to complicated applications. (Specifically: one project I work on at the moment is an Excel-esque application where SolidJS handles both the UI and the underlying reactivity of the application. I have only needed to think about performance in a couple of cases, the vast majority of the time, SolidJS can handle hundreds of thousands of cells without issues.)
That said, if you're working with newer developers or on a larger team, or if you're new to web development yourself, I'd probably recommend Vue just because there's so many more resources out there for it.
That's true, but it's not usually recommended for most cases. You lose out on a number of optimisations, and I don't believe it'll be directly supported for vapor mode when that comes, although it looks like there's a plugin that will get them to play nicer with each other.
If you want JSX and signals, I suspect you'll get more out of just using SolidJS, as that framework is focused on working well with JSX directly.
Yeah, I've heard a few people say that. Tbh, I think that (plus a few philosophical approaches) is probably the biggest difference between the two frameworks at this point. Both use signals, both use an optimising template compiler, but in one you write the templates as JSX and in the other you write the templates as SFCs.
Vue is my framework of choice but currently working on a project with SolidJS. It's fine. To me it feels like React with the most objectionable parts removed. I haven't found too many painful bits, though there are some odd gotchas about destrecturing params losing reactivity.
Agreed, this is a thinly-veiled ad for sliplane, even if I generally agree with the sentiment regarding serverless (though wouldn't go as far as calling it a scam, it has it's usecases, just not for me)
If you have a website, you want to collect statistical data on which browsers are accessing your website and test for the best experiences on the top browsers.
that sounds nice, but history has shown thats never what happens.
what REALLY happens is the most popular browser and even version is determined, and anything thats not that doesn't get tested, and eventually breaks. its the pinnacle of lazy programming. "lets use telemetry so that we can point to data that allows us to make software thats as brittle as possible".
There are limited resources in the world. The bulk of the resources should go to the bulk of the users. It’s a feature that rare configurations are less tested
Well, when we say GitHub, we are talking about thousands of services. I don’t think we can pinpoint the overall operational failures to programming language choice. In my experience, these kind of issues are mostly caused by poor organizational architecture + poor project management. In GitHub’s case, I’m also confident to say the choice of infrastructure plays a much bigger role than Ruby.
If you have some customers that rely on GitHub-specific features and some others that rely on GitLab-specific features then you will have to support both set of APIs.
