Post

yeah this one pretty much proves the point ryan was trying to make you either make janky apps or put everything into web components choose between bad dx and bad ux with solid you dont have to choose

This is a false dichotomy that I don't think you intended to sound as sensational given your other responses below, re: nuance. I don't really want to keep going back and forth here though. I feel like the original intent of this thread has been misinterpreted (or miscommunicated or both).

1 repost0 likes

As @drk.wtf said, after over a decade of having my teams fumble with SPA architecture, D* has been refreshingly simple (in the Rich Hickey sense of the word) while still giving me the tools to build high-fidelity apps. I appreciate Solid2 (and use it on an app in prod!).

I wouldn't call anything built on top of a bundler like vite "simple" 😅 But I get it: if you want to do an SPA you don't really have a choice, you must ship the whole next page's code to the client, and that means you need a bundler that does chunking etc.

IMO it is in the best of current TS frameworks. I raved on release about the consolidation of the metaframework into the framework. My main complaint is abstraction complexity and onboarding. Solid2 feels like a framework targeted at people who are already experts in modern JS frameworks.

*caveat I have only built _one_ full Solid app to production grade and it also needed a sync engine (Zero) Love Zero, but admitting bias here that my experience is with complicated applications and this could be skill issue + types of problems I'm working on. YMMV.

I think this has less to do with the architecture and more to do with the documentation. I think the language is (or was, might be better now) obtuse for anyone not already versed in the challenges. And maybe that's correct given the target audience.