11–20 of 222 posts
You 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.
You 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.
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 components who need it
I'm doing this with Hugo for rendering the static parts, and htmx for loading hydrated partials. The HATEOAS approach simplifies state management in the application. There is no client side "routing", just links and the back button.
In addition to vanilla libs, I include one "app.js" bundle. This file is created with esbuild and linted with deno. My "business logic" can be written in TypeScript in VSCode with the Deno extension and LSP server.
Lost me at building a custom CMS for the MVP, or did I misunderstand?
Nope, that's my feeling too. Somehow for a news site mvp in 2023 we still reinvent the wheel.
As the author states, ... Svelte Stores are rough. Beyond just missing usage patterns and documentation, we found that several features are lacking, especially when used with native reactivity (`$:`). Another area lacking is TypeScript support. Our frontend codebase at OKcontract is implemented with Svelte, but we had to build some low-level libraries (including a wholly new implementation of Stores) to make it worth…
How is this[1] diagram built? I have seen this font in quite a few places. [1] https://claudioholanda.ch/assets/blog/en/0003/1.svg
You 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.
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 to use Redux, it's closer to MobX: https://pinia.vuejs.org/
There are also plenty of component libraries, like PrimeVue: https://primevue.org/
Seriously, the only actual complaint I have about Vue is that the 2 to 3 migration wasn't all that pleasant (albeit not as painful as what Python dealt with hah).
Oh and for more complex use cases (like what Next provides), there is Nuxt: https://nuxt.com/
