If you love super fast virtual DOM but don't want all the stuff that comes with react (including the learning curve), Vue's awesome. The same site has a bunch of other Vue tutes: http://coligo.io

1. Vue uses the actual DOM not virtual DOM like react

2. BOTH react and Vue can be learnt in a day

3. BOTH can seem daunting when you're making production app (Vuex, redux, webpack, Vue-router, react-router...)

So, I don't not agree with 'learning curve' that's thrown at React. Both Vue and React are amazing. If you want to use them properly, you as a developer has to spend the time to learn.

> 1. Vue uses the actual DOM not virtual DOM like react

Facebook really should have named the Virtual DOM something different to avoid this confusion. The "Virtual DOM" is not an alternative to the DOM (which would be impossible), it is just a string diffing algorithm to minimize the number of DOM mutations required.

Based on the down-votes I'm assuming most React users don't actually know what the virtual DOM is...

"Something inevitably has to put shit in to the DOM." - 91bananas 2015

1. My understanding is that Vue consolidates mutations in memory and applies the consolidated results resulting in less DOM churn.

2 and 3 are entirely subjective.

React can be learned in a day. It's really simple. The tooling around it can get weird but honestly I think most people are exaggerating. It's fine.

I second that.

I learnt it/redux/react-router on Saturday.

What resources did you use?

I grabbed a boilerplate[1] and read through it to produce a basic CRUD app for tracking mini libraries. mostly follow where the data flows through, and look up details on anything that looks like it could be doing a lot of stuff.

the gyst is, you have your state [Redux store] which is updated through reducer functions. Each reducer tracks the state for its part of the system, and is called with an action name+data when the state should change.

actions are called through a function, dispatch. it is typical to run a function as it's input, dispatch(makeAction()) where makeAction does things like make a REST request.

the state object is passed into React components as state and properties, which you can use for rendering HTML. to receive them, you register what you want from the reducers, and it is automagically passed in, and you can pass properties down to child components as HTML looking markup.

when something happens, like a user types into a text box, you call dispatch with the new text to be added to the state, which then gets reduced and passed into the next render call of the component, to update what's shown in the text box.

specific to that codebase, containers are top level components.

routing is done as a React component, where you render a tree of possible routes, pulling out variables as you go, to feed into the component/container leaves, and the matching route is rendered.

[1] https://github.com/choonkending/react-webpack-node [2] https://github.com/jhedin/little-libraries

Not the OP, but I used egghead.io (subscription version) - the Redux stuff is completely free though and it's from the author of Redux himself.

Between the egghead videos, the docs on the redux site itself, and looking at a couple boilerplate projects, it really didn't take long to grasp it. It will take you even shorter if you are aware of functional programming concepts such as reducers, pure functions, etc.

The hard parts always figuring out what goes in the store and what you should just handle in your presentational components

Just the tutorial on their github page :)

I had a look at some VueJS examples and the first thing I saw was this:

    <input type="radio"
      name="branch"
      :id="branch"
      :value="branch"
      v-model="currentBranch">
    <label :for="branch">{{branch}}</label>

I'm using React to avoid having to use a markup DSL (á la Angular), not because of the Virtual DOM. That's just a bonus.

Yeah, that's exactly what made me turn around from using Vue as well

React itself is already pretty simple if you ignore all the extraneous tooling. The core API is just about a dozen lifecycle methods.

That extraneous tooling killed React for me. React itself is simple and easy, I agree with that. But getting things wired up so that you can develop a real application? I think I lost a good day or two on it. Even after I was set up, honestly there were a lot of tweaks left such that I didn't really get to where I wanted to be. Also I can't really see where things might break down in between. It's enough to be frustrated with the code itself, let alone getting bogged down in a long, incomprehensible path along the build pipeline.

I've always thought of React itself as just one step up from jQuery. You don't need to use a router or flux to get use out of it.

You can't really code in React professionally if you ignore all the tooling around it, the pipelines , the JSX, the flux/redux/... and all that stuffs. It's like saying "C is pretty simple if you ignore gcc macros,make, autoconf, automake, autogen, pkg-config, ld , and all that stuff". You cant. All these dependencies are necessary and managing them constitute at least half the amount of time spent working with C. Same thing with React.

