Saul: “How’s it going?”
History.js: where and when all started
Netscape wanted a lightweight interpreted language that would complement Java by appealing to nonprofessional programmers
… and some of the weird quirks of the language continues to stick today like the absence of real inheritance (instead, see “object delegation”), weird bugs like typeof null === “object” // true, the choice of going full IEEE 754 0.1 + 0.2 === 0.3 // false etc…
The absence of a standard framework
Although extremely powerful, Node has a community problem: there’s not a Django-like or a Ruby-on-Rails-like framework that is considered standard. Some might say that Express is the de-facto web framework to use in Node, but it is highly unopinionated and doesn’t solve common boilerplate and repetitive tasks. Community-wise, Node looks much more like the PHP ecosystem with all its Laravel, Phalcon and Yii’s alike.
While some great efforts are put into opinionated frameworks like LoopBack, Sails and Kraken, the communities are quite sparse (although very much active).
we are in the middle of a pivoting period, where everything looks old, there are new things coming out, but nothing is really ready yet
How long can it last?
The surface is already cracking: the recent blog posts about what went wrong with Meteor in the state of Meteor 1 by Sacha Greif and a forum thread by MDG’s CEO Geoff Schmidt are proof that developers do need an integrated solution, or at least a clear path of when, where and how a tool can integrate with existing libraries.
Said it before and will repeat it. Meteor forgets what made them big. Those ten (or even hundred) thousand developers that use Meteor for fun or in small projects.
MDG wants big companies to switch to Meteor as it needs to pay back the VC’s that huge money they invested. Us small chicken won’t help pay the debts back as all we use up is free hosting on Meteor.com instead of paying for Galaxy.
I’m still really confused about the message being given by Geoff [Schmidt, MDG’s CEO].
Initially I thought it was a full 180, but the wording is too unsure. It sounds like he’s saying we’re recommending Blaze until we can write a better guide with React and/or Angular2. It says nothing about what they’re going to be working on.
Also, as Sacha Greif states (note to self: when writing an honest piece about a project of mine, do not drop “what went wrong” at the end if I want folks to keep using it):
I believe some of Meteor’s early choices may have ended up handicapping it. For example, Meteor’s focus on real-time applications makes them a lot easier to build compared to any other platform out there. But it does also come at the cost of hidden complexity, and potential performance problems down the road.
Sacha Greif, The State Of Meteor Part 1: what went wrong
Basically, global-scoping almost everything and the problem with figuring out what the heck is happening inside that .meteor/folder. Some hard-core developers are worried too:
To be honest I’m having problems to understand MDG strategy for the future. I work with Meteor platform since mid 2014 and I’m pretty happy with what I have now.
[…] Is there a future in the platform? I’m worried, but I keep coding :)
To summarize: something is rotten in the state of Meteor. Will it recover? It’s too soon to know but it ain’t going anywhere in the near future: the project has a great traction on GitHub and was backed by some very smart people down at Andreessen Horowitz so I guess that they are addressing those issues as we write.
Ultimately, the problem is that by choosing React [or any JS framework, NDR] (and inherently JSX), you’ve unwittingly opted into a confusing nest of build tools, boilerplate, linters, & time-sinks to deal with before you ever get to create anything.
When a generator is good solution for repetitious code, a better solution is to abstract it into a simpler API.
Being a JS developer right now is like being one of the suitors waiting for Penelope to finish weaving Odysseus’s shroud, being constantly reminded that yes, 1.x is indeed limited and 1.y will change everything so please stick with us a little bit longer.
I mean, there is no framework right now that is really production-ready (except for React, but, again… React 1.x is coming soon, is it?). Change is good, change is healthy, although having to re-learn everything from scratch again (yes, Angular, I’m talking to you) can be difficult for big projects that would like to stay up-to-date.
What framework to use for, like, NOW?
My feeling right now between what framework to use for a huge project is somewhat mixed.
Meteor has unanswered questions that will hopefully be answered with the 1.3 release (although I’m not ready to bet on it). A lot of the packages (oh, by the way, it seems that Atmosphere will be dropped for npm) are written for Blaze and not even the core-community is certain whether or not to drop everything for React or continue to support multiple view-frameworks. My advice is to skip the turn and see what’s coming.
Angular 2 is almost there although not there yet. It’s in beta and there is no release date for the final version. Still, whether or not the old 1.x crowd that has switched to React will come back for 2.0 is not clear yet. My guess is, they will. Angular 2 is written with all JS flaws and problems in mind. Case and point: TypeScript addresses the quirks of ES5 vs ES6 vs browser compatibility, RxJS gives a structure to data-streams, its whole structure gives a solid foundation to code on etc…
React sits in between, and, as they writes:
React makes no assumptions about the rest of your technology stack, it’s easy to try it out on a small feature in an existing project.
Kent C. Dodds wrote on July 2015:
Here’s the real kicker: If I had the freedom and leisure to build a major product from ground zero (like if I were to do a startup or something), I would probably go with React. Seriously.
I think some people in the Angular community are going to come at me with pitchforks right now. But as much as I like Angular 1, I think React is better.
Will Angular 2 be better than React? I think it might, but that remains to be seen. But it’s the principles and concepts behind React that I really like.
By the way, Kent is that Kent that hosts the Angular-Air podcast, so I feel that his views have somewhat more weight (see reputation) than other’s. Moreover:
A long time angular user but I’d agree and go React.
The way I look at it is that you can use React today.
Angular 2 is a work in progress. Angular 2 is adopting learnings from React which is great but it must impact development as plans have changed.
But, keep in mind that in July 2015 the dust that ng-europecreated back in October 2014 had not yet settled, Angular2 was still in pre-alpha and no release date was announced (not even at the Angular Connect conference in London back in October 2015). Although now Angular2 is in a solid beta (again, sarcasm) I agree with Jeff Whelpley when he writes:
[…] as soon as Angular 2 is closer to full release I will use Angular 2 for every nearly every new project.
That doesn’t mean Angular 2 will be definitively “better”. It’s more like leveling the playing field and the choice between the two will end up being one much more of personal taste and specific project requirements (assuming the performance characteristics and features will be nearly the same which it appears will be true).
[…] So, the stuff typically associated with React is likely going to appeal more to devs that have their foundation in functional programming languages while Angular 2 is likely going to appeal to more to devs that have their foundation in OOP-based languages like Java and .NET.
Kent recently added:
So I actually talked about my feelings about Angular 2 […].
Basically, Angular 2 is amazing. There’s no denying that. And I know that there are some things we don’t know about Angular 2 yet that are going to be even more incredible. The challenge is time.
I just don’t have time to do everything under the sun I’d like to do. So I’ve decided to go pretty much all React.
And, as always, keep in mind this great piece of advice:
[…] it is a never ending battle if you want to try and work on the “best” and hottest framework.
It is much better IMO (and more productive) if you instead just pick one that makes sense (Angular 2, React and Aurelia are all fine choices) and then bring the ideas from other frameworks into what you are working on.
I think in general people tend to think they need to drop what they are doing and move on when in reality all they need to do is innovate where they are already at. So, just choose one and make it work.
Right, choose one, make it work, and may the code be with you. Personally, I’ve always been drawn to the Angular side of the force and I think that I’ll stick with it for big projects. For small projects I’ll experiment other frameworks.