Vue.js 2.1 Released(github.com)
github.com
Vue.js 2.1 Released
https://github.com/vuejs/vue/releases/tag/v2.1.0
125 comments
I just finished watching the entire 16+ hours of the course.
It's pretty good, but it doesn't go too deep (or at all) into the new concepts in Vue 2.x like render functions, virtual dom, server side rendering and more.
I think the docs are very good and more than enough not only just to get started, but also to keep you going.
I think the docs are very good and more than enough not only just to get started, but also to keep you going.
Thanks. With this coupon "CNETBF2016" it's now just $10 and I bought it at that price!
Thank you, I've been looking for vue.js courses
Guessing that's an affiliate promotion code?
Not from me. I'm just trying to pass on the savings to HN users. :)
To the OP: I also purchased this at $10, thank you!
-------
I did a search for coupon codes and I found the exact coupon code from [1].
Can I ask, what would the problem be if the code was affiliated with an affiliate promotion?
The end user pays $10, which I think we can both agree on. It's a "NET" benefit for HN users to learn something new very cheaply.
If couponkoo negotiated with the vendor of the product, so that they can advertise a coupon and get some kick back, you know because they too have to keep the lights on.
Is that such a big deal now on HN? Can you please explain yourself because I don't see an issue here personally!
[1]: http://www.couponkoo.com/coupon/95-off-vue-js-2---the-comple...
-------
I did a search for coupon codes and I found the exact coupon code from [1].
Can I ask, what would the problem be if the code was affiliated with an affiliate promotion?
The end user pays $10, which I think we can both agree on. It's a "NET" benefit for HN users to learn something new very cheaply.
If couponkoo negotiated with the vendor of the product, so that they can advertise a coupon and get some kick back, you know because they too have to keep the lights on.
Is that such a big deal now on HN? Can you please explain yourself because I don't see an issue here personally!
[1]: http://www.couponkoo.com/coupon/95-off-vue-js-2---the-comple...
afghanPower, figured you would not reply. Stirring up trouble again!
Shame I cannot down vote you yet!
Shame I cannot down vote you yet!
Thank you!
Thanks a lot for the link! I was looking for a way to learn more about vue.js and this is a great chance.
It is scary that everyone is hyped and the site just shows off a series of syntax combinations.
So far my Vue.js experience has been great. Even though I don't particularly enjoy front-end development and the tools and techniques I'm supposed to use for them, Vue.js has been a breath of fresh air between my frustrations with HTML, Javascript, npm, CSS, HTTP and all the other things that are needed to stitch everything together. It really is a great framework.
The one thing that does still bug me these days is that even now that Vue 2.1 is out, many components I'd like to use are still not compatible with Vue 2.x, and almost all the Vue tutorials, questions, solutions, etc. I find are about Vue 1.x, which is mostly incompatible with Vue 2.x. But that should improve over time, of course.
The one thing that does still bug me these days is that even now that Vue 2.1 is out, many components I'd like to use are still not compatible with Vue 2.x, and almost all the Vue tutorials, questions, solutions, etc. I find are about Vue 1.x, which is mostly incompatible with Vue 2.x. But that should improve over time, of course.
I'm writing an easy to understand tutorial with vuejs2 here https://github.com/thewhitetulip/intro-to-vuejs
Thank you!
you are welcome. I am going to write a detailed chapter on components and how to use them in a big app. I plan to migrate http://github.com/thewhitetulip/Tasks/ to use Vue as the front end, the app Tasks is written in Go.
Have you checked the Awesome Vue [0] list of components? There are many there that support v2
[0] https://github.com/vuejs/awesome-vue
[0] https://github.com/vuejs/awesome-vue
Yes, I've looked at that list, but some of the components I'd like to use are still not compatible (Keen UI, for instance).
I'm using Keen UI @next a little. I had to hack it just a tad to propagate some click events but otherwise it was fine.
You can consider about mint-ui, which is compatible with vue2.0
are there any tutorials that would help a beginner start on that front?
I just went through the whole 'getting started' guide [1], reading everything, looking at the examples, and playing around in my own npm playground to see if I really got it.
I still consider myself a novice, I've only spent about 6 hours playing with it, but I'm already able to write my own components, communicate between them using events, set up data model for my app, binding the data model to bootstrap components in my templates, etc. Not bad for someone completely new to web development. Which says a lot more about Vue.js than about my own capabilities ;-)
One tip I can give you is to take a very good look at the Vue 1 to Vue 2 changes [2], and all the things that have been deprecated in Vue 2 (quite a lot). The big mistake I made was to mess around with examples written for Vue 1 and thinking there was some problem with the framework itself, while all of it was because I was using deprecated features (e.g. the event system has changed significantly).
[1] https://vuejs.org/v2/guide/
[2] https://github.com/vuejs/vue/issues/2873
I still consider myself a novice, I've only spent about 6 hours playing with it, but I'm already able to write my own components, communicate between them using events, set up data model for my app, binding the data model to bootstrap components in my templates, etc. Not bad for someone completely new to web development. Which says a lot more about Vue.js than about my own capabilities ;-)
One tip I can give you is to take a very good look at the Vue 1 to Vue 2 changes [2], and all the things that have been deprecated in Vue 2 (quite a lot). The big mistake I made was to mess around with examples written for Vue 1 and thinking there was some problem with the framework itself, while all of it was because I was using deprecated features (e.g. the event system has changed significantly).
[1] https://vuejs.org/v2/guide/
[2] https://github.com/vuejs/vue/issues/2873
I'm writing one! https://github.com/thewhitetulip/intro-to-vuejs
It's still pretty ripe big guy. You keep promoting it like you are further along. I kept looking thinking there was more and there wasn't. Great start and I'm even happy to assist you, but ease up on the promo unless yare inviting people to contribute.
Just a suggestion as someone who is keen to see a ton more on 2.x and is even also keen to help others like yourself; not against you or your efforts at all.
Just a suggestion as someone who is keen to see a ton more on 2.x and is even also keen to help others like yourself; not against you or your efforts at all.
Pls don't take this personally, but I am not entirely sure what the problem is. I didn't say "I wrote one", I said, "I am writing one", which means it is not yet finished and is a work in progress.
Any and all contributions are always welcome.
Any and all contributions are always welcome.
Another Vue.js 2.x tutorial that I am currently finishing is https://jayway.github.io/vue-js-workshop/. It is a nice intro into all the important pieces of Vue.js.
Does the guide include state management? As a newbie I face that problem. I was able to figure out how to use vue-resource, rendering, components, the next step in my learning cycle is to understand how to interact with a JWT server, set tokens and do state management. I don't even understand anything by the words state management :D
I am sorry if this sounds too ignorant, are frameworks like Vue.js (I actually read the guide and understood some wonderful things about its philosophy since I am actually developing backend mainly) or React, etc.. reasonable to use in websites in general (instead of jquery or taking some tasks from it) or they actually only reasonable for mobile web applications and SPAs?
What about the SEO and search engine rendering to custom HTML elements like in Vue.js components? is it okay or affects SEO?
What about the SEO and search engine rendering to custom HTML elements like in Vue.js components? is it okay or affects SEO?
I can't speak to Vue, but React is overkill for many sites. The virtual DOM etc is incredibly useful for sites that update the page very frequently, but if the only thing you're making is a static site and a contact form, you don't need React.
That said, I do like the React model of creating components (and suspect this is why so many people use it when it's unnecessary). I'm looking forward to browsers implementing custom elements so that we can all compinentise this way without the overhead of a large JS framework.
That said, I do like the React model of creating components (and suspect this is why so many people use it when it's unnecessary). I'm looking forward to browsers implementing custom elements so that we can all compinentise this way without the overhead of a large JS framework.
Chrome, Safari, and Opera (because of Blink) have implemented Custom Elements and Shadow DOM. Firefox appears to be working on it, and for Edge it's high priority, so things are coming along nicely :)
edit: The polyfills are also very viable. I know sometimes people knock polyfills, but they're really just libraries that implement the component model and encapsulation that frameworks generally have to, but they go away over time.
edit: The polyfills are also very viable. I know sometimes people knock polyfills, but they're really just libraries that implement the component model and encapsulation that frameworks generally have to, but they go away over time.
While the virtual DOM is a component in React's popularity, the main thing that I believe people use it for is the functional, one way data flow it allows you to use combined with the component model.
Not in websites per-se, but even the simplest contact/enquiry web form/wizard with some validation/interaction is a breeze to program in Vue.js compared to jQuery.
We have multiple internal enterprise applications where both jQuery and Vue.js are available. More often than not, when there's a pull request, even for the simplest UI interaction, it can be refactored to few lines in Vue.js from the jQuery event and DOM mess. We plan to move away from jQuery in a year or so, and no new jQuery plugins are allowed.
Vue.js has also allowed us to iterate much faster on complex UI than it would be possible with jQuery.
For bigger apps, you can add components, and for even bigger - add Vuex. Vue.js (same as React) really is the new jQuery.
We have multiple internal enterprise applications where both jQuery and Vue.js are available. More often than not, when there's a pull request, even for the simplest UI interaction, it can be refactored to few lines in Vue.js from the jQuery event and DOM mess. We plan to move away from jQuery in a year or so, and no new jQuery plugins are allowed.
Vue.js has also allowed us to iterate much faster on complex UI than it would be possible with jQuery.
For bigger apps, you can add components, and for even bigger - add Vuex. Vue.js (same as React) really is the new jQuery.
From personal experience for general web-sites like blogs, etc. it's better to do them old way, you don't need to worry much about seo, caching, precompilation, etc. But business apps huge community-like ones, and big shops benefit a lot from frameworks like that. But you should always base your decision on cost of implementation, support, etc.
Thanks, I am more interested in developing social websites with modern look and more performance, I mean like the design of medium.com or hashnode.com, I think they do render the first page fully canonical HTML, and then every subsequent request is rendered using the js framework GETing some JSON which gives more space to the server to do other work.
I am really interested in this approach but I fear about the SEO and any additional unnecessary complexities like compatibility with old browsers and OSs especially in Android.
I am really interested in this approach but I fear about the SEO and any additional unnecessary complexities like compatibility with old browsers and OSs especially in Android.
If you fear about the SEO, start with Turbolinks.
Take a look at russian vk.ru
It's lighting fast compared FB and does all the same things. Really neet. FB makes my laptop literally over heat.
It's lighting fast compared FB and does all the same things. Really neet. FB makes my laptop literally over heat.
React in particular, however, was specifically made to handle the state of just parts of the UI on Facebook (like notifications). You could build out a static site but let React handle something more complicated and it'll work just as fine, if not better.
It just so happens that the extensibility around React led to stuff like redux and react-router that's perfect for SPA's, but at its core it's just a View layer that could live alongside a traditional site.
It just so happens that the extensibility around React led to stuff like redux and react-router that's perfect for SPA's, but at its core it's just a View layer that could live alongside a traditional site.
Both Vue.js and React allow you render HTML on the server side. This helps get the first render out quickly where the browser can pick up the state and continue from there.
https://vuejs.org/v2/guide/ssr.html
https://vuejs.org/v2/guide/ssr.html
As it usually is in this industry, the answer to this question is: "it depends".
There's a point, where using jQuery alone just won't cut it.
I guess a rule of thumb here would be: If you're providing a service that requires an account - you probably need something more than jQuery.
There's a point, where using jQuery alone just won't cut it.
I guess a rule of thumb here would be: If you're providing a service that requires an account - you probably need something more than jQuery.
In vue.js, SEO is taken care of with with server side rendering[1].
This assumes that you are using node.js as your backend though.
[1] https://vuejs.org/v2/guide/ssr.html#SEO
This assumes that you are using node.js as your backend though.
[1] https://vuejs.org/v2/guide/ssr.html#SEO
Only that node can talk to your backend right?
I haven't heard of Laravel getting SSR yet, so yeah.
What I like about Vue is that it makes it is very easy to use it as a component of a larger website or non-SPA application. You can use it where you would otherwise use jQuery in order to build widgets or interactive components. It makes it very easy to drop it into a page without a lot of ceremony (no flavor of the month build tools or exotic precompilers are required to get started).
What would be better o build in terms of code clarity, performance and some other var I can't thin of rn, a slideshow in JQuery or using Vue.js?
In the past I've used https://prerender.io/ with a Backbone + Marionette website. You configure your .htaccess (or similar) to direct web crawler's to prerender.io's cached representation of your website. Works great and completely side-steps the issue of SEO for dynamic websites.
Google will index sites that render their pages through Javascript. There are two caveats to be aware of:
1. It drops out if it takes more than 5 seconds to complete its operation and uses whatever is render then.
2. Indexing with HTML happens in near-realtime. Indexing with JS to HTML is delayed by about 1-5 days depending on the popularity of the site.
So if you're serious about it; you ought to heavily include metadata for Google to index during the first run through or place a bare bones HTML copy down.
1. It drops out if it takes more than 5 seconds to complete its operation and uses whatever is render then.
2. Indexing with HTML happens in near-realtime. Indexing with JS to HTML is delayed by about 1-5 days depending on the popularity of the site.
So if you're serious about it; you ought to heavily include metadata for Google to index during the first run through or place a bare bones HTML copy down.
Proof?
I can't find the article yet, but a few months ago I read that only some chinese search engines had problems with that. The big ones didn't care much.
I don´t know why Riot.js (another js framework) don't attract more people. I used it and it´s awesome. Today they launched the 3.0.0 version http://riotjs.com/release-notes/ . Here is a quick introduction http://vitomd.com/blog/coding/hello-riot-js-quick-tutorial-a... I highly recommend it.
I also love Riot. It makes custom tags. It's easy to author and debug w/o so many additional tools. Serverside or client-side rendering. Was a snap to plug Riot in to replace jQuery "components" in a mostly PHP driven app.
riot makes me happy: truly feels like native. makes javascript a joy to use. don't tell the competition.
> http://mithril.js.org/comparison.html
> Vue's implementation cleverly hijacks array methods, but it should be noted that Javascript Arrays cannot be truly subclassed and as such, Vue suffers from abstraction leaks.
Can anyone who knows how vue is implemented explain this statement?
> Vue's implementation cleverly hijacks array methods, but it should be noted that Javascript Arrays cannot be truly subclassed and as such, Vue suffers from abstraction leaks.
Can anyone who knows how vue is implemented explain this statement?
they are talking about limitations of change detection in Array [1]. It is technically true, but practically, it is not much (if you are aware of it)
[1] : http://vuejs.org/v2/guide/list.html#Caveats
[1] : http://vuejs.org/v2/guide/list.html#Caveats
I've been using Vue.js for a new project and it is a breath of fresh air after using React. It has all the benefits of Knockoutjs (which was my gateway into these types of frameworks), but much nicer in-code organization (I'm looking at you ko.observable).
I am always looking for the fastest way to build a complete app. Brought me to Rails. Then to Meteor/React (which was mixed). Then some Rails/React which is ok.
Vue looks really appealing on the simplicity and completeness side.
I would like to know from people using Vue what backends you're using. In order to complete the loop - the simplest stack overall Vue+???.
Vue looks really appealing on the simplicity and completeness side.
I would like to know from people using Vue what backends you're using. In order to complete the loop - the simplest stack overall Vue+???.
I've used Vue w/ Rails so far and it's been pretty good. The one real complaint is that I really wish is that I could use Vue components (.vue files) in a better integrated way with the Rails asset pipeline.
react-rails does this really well, making JSX transformation a drop-in gem, vs. having to set up some kind of front end task runner of sorts and constantly having to commit compiled files and such.
Beyond that, Vue has been amazing, and I really love it.
react-rails does this really well, making JSX transformation a drop-in gem, vs. having to set up some kind of front end task runner of sorts and constantly having to commit compiled files and such.
Beyond that, Vue has been amazing, and I really love it.
Thanks for the reply. Yea the rails asset pipeline integration seems an issue and Vue hot reload capability is also something I'd want workings seamlessly (not sure if that would be problematuc). Perhaps best to just use rails as API server. Then be able to create complete Vue front without struggling w integrations.
I'm thinking to rewrite my templates in vuejs then put a nodejs+vuejs SSR layer in front of my non-nodejs backend. I'm wondering how Laravel expects me to handle this situation.
Nice, I love Vue.js it is light weight yet fulfill 90% of the needs of a large SPA without a third party language, some bureaucratic dependency injection and without getting in the developer's way by mandating this or that build tool. But competition is good so I'm glad there is a front end framework for everyone out there.
The sentiment 'competition is good' in the context of Javascript universe is a bit ironic since that's what led us to the recent fatigue grievance.
People have different requirements, there is not a single framework that would make everybody happy. The issue isn't the the number of frameworks by the way but the complexity of the build tools in the context of Nodejs. Grunt,Gulp,Babel transpilers and co, they are not frameworks, they merely transform assets, yet they make JS development extremely complex and bureaucratic.
I'm going to build a vuejs markdown site editor similar to Gatsby I just don't like Facebook it's refreshing that an independent project is gaining popularity the server side rendering is a big deal when you want to support mobile well.
Gatsby is awesome. Would love to see something like it without FB's licensing attached to the underlying libraries. Please do a Show HN when you've got something more-or-less working :)
Is this looking a lot like Angular 1.x to anyone else? I've heard it's actually more similar to React but I'm not seeing it... ?
It's like Angular in that they use a similar templating language, and it's like React in that they're using a component-based declarative DOM API.
Angular also has a component-based declarative DOM API. Always had, but since version 1.5 it's more explicit.
If you like the awesome simplicity of Vue, but prefer a more familiar mustache-style templating language with your virtual DOM, try ractive.js from The Guardian.
http://www.ractivejs.org/
http://www.ractivejs.org/
here's an link[0] to a comparison with react, angular 1 and others.
[0] - https://vuejs.org/v2/guide/comparison.html
[0] - https://vuejs.org/v2/guide/comparison.html
Hm, doesn't seem that much of a win for React users.
The performance is compareable, but they went for templates instead of the "it's just JS"-philosophy of React. Reminds me of "the fear of turing complete templates"[0]
Also, they mention their bindings are similar to MobX. I had the feeling MobX was a step back in the React eco-system, if I think about what Facebook wanted to achieve with Flux.
But yes, overall it seems like a much simpler approach than React or Angular, not to mention Angluar 2, lol. But it seems to come at the cost of the points I mentioned, which were really a pain back in the days and got solved with Flux and JSX.
It also doesn't seem to solve some problems that React didn't solve, like realtime asynchronous data or fractal state.
[0] http://lhorie.github.io/mithril-blog/getting-over-a-fear-of-...
The performance is compareable, but they went for templates instead of the "it's just JS"-philosophy of React. Reminds me of "the fear of turing complete templates"[0]
Also, they mention their bindings are similar to MobX. I had the feeling MobX was a step back in the React eco-system, if I think about what Facebook wanted to achieve with Flux.
But yes, overall it seems like a much simpler approach than React or Angular, not to mention Angluar 2, lol. But it seems to come at the cost of the points I mentioned, which were really a pain back in the days and got solved with Flux and JSX.
It also doesn't seem to solve some problems that React didn't solve, like realtime asynchronous data or fractal state.
[0] http://lhorie.github.io/mithril-blog/getting-over-a-fear-of-...
You can use JSX to write your render functions in Vue [0]. It's opt-in as the Vue community views them as overkill in the usual case.
Personally, I appreciate having the intuitive approach for templating as the default for people who don't share my encyclopedic knowledge of web development. They can more easily follow along and contribute.
[0] https://vuejs.org/v2/guide/render-function#JSX
Personally, I appreciate having the intuitive approach for templating as the default for people who don't share my encyclopedic knowledge of web development. They can more easily follow along and contribute.
[0] https://vuejs.org/v2/guide/render-function#JSX
I see :)
> I appreciate having the intuitive approach for templating as the default for people who don't share my encyclopedic knowledge of web development
I always saw it the other way around, haha :) Why should I learn some template language, when JS can do the job and I already know it.
> I appreciate having the intuitive approach for templating as the default for people who don't share my encyclopedic knowledge of web development
I always saw it the other way around, haha :) Why should I learn some template language, when JS can do the job and I already know it.
JSX is not JavaScript. If its not in a spec that is ever going to be implemented by a JS runtime, like a browser or Node.js, then it's not JavaScript. It's a superset of JavaScript.
If you admit that JSX is a superset of JS then the downsides become readily apparent. Many will still choose JSX and there's nothing wrong with that, but the argument isn't "why would I use X when Y is better".
If you admit that JSX is a superset of JS then the downsides become readily apparent. Many will still choose JSX and there's nothing wrong with that, but the argument isn't "why would I use X when Y is better".
IMO JSX is such a simple syntactic sugar around javascript that you can unfold it in your head.
> <element someProp={prop} /> = React.createElement('elment', {someProp: prop}, null)
Its such a simple transformation and adheres to javascript standard behavior. JSX doesn't add anything new, it just adds a way to do something old.
Its a shortcut to 1 transformation and thats it. You can unpack it in your head.
So while I agree with you that it isn't "standard javascript", if you look past the visual differences, there is no difference between JSX and javascript.
This is in stark contrast to the Vue.js (and other) template systems which, while they compile to javascript, the amount of transformations makes it impossible to extend the template system easily without touching the internals of the template engine.
JSX is just syntax, other template systems are entire secondary languages.
> <element someProp={prop} /> = React.createElement('elment', {someProp: prop}, null)
Its such a simple transformation and adheres to javascript standard behavior. JSX doesn't add anything new, it just adds a way to do something old.
Its a shortcut to 1 transformation and thats it. You can unpack it in your head.
So while I agree with you that it isn't "standard javascript", if you look past the visual differences, there is no difference between JSX and javascript.
This is in stark contrast to the Vue.js (and other) template systems which, while they compile to javascript, the amount of transformations makes it impossible to extend the template system easily without touching the internals of the template engine.
JSX is just syntax, other template systems are entire secondary languages.
> Its such a simple transformation and adheres to javascript standard behavior. JSX doesn't add anything new, it just adds a way to do something old.
I don't understand your point, to be honest. A lot of language features are just syntactic sugar for lower-level language functionality. ES6 getter/setters are just syntactic sugar for Object.defineProperty. Does this mean that ES6 and ES5 are the "same"?
No, of course not, but ES6 getter/setters are specified in ECMA-262 and JSX is not, so ES6 gets to be called JavaScript and JSX doesn't. It's really as simple as that.
My point is that because JSX is not JavaScript it then requires a ton of complexity to use it. Whether that complexity is justified is up to each person, but we can't ignore that complexity exists when arguing it vs. alternatives.
I don't understand your point, to be honest. A lot of language features are just syntactic sugar for lower-level language functionality. ES6 getter/setters are just syntactic sugar for Object.defineProperty. Does this mean that ES6 and ES5 are the "same"?
No, of course not, but ES6 getter/setters are specified in ECMA-262 and JSX is not, so ES6 gets to be called JavaScript and JSX doesn't. It's really as simple as that.
My point is that because JSX is not JavaScript it then requires a ton of complexity to use it. Whether that complexity is justified is up to each person, but we can't ignore that complexity exists when arguing it vs. alternatives.
It's literally as complex as transpiling ES6 to ES5.
And although JSX is not in the ECMA-262 spec, it does have a spec, so there's that.
And although JSX is not in the ECMA-262 spec, it does have a spec, so there's that.
Transpiling is complexity. You don't have to transpile if you just use web technologies (JavaScript, HTML, CSS).
Of course it is, but saying it's "a ton of complexity" to use JSX, while not saying the same for transpiling current and future ECMA-262 syntax into what browsers support right now is disingenuous.
No it's not, transpiling future ECMA-262 is not within the scope of this discussion. We are compared browser-native language features JS (non transpiled), HTML, CSS, to non-native features, namely JSX.
I loved how they did that! They actually invited the other experts to review and feedback on their declarations to ensure their work was honest and had integrity. Never seen that before. Have you?
Also I wished it was clear if this doc was updated with Vjs2 or if it's 1.x or what. That's not clear anymore and they need to sort that out or the integrity is lost.. by accident, but still lost.
Also I wished it was clear if this doc was updated with Vjs2 or if it's 1.x or what. That's not clear anymore and they need to sort that out or the integrity is lost.. by accident, but still lost.
my respect for the project grew immensely (because it showed me that they really cared and it was not another "me too because I can and I have my own way of doing things" project).
They openly talk about how they took what was successful in those platforms (React and Angular) and others, then built Vue with that in mind. Plus their goal from what I've heard was to also remove what other platforms did poorly (benefiting from hindsight) and hopefully do those things better by learning from their mistakes.
Nothing about how they said this was done in a manner that was boisterous, just simply leveraging what has been learned from first movers and now they are hoping to pull their own Apple, by making a better product as second (or third or fourth.....) movers in the market. ;)
Nothing about how they said this was done in a manner that was boisterous, just simply leveraging what has been learned from first movers and now they are hoping to pull their own Apple, by making a better product as second (or third or fourth.....) movers in the market. ;)
it uses virtual dom to render and components
https://vuejs.org/v2/guide/comparison.html
It's more that many many frameworks imitate Handlebars, or accept that Handlebars is good enough and it's not worth inventing new syntax.
If it's your opinion, as it is mine, that HTML frameworks should deal with HTML, instead of abstracting it away, then this isn't a bad thing.
If it's your opinion, as it is mine, that HTML frameworks should deal with HTML, instead of abstracting it away, then this isn't a bad thing.
Yes, the tag names are even similar but the performance and simplicity is even better than ng2.
You can use it for a page that isn't a SPA for example.
Pleasure to work in Vue.js framework. Very easy learning curve. Simplicity is the biggest strength of this framework.
I have created few tutorials on Vue.js.
https://m.youtube.com/playlist?list=PLJ6Y8JfXAV-8_2lHNgP1DhC...
I have created few tutorials on Vue.js.
https://m.youtube.com/playlist?list=PLJ6Y8JfXAV-8_2lHNgP1DhC...
So glad this project is gaining more and more traction. Been using it since very early releases, when I was sick of dealing with overly complex front end libraries.
I'm really excited about the scoped slots feature. Finally it's really easy to create components that can be customized by the user from the outside. For example, it's now really easy to create a data table (with features like filters and sort), and with each row showing not only the data text, but also any other feature you might want to embed in it (like attach click listeners to each row, or popup some menu on hover).
I believe there was a way (probably a complicated hacky way) to achieve this previously too, but I never investigated it too much. Now it's really easy.
Kudos to the Vue team for this release!
I believe there was a way (probably a complicated hacky way) to achieve this previously too, but I never investigated it too much. Now it's really easy.
Kudos to the Vue team for this release!
In case someone user Meteor - Vue plays very nice with Meteor and there exists a great integration package [1], which means if you're familiar with Meteor you can write full stack applications with it very easily and quickly with it. The package supports hot module replacement out-of-the-box. It's also dead simple to start using it, if you already have Meteor installed it's a matter of running "npm install" and "meteor".
[1] https://github.com/Akryum/meteor-vue-component
[1] https://github.com/Akryum/meteor-vue-component
I'm looking to move a few projects from Angular 1. What do developers think of migrating to Angular 2 vs Vue for this? I've played with Angular 2 but can't shake the feeling that it's overly complex.
Angular2 has a huge surface area, conceptually. You might need that surface area. But it's daunting. Angular2 also expects you to teleport into a very modern future of tooling and development practices. That said, it's a safe choice...everything you might want to do has been done and complained about on StackOverflow. [wink]
You may want to check out Aurelia too. One of Angulars main devs left the Angular Team because of its direction and build Aurelia the way Angular should have been.
I played with it a bit and what's awesome about it that you just write plain JS most of the time. No weird stuff like JSX and whatever. Docs arn't that great tho
I played with it a bit and what's awesome about it that you just write plain JS most of the time. No weird stuff like JSX and whatever. Docs arn't that great tho
It's worth noting that the developer who split from the Angular team to create Aurelia was also the developer of Durandal, which is quite a nice (and underrated) framework.
Aurelia is a sort of the spiritual successor to Durandal.
Aurelia is a sort of the spiritual successor to Durandal.
Well, it might help if you said why you're looking to move from Angular 1. What problems do you have with it? How many developers are working on the project? Do you use libraries like angular-material? ...
There are a thousand factors why you'd chose one above the other. I would just be very wary of comments like: "Definitely framework X".
There are a thousand factors why you'd chose one above the other. I would just be very wary of comments like: "Definitely framework X".
> Well, it might help if you said why you're looking to move from Angular 1. What problems do you have with it? How many developers are working on the project? Do you use libraries like angular-material? ...
Just that as time goes on Angular 1 is going to fall out of support in general and for popular libraries so it might be best to switch sooner rather than later before we get more entrenched in Angular 1. Switching to another framework wouldn't be a massive undertaking right now but probably would be later. Typescript is a great feature too but you can use this in Angular 1 somewhat as well. Any thoughts?
Just that as time goes on Angular 1 is going to fall out of support in general and for popular libraries so it might be best to switch sooner rather than later before we get more entrenched in Angular 1. Switching to another framework wouldn't be a massive undertaking right now but probably would be later. Typescript is a great feature too but you can use this in Angular 1 somewhat as well. Any thoughts?
Well, they're not that far apart (vue 2 and angular 2).
They're both component based frameworks with a very comparable templating system. So you'll be able to create the same things in more or less the same manner with both frameworks.
The main difference is that angular 2 is a bit more enterprisey. It's a bit more bloated (but also more complete) and if you're a small team with a not too large app, you may find it introduces too much overhead. If you're a larger team with a larger app you'll really benefit from angular 2.
One thing that speaks for angular 2 has is their ngUpgrade module, which allows you to gradually upgrade your angular 1 app, which you may find useful.
There's a (somewhat biased IMO) comparison by vue itself here: https://vuejs.org/v2/guide/comparison.html#Angular-2
The main difference is that angular 2 is a bit more enterprisey. It's a bit more bloated (but also more complete) and if you're a small team with a not too large app, you may find it introduces too much overhead. If you're a larger team with a larger app you'll really benefit from angular 2.
One thing that speaks for angular 2 has is their ngUpgrade module, which allows you to gradually upgrade your angular 1 app, which you may find useful.
There's a (somewhat biased IMO) comparison by vue itself here: https://vuejs.org/v2/guide/comparison.html#Angular-2
Angular 2, not worth it. We made our decision to migrate an old Angular 1 app to Vue.js. Best decision ever.
> Angular 2, not worth it. We made our decision to migrate an old Angular 1 app to Vue.js. Best decision ever.
Can you elaborate? I've used Angular 1 a lot, Angular 2 a little and Vue not at all. What makes Vue better?
Can you elaborate? I've used Angular 1 a lot, Angular 2 a little and Vue not at all. What makes Vue better?
Vue feels very light, and you can use as much or as little as you need. With Angular 2 you really need to dive in, understanding modules, DI, Typescript, components, the various decorators properties, observables, etc. I like Angular 2 personally, but it really is quite heavy.
The upgrade adapter isn't ready for primetime yet from what I gathered.
Can't speak for Vue, but Angular 2 is pretty nice, and the performance benefits are significant. There are some complexities, mainly around AoT compilation, but those are challenges that one would come across if one wanted that anyway.
Can't speak for Vue, but Angular 2 is pretty nice, and the performance benefits are significant. There are some complexities, mainly around AoT compilation, but those are challenges that one would come across if one wanted that anyway.
I still wonder why they moved the events from the constructor to the instance...
Before 2.0:
new Vue({ el: "#el", data: someData, events: { myevent: function(){} } });
after 2.0 :
vm.$on('myevent', function () {})
Before 2.0:
new Vue({ el: "#el", data: someData, events: { myevent: function(){} } });
after 2.0 :
vm.$on('myevent', function () {})
Events in Vue 2 are now supposed to be used only for child -> parent component communication. If your needs are more complex then you're supposed to use Vuex.
I found this guy creating a todo app using all popular js frameworks
https://github.com/tastejs/todomvc/tree/master/examples
including vue.js riot.js react, meteor, angular 1,2 dojo, duel, ember, jquery ....
it's a great way to compare frameworks
https://github.com/tastejs/todomvc/tree/master/examples
including vue.js riot.js react, meteor, angular 1,2 dojo, duel, ember, jquery ....
it's a great way to compare frameworks
I really miss 1.0's inline way of writing javascript anywhere inside the dom (attributes) via {{ execute_raw_js_code() }} as well as the ability to run filters on it. Is there anyway to get them back on Vue 2? I have to admit, this was a major step back for me when upgrading to Vue 2 from Vue 1.
I also really loved the Vue 1's way of handling transitions. Now having them inside it's own wrapper really diminishes the elegance I felt from Vue 1.
Wish there was some ways to get them back instead of having to downgrade.
I also really loved the Vue 1's way of handling transitions. Now having them inside it's own wrapper really diminishes the elegance I felt from Vue 1.
Wish there was some ways to get them back instead of having to downgrade.
I'm currently using (and enjoying) my first Vue project. I have to say the camelcase support for JSX events feels like a step backwards. The `on-` prefix had a nice semantic way of telling you that thing is an event (either DOM or $emit from component). Now there's just this implicit `onFoo` which could be an event, or could be a prop, maybe component will invoke it directly like in React, maybe it will $emit, who knows?
I've been waiting for scoped slots for so long. I've implemented several workarounds since I started using Vue a year ago. Creating a directive to pre-compile a slot template in the child scope in Vue 1, and then once Vue 2 rolled around, making lots of functional components and passing them around. So glad they finally added this.
I've been a long time React and Angular user, but is still sick to implement correctly enough SSR for my projects. And VueJS just did it elegantly ! I must say, thank all React + Angular folks as the pioneer for better CHANGES. This is THE time for us to change. Really.
What is a correctly enough SSR? We use react in most of our projects with server side rendering without any problems at all.
https://github.com/ueno-llc/starter-kit
https://github.com/ueno-llc/starter-kit
I tried to use Vue 2 for a pet project but couldn't get the routing to work. It seems the router was lagging behind in versions and there were no guides on "router 2.0".
Does this version have a routing guide and production ready routing solution? That's pretty important.
Does this version have a routing guide and production ready routing solution? That's pretty important.
We're using Vue and its router in production since 1.x, so I'm not sure where you got that impression...
I would like to know more about your use of Vue and the router in production. Tips/best case guidelines?
If you have a relatively large app and having URLs makes sense, the router is a no brainer.
No real tips; the vue-router documentation is excellent.
If you're coming from Vue 1, the only thing that did confuse me is that the router hooks have changed. The router now listens on `beforeRouteEnter` and `beforeRouteLeave` and these hooks only get triggered once per route change. Therefore, to listen to query changes on a route you need to watch the `$route` object.
No real tips; the vue-router documentation is excellent.
If you're coming from Vue 1, the only thing that did confuse me is that the router hooks have changed. The router now listens on `beforeRouteEnter` and `beforeRouteLeave` and these hooks only get triggered once per route change. Therefore, to listen to query changes on a route you need to watch the `$route` object.
Took less than two seconds to google. https://github.com/vuejs/vue-router
This is the project they were referring to by "2.0". And your two seconds of googling found a Github URL with no documentation, which is what the commenter was lamenting.
http://router.vuejs.org/en/ does appear to be fairly complete however. (linked from the README)
http://router.vuejs.org/en/ does appear to be fairly complete however. (linked from the README)
Are there any migration guides from jQuery to Vue which are noteworthy?
Specifically, I used learning Vue as an opportunity to upgrade a simple jQuery-based SPA (with a PHP backend) to ES6, JS modules and Vue. It was a little hairy to bite off all of that stuff at once, but the Vue community was really helpful. In contrast to more monolithic frameworks I didn't have to port everything at once, and the re-implementation of the bits I did port are sooo much cleaner.
FWIW, there's a highly-rated Vue.js 2/Vuex Udemy course on sale for an impulse price of $14 (normally $190) as I type this. With the caveat that I just bought the course myself, at that price it seems like a useful resource even if you only have a cursory interest in Vue.
https://www.udemy.com/vuejs-2-the-complete-guide/