So you pretty much end up with the same level of complexity as more complicated solutions in the real world context.

Haven't ignored JSX, but other than that, I use React in a professional context with the same tooling I use for jQuery.

If you ignore the tooling, then you can't use JSX. If you can't use JSX, then I don't think React is that useful.

have you looked into hyperscript and the hyperscript-helpers? there are versions that work with react.

And if you like pure js and something faster than Vue (by 25%) and smaller than Vue (by 80%), try domvm [1] (15kb with view core, router, isomorphism and mutation observers).

Disclaimer: I'm the author.

[1] https://github.com/leeoniya/domvm

Another very good resource for learning VueJS is Laracasts' Learning Vue 1.0 - https://laracasts.com/series/learning-vue-step-by-step

Edit: Heroku instance should be up now :)

The Heroku instance is currently overwhelmed with all the traffic. You can download the code from the GitHub repository here: https://github.com/coligo-io/real-time-analytics-node-socket...

and run it using: node app.js

What is the point in preferring Socket.io to WebSockets in 2016?

- Built in reconnection.

- Events / actions as main abstraction.

- Support for degradation for old devices, browsers, corporate networks.

- WebSocket is not very good at multiplexing. One discrete TCP connection per socket (opposite direction of what HTTP/2 is going)

- Binary support inside JSON (`Buffer` etc)

Plus, all of this is requires support on the server end as well as the client.

A lot of people look at SocketIO as a client-side only library, but it's not. It has connection implementors written on the server side to support things like multiplexing over one channel.

i actually went through this debate a few days ago when deciding what to use for realtine updates on our new platform. I had previously used socket.io but decided I'd try just using straight websockets and not bothering backporting realtine updates to IE9. Really great decision IMO. The basic Websocket API is actually really easy to use. i got everything up and running in less than a day, the server is less than 100 lines, and the client side code is about 50 lines and completely resuable and DRY wherever i need realtime updates. Compare this to the 100kb (minified) and all sorts of boilerplate you have to write for socket.io, so in my opinion you're better off with straight WebSockets these days.

See this: https://gist.github.com/zeusdeux/5491cff541fb4ac4c142 I myself prefer the extra 100kb if I receive in exchange a more robust client/server architecture with browser fallback.

That link mentions that it's both a server and a client, which made me realize i didn't mention what i used server side. I used https://github.com/sitegui/nodejs-websocket/blob/master/READ... which is extremely easy to set up and use. i don't doubt the value of socket.io but I for my purposes it was not optimal.

> and the client side code is about 50 lines and completely resuable and DRY

Were you able to implement auto-reconnect with backoff? That's one of the most important features that something like Socket.io gives you.

If you don't need fallback to HTTP, there are some alternative libraries that handle auto reconnect for pure WebSockets:

https://github.com/fanout/websockhop

https://github.com/joewalnes/reconnecting-websocket

Also, if your traffic is basically one-way like in this example, don't forget Server-Sent Events, which are auto-reconnecting and well supported.

Right now just a 3 time retry with hard coded delay between each one.

i recently made a messaging app something like appear.in using websockets in less than a day. Just added nodejs cluster support to it. Kind of easy to learn and easy set up made me love websockets.

Isn't graceful degradation (in support of older browsers) the main feature of Socket.io?

Does anyone really care about IE 9 any more, though?

It's also important to note that you don't just need browser support. You also need support in every web appliance that the request passes through.

It's really common for web sockets not to work through corporate content filters and old load balancers.

It really depends on your target audience who will be using your application.

If you can block them (ie: the user needs to login), you don't need to wrory.

Apparently they make up ~7% of internet users. So my guess is, yes.

> Does anyone really care about IE 9 any more, though?

Not Microsoft. It's unsupported as of 2 months ago.

So - for a large site with say 25,000 average concurrents peaking at 250,000 once in a while, how much computing power on heroku or AWS would I need to run this setup?

the main feature of Socket.io