Hacker News Reader

Comment by anonyfox | Hacker News Reader

As someone who went through the complete frontend hype-trains (jquery, backbone, angular, ember, react, all in production): Vue.js 2.0 with single file components is exactly what everyone looks for desperately.

- performance: faster than react now

- learning curve: a few hours from scratch

- getting started: cli-tool for initial scaffold & configuration

- components: simple .vue files with a <template/>, <script/> and <style/>. Super easy to get going, no need for JSX

- "official" packages for routing, ajax and state management. No wasting of days for choosing every tiny package for days

- vuex 2.0 is one of the cleanest flux implementation i've seen in the last year

... and much more. Give it a try with the full webpack template of the cli tool!

View on HN

I went digging through tons of frameworks for a new company project early this year and chose Aurelia. Vue was a pretty good possibility in my mind, but Aurelia gives me a little more bang for the buck. I also think it's much easier to get going with Aurelia than React or Angular. Since then Aurelia has released a new CLI tool and some other significant updates. It's already fast and the code is predominantly straight JS and web standards so it seems easy to pick up again after not looking at it for a while.

I started reading through the docs and found it very similar to Knockout.js. Is here anyone who used both to tell the advantages of Vue?

FYI, I'm thinking about dropping Knockout because some performance problems I'm having with a very specific use-case.

We are using Knockout in my current work. I am using vue in my spare time. They feel indeed very similar.

Exactly my thought when I tried Vue.js: on the surface, it's knockout with some react-inspired additions that make it faster. I loved being able to pick up Vue.js and make something that just worked in 30 minutes.

https://vuejs.org/guide/comparison.html#Knockout

I've used Knockout before and it's really slow. I also find Vue to be less complex overall in comparison to Knockout.

React with MobX, Vue and Knockout all seem very similar. I am wondering if TypeScript is a first class citizen in either MobX or Vue - in my experience seeing TypeScript everywhere in Angular 2 has been one of that platform's biggest wins.

yep, Vue has an official support for TypeScript as well: https://github.com/vuejs/vue/tree/dev/types

MobX is written in TypeScript: https://github.com/mobxjs/mobx

When I first started looking at Vue last year this was my initial thought too. Overall, I think Vue has more to offer, has a cleaner syntax, and is more enjoyable. Some specific things I like:

- With Vue, you don't have to specify which pieces of your data are 'observable'. The entire data object for each component is reactive.

- Vue's getters/setters mean you can interact with your data really easily, no need to invoke properties as methods

- Directives are more readable. Knockout makes you cram everything into the `data-bind` attribute, whereas Vue splits these out into individual attributes( @click, :class, v-if, etc)

I've used both Knockout and Vue for frontends that needed to render reasonably large amounts of disparate elements with near real-time updates, so I think I can answer this. Knockout is nice but feels closer to jQuery in that it requires a lot more discipline on the behalf of the developer to organise and maintain code. Things like ObservableArrays means dealing with another layer of abstraction; the wonderful thing with Vue is that it's just native JS objects all the way down. It also has a better structured child/parent component model with event flow, not to mention being much faster for rendering. I would also recommend Vue over Knockout.

Isn't Vue.js hype too?

I mean if I look at the GitHub stars it seems pretty hyped to me. (It's between Angular/React and Ember)

It's definitely hype. I'm honestly surprised nobody seems to be complaining about it breaking their noscript, accessibility, SEO, etc.

I read a writing about how SEO isn't an issue with SPAs. (can't find it at the moment)

As far as I know, all major search engines are evaluating JavaScript client-side and index the resulting html, only a chinese one had problems with SPAs.

There was even a site from Google, where you could enter a URL and see how Google sees the page.

Also, with Vue 2.0 we have the option of SSR.

It's still an issue. Let me show you an example.

Here's a website that's an SPA https://preactjs.com

I don't have an exact page count, but I was able to find 15 pages from browsing around.

Here's how many pages various search engines have indexed using the query "site:preactjs.com"

Google: 17 Bing: 6 Yahoo: 6 Baidu: 1

One of the Google results is an error page, but it presumably can't be de-indexed automatically due to there not yet being a way of declaring a 404-equivalent in SPAs.

I've also read (I can't recall where) that Google has a latency of a few days when it comes to indexing SPAs compared to server-rendered apps. This may not be a problem for you, but it's worth knowing about.

Interesting, thanks.

I think Jason Miller, the Preact developer, re-tweetet the article about SEO & SPAs a few days ago.

But, because of progressive enhancement, I would using SSR on my next project anyways.

Is that not what sitemaps are for?

That seems like an example of a SPA that should really be a static site. Aside from it being the library's main page, why would you even need to implement this with any front end frameworks? I believe the parent post was referencing how companies usually have a static site for marketing/SEO, and the backend application is a SPA. This would effectively remove the need for SEO on an app that requires authentication anyways.

