I think that a lot of people are missing out.
I also feel like a lot of genuinely exciting projects get drowned out by the noise created by well-funded mediocre projects.
There is a problem in society now whereby successful (sometimes well-deserving) people are helping their friends too much. I have seen really poor quality projects (with 0 growth) keep receiving funding year after year because the CEO was friends with the investor.
The marketing noise created by these mediocre projects prevents a lot of quality projects from reaching the awareness of consumers.
I often wish that all newly minted tech millionaires would just keep their money to themselves and go on a perpetual holiday to the Bahamas instead of using their money to pollute the market with poor quality projects/companies.
Funding isn't necessarily evil though, funding the wrong project is (even though it is unintentional).
From a development efficiency perspective, Famous is not as good as Angular or React. From a rendering perspective, it's not as good as three.js. It's not yet a leading tool. Jack of all trades, master of none. Maybe it will make more sense when VR platforms become mainstream.
What was released today was a rewrite of the Famous core engine, so you can't really compare it to Angular or React. Three.js is a far better comparison, though the two have different specialties since Famous isn't trying to be pure WebGL.
The Famous team is working on a framework that will interface with their core engine, making things far cleaner at the application level while facilitating less painful integration. Comparing that to various client-side frameworks will definitely make sense.
To expand on this, Famous's Node class [0] is rather like a DOM node, except far more powerful. You could imagine a React component that renders a tree of virtual Nodes, diffs that with an existing tree, and transitions properties accordingly. But that will be built on Famous, just like react-canvas [1] needed the canvas API to exist. Baby steps.
I think that pulling the core out into a separate engine is definitely the right direction and it will be interesting to see what framework they come up with. It definitely needs a clean slate - The Famous/Angular stuff looked promising but it came across as a bit bulky.
Maybe if he tried to learn some of these other tools which he currently 'has no time for' - He would realize quickly that they pay for themselves in time saved.
I guess it's probably more of a sentimental thing for him though.
Overall, JavaScript is a great language. I don't find the prototype-based approach to OOP any less intuitive than the class-based approach. I much prefer it in fact.
It just so happens that the prototype approach didn't catch on early enough. Developers are now just really set in their ways and are rather pretend that JavaScript is not a true OO language.
I feel that the addition of a 'class' concept to ES6 adds no value to the language itself, but I think it was probably a good decision anyway - Because JavaScript is more flexible and adaptable than the minds of most people - It might as well use that to its advantage.
Unlike the stubborn developers who refuse to learn about prototype inheritance, JavaScript is capable of change.
Some apps have lower profit margins than others. Also some companies need to be able to integrate with their realtime channels on the backend (E.g. for doing custom realtime analytics, integrating with third-party services, applying transformations/filtering to messages in realtime, capturing certain messages for storing in your database, launching various realtime-based background tasks, etc... You do lose a lot of flexibility by going with a service like Pusher. Though it is well designed and very convenient.)
It really depends on a lot of things such as how often users send messages on average and what kinds of messages (JSON or plain text?). The latest version of SocketCluster can handle 25000 concurrent users per CPU core each sending a JSON message every 6 seconds so the 50K number does match my own benchmarks if you assume that each user sends a JSON message every 12 seconds on average.
SocketCluster's API is similar to that of Pusher so it can be a good self-hosted alternative: http://socketcluster.io/ - It's also designed with scalability in mind. You do have to manage presence yourself though but that shouldn't be too difficult (You can keep track of user presence in your own database - That could actually be an advantage since you can go ahead and use that presence data easily on your back-end to do other stuff - Easy to integrate).
We're currently working with a couple of fast growing startups so it's getting traction (still early adopter stage though). We'll be announcing our native iOS client near the end of this week. (disclosure: I'm the main author)
Really great news. I guess io.js fulfilled its purpose of shifting control of Node.js away from Joyent and giving it the vitality it needs to remain a leading backend technology.
"It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away."
Great quote - It reminds me of the story of when Michelangelo unveiled the statue of David, someone asked him how he managed to create such a masterpiece and Michelangelo answered "It was simple, I just chipped away all the rock that wasn't David".
I don't think reduction only leads to perfection. If it would be, then our starting point must always be the right one. But in practice you start somewhere, reduce, move forward, add stuff, move sideways, try out and test. Sometimes you need to add stuff to make it clearer to your users.
It's as though ad-supported companies are advertising each other to keep the money flowing because they can't get any outside money.