Comment by iamsanteri | Hacker News Reader

Comment by iamsanteri | Hacker News Reader

After using Vue for a long time, React felt like an unforgiving piece of cr*p. As time went on and Vue was getting its Composition API while kind of moving in the overall direction of React, I decided to try class-based components and didn’t like them that much (this was a couple of years ago). Recently, I went through these new docs and read and applied the stuff I learned, and I can say it was a surprisingly nice experience. I just needed to get friendly with a composition-ish, functional-ish and JSX-ish way of thinking. Alone the thought of HTML-in-JS instead of JS-in-HTML made me crazy back then (it still kinda does). But when you get the hang of building actual user interfaces instead of just websites, it makes a lot of sense. If you’re comfortable with javascript while daring to take the less-opinionated route as opposed to an all-out framework, you'll simply feel the power!

Anyhow… To this day, I still think it’s an unforgiving, crazy beast of a library for a weekend hobbyist developer like me. But I kinda like it now and in big part it’s thanks to hooks, functional components and these new docs. Good job team, and congratulations on finally getting this live!

As someone who worked with both, vue 3 is miles ahead imho. Scoped css, well working two-ways data binding (now being mimicked again with signals after mobx demise) and reactivity, easier to get performance out of the box without the hook madness.

In many ways I do agree with you, but by now all these front-end frameworks and libraries, including their server-side rendered counterparts (like Nuxt, Next, etc.) just keep borrowing things from each other.

Regarding performance, I remember having blocking sluggishness with v-model that shouldn’t have been there back in Vue 2 days.

Also, for example, in Vue 3, my favorite component library Buefy (based on Bulma) is no longer available, and I don't think any of the other ones have (arguably) come so close and extensive to what I want.

Vue 2's transition to Vue 3 (if you want to use the new CLI tools and the Composition API) had to, by definition, fragment the ecosystem in unpleasant ways no matter how carefully and sensibly it was managed by the core teams in charge.

