Live data from Hacker News

Vue.js 3

github.com

241–250 of 308 posts

Re: Vue.js 3

#241
post #200

Earlier quoted context omitted.

React is a quite bit more all-in than Vue though. For example, an old app I'm aware of has HTML generated by JSP with its own convoluted maven build process and uses a mix of AngularJS and jQuery to hydrate client-side functionality on top of it. The development workflow is a draconian exercise in acrobatics through remote desktops and VPNs in really old laptops (because "security" and unions). Vue has similar hydrat…

This is also just plain false you aren’t shipping jsx and react doesn’t depend on anything but there being a stable host DOM node. It’s literally the other way around, vue uses global registration making it the only one of the three frameworks likely to give you any issue at all https://vuejs.org/v2/guide/components-registration.html

The JSX point boils down to this: you can't say with a straight face that using react without writing JSX is as idiomatic as pulling vue from a CDN, and you can't say that using JSX is as easy to setup on a legacy codebase.

React doesn't depend solely on there being a stable host DOM node. It also generally assumes data is programmatically structured. Try rendering FAQs as HTML with PHP then sprinkling answer toggling functionality with React and you'll see it's not straightforward at all; it would require refactoring backend code into a REST API or similar. With vue, add v-if and you are done.

Nobody's saying vue doesn't have faults; it has plenty of them. Let's not get all fanboyish when someone points out a legit con in react.

Re: Vue.js 3

#243
post #176

Earlier quoted context omitted.

You can do the same thing with React though, you can arbitrarily render a React root anywhere, and an arbitrary number of times on the same page. For instance, I work on an app that was originally written in Backbone / Marionette, but I was able to write generic connectors to allow us to drop in React at any point in the tree. Similarly, we can go back to Marionette / Backbone at any point in the tree. It's made grad…

> you can arbitrarily render a React root anywhere I think this exact capability is what led to such strong React adoption. It's almost viral within an application. The main application that I worked on a few years ago was on Backbone / Marionette and we evaluated React by writing several small but complicated nested components, with state controlled by existing mechanisms. After liking both the flux application arch…

Why is Jsx a hurdle? Because you need a transpiler?

I find it the other way. Vue has a big learning curve. Learning their special directives and double binding gotchas takes a while.

While jsx is a very thin layer for existing Js. All control flow is good ol js. The tags just translate to createElement/h calls. React (class based React) was easy to pick up.

Re: Vue.js 3

#244
post #99

Earlier quoted context omitted.

curious how easy it will be to move from vue 2 to vue 3

They're working on a "migration build" which is a version of v3 that has support for v2 behaviors + warnings, which should help smooth any transition. On top of that, v2.7 slated for 2021Q1 also includes the relevant migration warnings, which should help make life easier

I just updated a 1 day app, it took a couple hours. No Vue.set/this.$set, significant changes to render functions, changes to much of the boilerplate. I was thinking that most of the deprecated behavior could be easily emmulated. The performace improvements are worth the pain, but I have a lot of code to update. Hopefully the migration build will solve it. It would be nice to avoid a python3 situation.

Re: Vue.js 3

#245
post #183
post #140

Earlier quoted context omitted.

I suppose it could, but there are annoyances with JSX defaults. For instance, Vue provides a method to explicitly declare your template variable delimiter syntax. Last time I looked this was requested of React, but not implemented, someone correct me if I'm wrong on that and it has come along in the last year or two. So.. lets say you wanna put some modern Javascript in some Django templates to make them look spiffy.…

React doesn't have templates, so that's a non-issue. JSX is sugar on JavaScript, but it's not a string. So template delimiters don't matter (that is, if you didn't use a build step, then it would be straight javascript functions calls)

That’s the whole point of the discussion: Vue makes it easier to have Django spit out My data here and then Vue notices and adds the event listeners. In React, it is very difficult if React has to start with foreign template output because it wants to own the (V)DOM.

Re: Vue.js 3

#246
post #200
post #176

Earlier quoted context omitted.

You can do the same thing with React though, you can arbitrarily render a React root anywhere, and an arbitrary number of times on the same page. For instance, I work on an app that was originally written in Backbone / Marionette, but I was able to write generic connectors to allow us to drop in React at any point in the tree. Similarly, we can go back to Marionette / Backbone at any point in the tree. It's made grad…

React is a quite bit more all-in than Vue though. For example, an old app I'm aware of has HTML generated by JSP with its own convoluted maven build process and uses a mix of AngularJS and jQuery to hydrate client-side functionality on top of it. The development workflow is a draconian exercise in acrobatics through remote desktops and VPNs in really old laptops (because "security" and unions). Vue has similar hydrat…

>you are pretty much forced to describe the view from scratch in JSX.

That's just not true, I've just finished working on a client project creating a migration scaffold between react and angular-js - like someone mentioned above, there are libraries to support communication and embedding both ways.

Re: Vue.js 3

#247

Earlier quoted context omitted.

I can only suppose it means 100% less memory consumption by Vue, and then Vue somehow frees 20% of memory from other running processes, which would lead to some pretty interesting results.

also being 130% faster it's rendering results before computations

That one is not so odd. If you drive 10 mph and accelerate to 23 mph, you're now 130% faster.

You can do the same if you measure rendering speed in fps.

Re: Vue.js 3

#248
post #221
post #6

> Vue 3 has demonstrated significant performance improvements over Vue 2 in terms of bundle size (up to 41% lighter with tree-shaking), initial render (up to 55% faster), updates (up to 133% faster), and memory usage (up to 120% less). What does 120% less memory usage mean, really?

I see the confusion. 100% more of something = 2x more 120% more of something = 2.2x more 120% less of something (problem here!) = 2.2x less = 1 / 2.2 of something = 45% of something I think the writer meant 2.2x improvement in memory usage rather than 120% less memory usage -- the word "less" used in conjunction with a percentage is confusing.

I think this is how you evaluate X% less: amount * (1 - (x / 100))

So 120% less of 10 rocks is -2 rocks, which obviously doesn’t make sense. Which is good, it shouldn’t make sense to have more than 100% less of something.

Re: Vue.js 3

#249

The announcement talk was nice to watch, however, it was technically void of any of the implementation details. It's interesting to me that they did not consider the approach of pushing more work to the compiler and less to the runtime in the manner popularized by Svelte. I wonder what the trade-off between their current rendering approach and the Svelte-based approach are?

> they did not consider the approach

they certainly did, lol. the tradeoff is the same it's been; they want all of vue available in a script tag.

Re: Vue.js 3

#250
post #243

Earlier quoted context omitted.

> you can arbitrarily render a React root anywhere I think this exact capability is what led to such strong React adoption. It's almost viral within an application. The main application that I worked on a few years ago was on Backbone / Marionette and we evaluated React by writing several small but complicated nested components, with state controlled by existing mechanisms. After liking both the flux application arch…

Why is Jsx a hurdle? Because you need a transpiler? I find it the other way. Vue has a big learning curve. Learning their special directives and double binding gotchas takes a while. While jsx is a very thin layer for existing Js. All control flow is good ol js. The tags just translate to createElement/h calls. React (class based React) was easy to pick up.

Yes, the transpiler (though everybody is already bundling these days). I really like JSX, though it's not everybody's cup of tea.

I also think other folks in this thread are referring to mounting on existing DOM in jQuery-esque use cases.

Post reply on HN