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.
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.
Breathe in – breathe out. Breathe in – breathe out. Ever tired of breathing? You will be.
I've seen all my favorite activities turn sour. Pleasure turned into pain. Relief out of reach. Breathe in – breathe out.
The world is like this. Breathe in – breathe out. It does not go anywhere, it just breathes. Breathe in – breathe out. Until it breaks. Breathe in – breathe out. Find your peace.
It does not mix, and does not obstruct my eyesight. I can read while 'seeing' the events in the book. It does not pass through the eyes, and it is as detailed and sharp as my sense of reality - obviously. It just does not come through the same channel and that's easy to notice.
As a side note, it can be really odd to read something like: 'She saw two doors in the room. She took the one on the left wall.' And my flow is broken and I have to stop and reimagine the room, because I saw the two doors on the wall ahead - what is the author going on about? Maybe they should not be so exact about a tiny detail.
I had to once code a ‘wheel of fortune’ UI, that simply revealed trivia in random order. You had the perception of control: you could set a speed for the initial spin and see it gradually stop – as if it was adhering to physical laws – on an item that you haven't seen yet. The same item never came up twice. You always got to see all items on the first try. It was so easy to trick the mind into thinking you had control.
Edit: Sure, having automatic HTML escape for values is good. I work with JSX every day, and I can't really imagine having it all in one huge chunk and no code reuse. Also, what about conditional hide/show and lists?
VS Code will type check open files only. So this only works for tiny projects. And all that typing (overly verbose) seems a lot of pain compared to setting up TypeScript properly.
I have had success combining old jQuery based components with a Mithril based UI (Mithril is similar to Vue, but simpler). But this only worked because I defined clear boundaries between areas managed by Mithril and areas managed by jQuery. Nesting such areas was possible. It was possible to make them both notify the other when they were about to remove a nested area.
Deleting an element created by the other framework however is never a good idea. They can manage their own event handlers and metadata only themselves. Instead, you need to ask the other framework to detach itself. You can use jQuery's special events to detect elements about to be removed from the DOM [0]. Mithril lets you define an onremove lifecycle callback on any component. From there, it is cakewalk.
YC turns builders
nto formidable founders
And a little dirt next to founders.