They are pretty close in mindset (how state works), but Svelte is more established, better polished, has better docs, with a larger community, and of course, great animation / transition support. Svelte 5 does not have dev tools at the time of this writing, just like Solid. SFC is great, Solid has no comparable offering. It also has robust error handling, better than Solid.
That said, Solid has a way better Tanstack Query implementation. (No idea why we still don't have a proper Svelte 5 version today.) It is reasonably close to React that you may feel it should be easy to switch – though that is deceptive. Most of the work is not in the templates but in how the state works, and for this reason it is easier to port Solid code to Svelte or Vue than to React. Developing in Solid is smoother, because it is not a custom template, but just TypeScript. Less concepts to learn, if you are well versed in React.
Both can be good choices for different use cases. And then sometimes React is the right choice.
Solid has a different take (from React) on how to tackle application state. I love this. It is refreshingly simple. (Look ma, no keys! Deep state! No reducer!)
Yet, it is unpolished. It commandeers not only the `use`, but also the `create` prefix for no apparent reason. (We understand it works differently from React, but still... this just adds friction when porting.)
The community is unhelpful. Questions go unanswered. The docs are lacking. Dev tools are alpha / unusable. Every update happens in sync, so you get odd errors that React devs are not familiar with. Some parts of the API must be avoided, but you have to learn this the hard way: Suspense (don't ever introduce this and you'll be fine), createUniqueId (not very unique, not configurable), SolidStart routing (occasionally very slow, no workaround, no support).
Expect rough edges. Not a good fit for all teams. For a small team of experienced devs it can be a great DX improvement though.
Firefox on mobile has the saved logins (passwords) hidden deep in the settings menu. Odd to see that option hidden so deep. Especially since Chrome just moved the option to the main menu.
As a designer I feel more than capable of designing anything you want and iterate on it until you are truly happy. (And as a web developer I can even build it for you, if it's a web app.) The reason my portfolio doesn't have anything I could show you as an example is mainly because it does not sell nowadays. It's not the thing the world wants – since too long. But maybe we can come to an agreement... You can reach out to me on hn (complicated symbol) csakegyhonlap.hu (never mind the home page, it's... not what you're after, and foreign). I have way too many years sunk into design to really stick to a particular style only. I am pragmatic – I do what I'm paid for. There were a few direction changes along my journey.
I played Minetest a lot with my kids too. We still have tons of those old maps from our co-op on various computers.
Now that they are playing other games, I still find that I occasionally log into Minetest servers just to look around at all the amazing builds.
In one of them I found a working MS Paint emulator (a wall with the icons and canvas on it), as well as a very impressive and huge ancient Greek temple.
Double Commander is a free cross platform open source file manager with two panels side by side. It is inspired by Total Commander and features some new ideas.[0]
Apart from design differences, the TIC-80 is free and open source. PICO-8 is not. This could mean that whatever you create in the PICO-8 will be playable only as long as the owner of the platform is interested. Whatever you create in the TIC-80 can continue to be playable even after the original developer loses interest in the project.
There is a healthy community around the TIC-80 that cares about the continuous development of the platform. There is an open atmosphere around it. Anyone can be a developer in the TIC-80. Students don't need to ask mom to buy a license for them. On the opposite, PICO-8 feels like a walled garden.
This was the main reason I chose to develop my tiny games in the TIC-80.
I wonder if there are aspects of this that would make it difficult or impossible to port to, say, the Esp32 microcontroller? An inexpensive and ubiquitous hardware implementation would make this perfect!
There's apparently a port floating around to run it on OpenDingux devices (little handheld gaming devices with MIPS CPUs), so it is at least fairly portable. If the OpenDingux port works- I haven't tested it yet- that's a good bet for a cheap platform that'll run it.
Of course a MIPS device is a lot more powerful than the ESP32.
They are pretty close in mindset (how state works), but Svelte is more established, better polished, has better docs, with a larger community, and of course, great animation / transition support. Svelte 5 does not have dev tools at the time of this writing, just like Solid. SFC is great, Solid has no comparable offering. It also has robust error handling, better than Solid.
That said, Solid has a way better Tanstack Query implementation. (No idea why we still don't have a proper Svelte 5 version today.) It is reasonably close to React that you may feel it should be easy to switch – though that is deceptive. Most of the work is not in the templates but in how the state works, and for this reason it is easier to port Solid code to Svelte or Vue than to React. Developing in Solid is smoother, because it is not a custom template, but just TypeScript. Less concepts to learn, if you are well versed in React.
Both can be good choices for different use cases. And then sometimes React is the right choice.