You can see that Vue went down slightly in recent developer surveys, and I suspect this to be among the main reasons. As if Evan himself would be suddenly more focused on his build tool Vite as opposed to Vue itself (of course it's just an illusion).

But I still love Vue because of their amazing docs, and the fact that they let me enter the world of web-development in a relatively accessible manner (this may not have been possible with React, for me personally). Lack of something like scoped styles alone baffles me in React to this day, but it makes kinda sense in the ecosystem it's operating in...

Oh, nice for reminding me, SSR is also better imho on Vue with Nuxt than anything in react world. Next.js has the tendency of monkey patching plenty of APIs, even broke native fetch when uploading anything bigger than 14 kbs.

To clarify: there's no "native" fetch to patch. Both Nuxt and Next have been adding it to the runtime to normalize it across Node.js versions and environments, and to add critical capabilities that the Web standard lacked (like being able to read the `set-cookie` header or customize `Host`).

Worth noting: we've been enabling SSR for React since 2016[1], and some of the largest websites on the internet SSR with Next.js: Twitch, Hulu, Nike, and even parts of Amazon[2]

[1] https://vercel.com/blog/next

[2] https://twitter.com/rauchg/status/1594779272945627136

Remix is the gold standard of SSR to be honest. I worked with both, Nuxt and Next.js, but Remix with is heavy usage of web standards just makes the most sense to me.

> Also, for example, in Vue 3, my favorite component library Buefy (based on Bulma) is no longer available, and I don't think any of the other ones have (arguably) come so close and extensive to what I want.

I had a look at the component libraries that are compatible with Vue 3 a while back and concluded that either PrimeVue or Quasar are some of the better choices for my web dev needs.

Surprisingly, many of the formerly popular options are stuck with just Vue 2 support.

Vuetify is back now, and I've really been enjoying it for a side project.

I never really got why people LOVE two-way binding to the point that they add things like mobx to projects. IMHO the one way data flow makes things so much easier to reason about.

In Vue two way data binding, like v-model="var1" is syntax sugar for `v-bind="var1" v-on:input="var1 = $event.value"

The difference between this and rreact is less typing, easier mental model and less issues (because react calls render() multiple times)

Which are also just sugars for creating setter callbacks.

You only have issues with render getting called multiple times if you use React incorrectly...

That is one way to look at it. The other way is that vue/svelte/solid do not have a way for them to be used incorrectly

MobX is fantastic! But you do have to change your philosophy quite a bit compared to what you would do in vanilla React - namely you need to displace most of your state management to the outside of the components.

Once you do that, React becomes purely functional (and quite "uni-directional", if that's the right term). Just update the state (in an event handler or when a Promise resolves after a fetch or another part of the UI finishes) and UI auto-magically reflects that on the screen.

Arguably, MobX + React is closer to the React's original ideal of `UI = f(state)` than the vanilla React itself.

Spitting truth right here. The problem is MobX is little too unfamiliar for newbies.

I thought Zustand is kinda simplified clone but seems like computed properties don’t work super well.

Agreed! Also, you can use strict mode with mobx and help force it to be one-way, it's up to you as a developer.

Two-way data binding trades a slightly more complex and less transparent rendering model for more efficient rendering. You don't re-render the entire component and diff the two components you have to understand changes, you simply change the leaf.

I'd say in Vue it rarely causes troubles, in React world it leads to few non-obvious edge cases where React's one way data flow is indeed easier to reason about (but less performant).

Mobx demise?

mobx demise? Did something happen to mobx?

I haven't used Vue 3 but I have used Vue 2 and React extensively. React is much better for anything but tiny projects.

It has much better Typescript support, and also it doesn't have Vue's spaghetti reactivity system, both of which vastly increase the chances of bugs.

I guess you could say they're more similar if you simply don't care about bugs at all.

I think typescript support was a priority aspect to be addressed for Vue 3 making it sort of a first-class citizen. The whole new composition aspect of it was to address large codebases and large-scale applications. So I understood that V3 makes all the difference if TS support and working on larger project is important for you. In fact, I think if you are coming from React and try it out, you are highly likely to feel right at home there.

Good thing then that I specified Vue 3 and not Vue 2.

Vue 3 has excellent TS support.

It's better but it's still not as good as React.

What happened to Mobx? It was my understanding that it’s still going strong.

Interesting, I had an opposite experience. I started out using React when using class based components was a way to go then stopped for quite some time. Years ago I had to use React for something and decided to use the new approach with hooks and it was such a painful experience - it was harder to learn and use, also I introduced many ridiculous rendering bugs. I still feel that component based approach was somewhat easier and more straightforward to get into even if more verbose.

Yes, it can be tricky, and sometimes I too catch myself asking, "why is it designed like it is" with regards to hooks, I won't lie. But, there is something there that makes it attractive to me where it was off-putting before. Alone as a complement to more extensive state management libraries, or other tools intended for larger scale apps, it serves as a nice middle-ground solution. You can build your own bits of logic in quite an accessible way now too. In other words, for me personally I feel that there is something distinct and interesting going on here.

Finally, if you combine it with the fact that it seems to hold on as the industry standard for jobs, and being useful for native mobile development via React Native, it all comes together nicely in my mind. With its huge ecosystem and closeness to plain vanilla JS, I guess it just makes me simply a bit of a better developer and gives me a new perspective on things. That's that.

I also like what it inspired in Vue. At first I thought "oh no they're taking what React did and throwing it into Vue". But it actually ended up to be a very true-to-Vue variant with just some idiom similarities. The new Vue 3 ecosystem with Pinia blends together nicely

Thank you! Glad to hear it made things click :)

Svelte > Vue > React

Is it possible to add Svelte gradually for simple and small parts of a website without a compile step? It surely seems amazing and all the rave these days!

Then again, the whole front-end ecosystem is moving at a pace I cannot quite follow. Instead, I've been going into the direction of traditional monoliths and working through the docs of Django and RoR.

There you have a plain "good-old" templating language with sprinkles of htmx and alpine where you need it. This along a bunch of back-end devs that seem to not want to even touch the javascript stuff with a stick. It almost feels refreshing though, particularly if you want to build rapid MVPs while retaining maximum control of your entire stack and IP. When teams grow and you need to support extensive and/or thicker clients, I believe this is where bigger front-end libraries like you mention truly shine. I'm still counting on us coming a full circle and there being a re-emergence of traditional monoliths in the future though. But then again, with supabases, pocketbases, strapis and other "simpler" backends of this world, who knows what'll be happening even in the nearest future...

Reply on news.ycombinator.com