Live data from Hacker News

Vue.js 1.0.0

vuejs.org

61–70 of 89 posts

Re: Vue.js 1.0.0

#61
post #59
post #54

Earlier quoted context omitted.

Could someone tell me a bit about how the two differ? I've built a decently-sized app with Ractive.js and really like it, and I might be working on an app soon where either Ractive.js or Vue.js seem like a good option. From what I've gathered so far, Vue seems like it is basically a better Ractive, and it makes more sense to use it for my next project. But perhaps I'm missing some important differences between the tw…

Ractive uses mustache templates, which I prefer as - nearly every web developer already knows mustache - mustache distinguishes what's HTML and what's not I also like ractive because it has two way bindings, and promises for when DOM changes, but maybe Vue also has those.

From what I gather it's quite possible to use mustache for Vue as well, and it also does two-way binding. I'm mostly interested in the differences between the two.

That said, the reason I used Ractive in an earlier project instead of React is exactly what you point out. Mustache is much easier for other developers to start using.

Re: Vue.js 1.0.0

#62
post #10

Earlier quoted context omitted.

> More importantly, there’s no need to worry about calling $apply in a timeout, or calling setState(), or listening to store events Calling `setState` is not a big deal and neither is dealing with stores. It's very simple and you keep your state separate from your HTML. At this point I probably can't do web development without JSX and not be miserable. The days of separate templates are hopefully forever behind me. N…

I disagree, I've never used jsx and I can still build web apps. There are plenty of templating languages to choose from, my choice is Jade. I actually have never touched React because I've never had so much DOM manipulation to make use of it. If anything I can smoothly update my DOM with marionette/backbone and a little css animation.

Funny thing is, I switch away from React if I have much DOM manipulation and only use it for the "normal" stuff, like forms.

Re: Vue.js 1.0.0

#63

Earlier quoted context omitted.

It has: https://facebook.github.io/jsx/

Emphasis on "implemented" haha. At least this makes it more open since someone can come in and make their own implementation. As it currently stands I don't think you can use Facebook's implementation to transform JSX to a framework-agnostic object.

Well, you could fork it:

https://github.com/insin/msx

Re: Vue.js 1.0.0

#64
post #41
post #37

I like it. In fact I like it more than React, which I am not using (still a happy Backbone user). A thought that I share, from the guide: "API-wise, one issue with React (or JSX) is that the render function often involves a lot of logic, and ends up looking more like a piece of program (which in fact it is) rather than a visual representation of the interface. For some developers this is a bonus, but for designer/dev…

Massive render() sounds like those massive viewControllers from Cocoa. With experience it slowly goes away. But yeah it can be daunting to look at sample codes and see 300 lines of render(). It helps if it's broken down in named function calls, but still makes you jump around.

You can always decompose the components, if your render() gets to big.

Re: Vue.js 1.0.0

#65
post #10

Earlier quoted context omitted.

> More importantly, there’s no need to worry about calling $apply in a timeout, or calling setState(), or listening to store events Calling `setState` is not a big deal and neither is dealing with stores. It's very simple and you keep your state separate from your HTML. At this point I probably can't do web development without JSX and not be miserable. The days of separate templates are hopefully forever behind me. N…

I disagree, I've never used jsx and I can still build web apps. There are plenty of templating languages to choose from, my choice is Jade. I actually have never touched React because I've never had so much DOM manipulation to make use of it. If anything I can smoothly update my DOM with marionette/backbone and a little css animation.

Yeah, but the thing with React is that it's one library, instead of having both Jade and Backbone, you can have a fully React stack and have peace of mind through it.

I've used Jade and honestly prefer the React way for sure because it combines the javascript with the html in the same file(s)

Re: Vue.js 1.0.0

#66

I'd love to see a comparison of Vue.js with Aurelia ( http://aurelia.io/ ). In my mind, Vue.js and Aurelia are the two front-runners for the next "right-weight" framework (whereas React is the lightweight champion, and Angular 2 likely to be the heavyweight winner by default).

React 0.14 is 132KB minified [1]. I wouldn't exactly consider React "lightweight," especially compared to other frameworks like Mercury [2], Mithril [3], and Riot [4], which are a fraction of the size of React but still have their own virtual DOM implementations. [1] https://fb.me/react-0.14.0.min.js [2] https://github.com/Raynos/mercury [3] http://mithril.js.org [4] http://riotjs.com/

Is there any statement from the React team about the size?

Re: Vue.js 1.0.0

#67
post #10

Earlier quoted context omitted.

> More importantly, there’s no need to worry about calling $apply in a timeout, or calling setState(), or listening to store events Calling `setState` is not a big deal and neither is dealing with stores. It's very simple and you keep your state separate from your HTML. At this point I probably can't do web development without JSX and not be miserable. The days of separate templates are hopefully forever behind me. N…

It would be neat if Facebook had implemented JSX as a framework-independent transform rather than a React-only one, that way other frameworks could use the pretty XMLish syntax rather than strings or JS objects.

There are babel transforms for it: https://github.com/openjsx In fact I've seen a user use JSX-to-HTML for his Vue templates.

Re: Vue.js 1.0.0

#68
post #55

Earlier quoted context omitted.

"and teaching him React + Flux (Alt.js) " Can I ask what do you use for routing and if you have good results with that mix?

Interestingly, we're using our "own" router that I wrote in a fit of frustration; it's tiny, not particularly well documented and has the interesting design choice of handing the route matching on to the user of the library; give each component a name and have your route matcher callback return that name and you're good to go. The reason why I went down that route (pun intended) was that we built a rather large, isom…

Thanks.

I'm trying to find my way around flux but until now has been a little frustrating experience.

I wish something like Elm was mature enough.

Re: Vue.js 1.0.0

#69
post #10
post #2

Author here - thanks for the submission, I was actually planning to do it tomorrow :) Anyway, for those of you who are not familiar with Vue, here's a blog post explaining why it's worth taking a look at: http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/

> More importantly, there’s no need to worry about calling $apply in a timeout, or calling setState(), or listening to store events Calling `setState` is not a big deal and neither is dealing with stores. It's very simple and you keep your state separate from your HTML. At this point I probably can't do web development without JSX and not be miserable. The days of separate templates are hopefully forever behind me. N…

Having to call `setState` kinda becomes a big deal when you want to separate state manipulation and make your components dumb. Both dirty checking and Virtual DOM are pull-based mechanisms - i.e. nothing happens when the state itself changes, you have to give the system a signal to pull and apply. This means when manipulating externalized state you need to hold a reference to all the components that are interested in it, or do it by registering events - which is why the original Flux is unnecessarily complex. It becomes less awkward when you have a single state atom, and that's why Redux is an improvement over vanilla Flux.

Re: Vue.js 1.0.0

#70

Sorry I can't get past the two way data binding. I have seen the issue it causes and how one way makes things so much easier to reason with. I do wish the project the best of luck though as all these frameworks do a great job at borrowing from what others do well.

In Vue two way data binding is just syntax sugar for handling form input events. If you are talking about component state, the default mode of passing data in Vue is in fact one way.
Post reply on HN