In that context, I agree. If your app doesn't need to be crawled or otherwise scraped, worrying about server-side rendering is just going to hold you back.

But there are public websites with a high degree of interactivity (such as social networks, or ecommerce sites) for which SEO is a huge concern.

https://support.google.com/webmasters/answer/6066468?hl=en

Yeah there's a lot of FUD about how google indexer works, needlessly IMO

I don't think it is. I've been closely keeping an eye on Vue since its first release, and it has really matured quite well and steadily since then. I like to reference Vue with the Crystal[1] programming language, which has looked closely on mainstream programming languages and adopted the good parts of them, like Go's concurrency model, Node's asynchronous I/O, Ruby's clean & straight-forward syntax and object-orientation model and the performance and interoperability with C.

Similar to Crystal, Vue has looked at the other frameworks and adopted the good parts from them. I personally don't think the hype is anything but a result of hard work and a genuinely good framework.

[1]: https://crystal-lang.org/

>I don't think it is.

You probably want to give it a bit more time. It takes 1 or 2 years after a js framework goes mainstream for the disillusionment and disappointment to set in. We are still in the Vue.js honeymoon phase.

This is because it takes about one or two years before all the hordes of idiots to abandon the last ship they sank and come swimming full speed towards a new ship to sink.

The unfortunate part is that it's moments like this (when a framework makes it into the spotlight in a big way like this) that those hordes begin their swim.

Evan is an excellent developer, and it won't by through his volition that Vue gets ruined.

Could you expand more on how these hordes of idiots sinks framework by using it? I've never come across a theory about this that's quite so tantalizingly bad before and I'd love you to expound further.

Can't speak for the author of the post you're replying to, but I'd wager it refers to the bad actors you find on GitHub and such where they contribute significant negative equity to an ecosystem.

It's easier to illustrate by walking through an example timeline:

1. Framework X is created based on the vision of its founder

2. Lots of people begin to use it

3. X gets better and better (user feedback + excitement of the project's success)

4. X becomes super popular and attracts people from other frameworks

5. More and more contributors begin committing code (helpful, but hard to manage beyond a certain volume), and entropy increases - more bugs start getting through (think Rails, where there were loads of security and data loss bugs in the span of single years)

6. People bring their ideas with them, which is helpful at times, but which also begins to dilute the X creator's vision and replace it with a democratic vision (sometimes good, sometimes bad)

7. Social pressure causes the creator of X to begin changing his vision to accommodate the community

The apex of quality is at # 4, and that's the point we're approaching now. Also worth noting is that this timeline isn't always followed exactly. Take Django, for instance. It was able to keep up with community demands without caving in to too many wild requests, and it managed entropy by keeping the number of core committers to a minimum for many years.

> I've never come across a theory about this that's quite so tantalizingly bad before

With some projects, it's both obvious and simple. Similar to eternal summer. Democracy means that all of us get to be dumber than any of us.

You most likely meant "Eternal September".

Yes. But longer. Because it starts even before the kids get back to school...

No, what happens is a new framework comes out that fixes the complexity problems of the previous popular framework, but ignores why that complexity existed in the first place.

Once the new framework gains popularity the limitations caused by ignoring complexity start to surface and so the framework has to add features to handle them, creating complexity of its own.

Then the cycle repeats itself.

See my explanation below my OP. Your comment is correct, but these complexities should not be solved in the framework, lest we forget the vision that drove the creation of this framework in the first place, providing an obstruction layer that doesn't solve all problems at all layers.

Keep in mind Vue isn't backed by Facebook or Google, so it'll take longer for hype to set in as Evan You can't market it heavily or organize large conferences by himself.

Personally it's Angular 2.0 for me. I'm a big fan of Angular 1.0 but can't stand how complex it has become. I want to be able to start using a framework in a matter of hours, not weeks. Most of Angular 2 complexity is unecessary and I write large SPAs ,not toys, but I don't like the noise. I use Go and Python on the server, I don't want to have to manage a Java style application on the client, because that's what it is another version of GWT with Typescript in place of Java.

I highly recommend the angular cli tool. In 2 minutes you have a webpack setup with bootstrap that hot reloads your code . you can even proxy API calls to your real web server. Deploying consists of copying the dist folder . With tree shaking the footprint for angular 2 drops significantly

If VueJS 2 supports JSX, does that mean Vue and stateless React are now largely interchangeable with minimal re-write?

I've written a express renderer library so you can use vue component files without webpack. Just using res.render()

https://github.com/danmademe/express-vue

any good resources that goes in depth with features and best practices you can share with us? vue2 specifically?

Reply on news.ycombinator.com