When will mithril.js get the hype it deserves, I'm a sucker for simple tiny libraries with no dependencies and no build steps that are mature as well (6 years). I guess it doesn't have a flashy community with talks and developer advocates :/. I feel the same about htmx, another simple tiny library with no deps and no build steps. Why don't people recognize the advantage in that.
It will not happen anytime soon or ever. The key to large community lies in ease of adoption, convenience and performance.
Mithril's hyperscript like syntax hinders its adoption. And now, with newer tools like solid and svelte, the ship has sailed.
Migrating from Vue2 to Vue3 is not that hard with the compat layer of Vue 3.1, it allows you to convert your code progressively. I'll guess Vuex -> Pinia is more work.
I was annoyed when I found out vuex4 was pinia. But I followed the guide and converted over and was suprised it works without any bugs. (Except for my typos during the migration) turned out great and I love the simplified api.
Yes it's not that hard and different, but it can't really be done progressively.
JavaScript framework fence sitters who are planning to use Svelte for a component in your SSR application please note that that their Web Components support is very buggy and Svelte team has no intention to fix it, Because(In their own words)[1] - "Nobody on the core maintainers team is particularly fond of Web Components" Yet,Their official doc includes support for Custom Elements; I found that svelte is not the rig…
Offtopic: I just looked through your website and I am so mighty impressed by you. Huge respects.
As someone working in a large Vue 2 app: - Very poor typescript support. - Poor performance (compared to Vue 3). - Ecosystem has already started lagging behind (e.g. Vue Testing Library for v2 has out of date dependencies, and no one is actively maintaining it) - Nuxt 2 hasn't made any releases in ages.
> - Very poor typescript support. If you use class components and prop decorators, the TS support is actually pretty nice. Kinda boilerplate heavy, but nice.
Composition API has the best Typescript support available in Vue 2. It's supported out of the box in 2.7, and a plugin in previous versions. The decorator syntax is unsupported in Vue 3 and shouldn't be used.
I find a lot of Svelte users are pretty religious and hysterically anti-React. When the first version of Svelte Query was announced, people were trashing the API because it looked like hooks and "you don't need those in Svelte", concluding the library must be useless. There's a lot of the "Svelte is the one true way" talk, similar to when Vue was the main alternative to React. The core team seem very reasonable but I…
I was looking at the svelte-query PRs recently, and I didn't see anything that looked like "trashing". I agree that if you want to keep the patterns that make React-query so amazing, but apply them in Svelte, you should use idioms that make sense in Svelte. The exact syntax (`useQuery` and friends) isn't the point, and the `use[A-Z].*` naming convention actually communicates that you're hooking into the React lifecyc…
This could have been a year ago at this stage. It was on r/svelte, if I recall correctly. Svelte doesn't have idioms for reusable reactive logic. The $ sign is used to drive functionality in Svelte, so you can't use it to signify something observable like with RXJS. For Solid, they use createQuery because that is the convention in Solid. For Vue and Svelte, they stick with useQuery. I think the idea is that useX is just a shorthand for "here is some abstracted reactive functionality". Ultimately it has nothing to do with how the reactivity works, it just says, "this function will tie into your reactivity". They could have just called it query, but it seems arbitrary to change the name.
The very first paragraph leads me to believe this is just a rewrite into svelte for the sake of it - I get it, Svelte is the new hotness on the FE-js-block, but this entire post stinks of "someone on the dev team advocated and fluffed enough figures to convince us. So now we're going to tell you why it was the right choice!" I say all this pretty confidently as someone currently maintaining a massive legacy vue2 app…
Excellent observation. This right here is what a senior frontend engineer, that has gone through a couple rewrites and hype cycles, looks like. The fact that they used a popularity contest as justification is laughable: if you have more than 3 years in the field you have experienced the pattern that the new kid on the block, often untested and with smaller mind share, jumps to the top of any "which framework would yo…
> No stable and productive framework will ever be able to compete in hype and good PR than alpha-quality software.
Huh? Stable and productive tools will let developers ship features while hyped frameworks come and go. Whatever survives and is in good shape after multiple hype cycles is surely a winner.
JavaScript framework fence sitters who are planning to use Svelte for a component in your SSR application please note that that their Web Components support is very buggy and Svelte team has no intention to fix it, Because(In their own words)[1] - "Nobody on the core maintainers team is particularly fond of Web Components" Yet,Their official doc includes support for Custom Elements; I found that svelte is not the rig…
Offtopic: I just looked through your website and I am so mighty impressed by you. Huge respects.
Thank You for checking my blog and for the comment!