Earlier quoted context omitted.
Nope, that's my feeling too. Somehow for a news site mvp in 2023 we still reinvent the wheel.
It's a storied tradition. (I know that at least Django was written for a news site)
Thoughts on Svelte(Kit), one year and 3B requests later
31–40 of 222 posts
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#32Lost me at building a custom CMS for the MVP, or did I misunderstand?
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#33You need very strong argument not to take the most popular technologies these days. I don’t hear any arguments against react here strong enough to justify not choosing VueJS or React. It’s not in the interests of your client.
Standards-based is really the only thing that challenges react these days, i.e. raw JS with es modules, web components, and no build step/bundling. It only works in certain situations though, but when it does work, it's so much better than the giant web of black boxes and indirection that is the React universe.
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#34Earlier quoted context omitted.
Standards-based is really the only thing that challenges react these days, i.e. raw JS with es modules, web components, and no build step/bundling. It only works in certain situations though, but when it does work, it's so much better than the giant web of black boxes and indirection that is the React universe.
> Standards-based is really the only thing that challenges react these days I feel like Vue would be a better fit for this role, especially since now they have a Composition API that's as pleasant to use as React, except that they do lifecycle hooks better than React (no messing about with dependency arrays): https://vuejs.org/guide/extras/composition-api-faq.html There's also Pinia which is a lot simpler than trying…
Next is so much more refined compared to that.
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#35You need very strong argument not to take the most popular technologies these days. I don’t hear any arguments against react here strong enough to justify not choosing VueJS or React. It’s not in the interests of your client.
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#36I've moved my little hobby website to SvelteKit[1] from react and I am not regretting it.. yet. The only main frustrations I have are: - Library support is pretty lousy. You need to fudge things around to get working. I.e, with leaflet and others I have vendored in the libs and redone them. - Incremental static refresh with svelte kit is not really there. I'd like a web hook or api callback that allows me to refresh…
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#37> by wrapping a vanilla lib to a component or an action, you’ve essentially created basic Svelte version of that lib This is the key to making framework churn go away. The DX of using vanilla JavaScript is getting better every day. And is a much better experience than it was a decade ago. > Islands architecture and partial hydration can help you render static HTML with just a small portion of JavaScript for those com…
This is all fun and games until you work on a platform that requires dynamically loaded modules, error boundaries and suspense (or another form of components loading their own data) and then the no-nonsense approach falls flat. It is easy to put your nose up towards bloated frameworks when you’re doing small (static) stuff but as soon as you need the bloat you’re just reinventing a wobbly wheel without one. There’s a…
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#38I've moved my little hobby website to SvelteKit[1] from react and I am not regretting it.. yet. The only main frustrations I have are: - Library support is pretty lousy. You need to fudge things around to get working. I.e, with leaflet and others I have vendored in the libs and redone them. - Incremental static refresh with svelte kit is not really there. I'd like a web hook or api callback that allows me to refresh…
+1. I've been pushed to change tabs using `Ctrl+P` instead (search tab command) and write its route (folder's name). But it's still a bit painful
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#39Earlier quoted context omitted.
This is all fun and games until you work on a platform that requires dynamically loaded modules, error boundaries and suspense (or another form of components loading their own data) and then the no-nonsense approach falls flat. It is easy to put your nose up towards bloated frameworks when you’re doing small (static) stuff but as soon as you need the bloat you’re just reinventing a wobbly wheel without one. There’s a…
I work on a huge angular project and I can’t help but see svelte as a toy in comparison. Must be nice when everything just falls into place.
Re: Thoughts on Svelte(Kit), one year and 3B requests later
#40Earlier quoted context omitted.
Standards-based is really the only thing that challenges react these days, i.e. raw JS with es modules, web components, and no build step/bundling. It only works in certain situations though, but when it does work, it's so much better than the giant web of black boxes and indirection that is the React universe.
> Standards-based is really the only thing that challenges react these days I feel like Vue would be a better fit for this role, especially since now they have a Composition API that's as pleasant to use as React, except that they do lifecycle hooks better than React (no messing about with dependency arrays): https://vuejs.org/guide/extras/composition-api-faq.html There's also Pinia which is a lot simpler than trying…
Vue also takes a lot of inspiration from compiler first frameworks and will be implementing an optional API to bring those optimizations to core in a coming point release.
I agree with you that hooks are a great feature that many React devs would probably enjoy using.
The only downside to Vue atm is the lacking comprehensive community support for libraries like `react-aria` and `framermotion`. I think the community is working on ports, but we all know that sometimes ports make compromises that might miss the nuance of the primary library author thinking about those problems directly in relation to the target client.