I am amazed by how the article attempts to look forward to what the future will hold with JavaScript frameworks... and yet seems to be completely both dismiss or misunderstand (perhaps willfully) why previous frameworks have succeeded.
jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not attempt to be a fundamental ui framework like those guys, it didn't try to be full featured, it didn't try to change javascript to look like another language and didn't try to shift the paradigm of the front end development world.
Silly question - why are is everybody talking about jQuery in the past tense and why are you saying it "did not succeed"?
It just got a beta release of a major version less than a week ago, it's a core part of Bootstrap, which just about anyone building webapps has used at some point, and depending on whose statistics you look at[1], powers a frankly absurd number of sites, including things everyone's heard of like Microsoft and Yahoo and Amazon.
That's the opposite of a has-been thing that did not succeed in my book.
I think you've misread the parent. S/he isn't insinuating that jQuery didn't succeed, but that it (has) succeeded because of a set of reasons which are not part of the modus operandi of the teams behind a lot of modern UI frameworks.
Doesn't really scale to larger projects. Managing application and UI state becomes too cumbersome.
With that said the new things are still very rough, I agree, but they will make our lives easier after it all settles down. It's already beginning to settle down with React becoming semi-standard.
Large projects are never simple and fun. Blaming it on tools is too often just scapegoating.
Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.
I disagree. When designed correctly, large projects are simple to work on individual features and only complex when observed in aggregate as as complete system.
> Chasing a magic bullet can temporarily make it look like you're avoiding the problems of large projects, because when you're constantly switching frameworks you never actually reach the point of having built something large enough.
I never alluded to scrapping or restarting projects to get on the latest framework so not sure where this comment came from. I've build large systems with "jQuery", large systems with React and Flux. The latter was simpler to work on, more fun, and suited the needs of the client.
I didn't mean to imply that you personally are in the habit of restarting projects on new frameworks. But I've certainly seen it happen a lot.
Deciding on a framework for a project takes understanding of both the application domain and the tools. When both are lacking, framework hopping happens.
I'd recommend experimenting with one or the other. If you know the domain, feel free to experiment with tools. If you don't know the domain, it's a double hazard to try to learn a new framework at the same time even though it might superficially look like a great fit.
Its success has nothing to do with looking in the other direction or not redefining Javascript: it solved a problem that a lot of Javascript developers were struggling with.
Now what's really fascinating to me now is that while one can safely say jQuery created a revolution in the Javascript world when it came out, it is today widely looked as a smell and avoided as much as possible in favor or frameworks that modify the model instead of the UI.
And this quick rise to success and fall to obscurity could very well happen to the successful frameworks we are currently using today (including React).
That need was filled by Prototype.js before jQuery. I remember the times when Rails defaulted to Prototype (author was a member of Rails core team, iirc). I also remember when we still had to choose between the two for the new project and I was unhappy if the choice was Prototype. So they both solved the problem, but jQuery's solution was more focused and way more elegant.
thing about prototype is it fundamentally changed how you dealt with javascript.
jquery was just easy dom selection and manipulation, easy ajax, and easy events... you could drop it into any project and it didnt really proscribe anything else...
I agree whole heartedly thats what i am getting at... jQuery succeeded not by trying to be everything but by trying to solve a real straightforward common issue that affects big projects and small projects, super senior developers and junior developers...
I am not suggesting we go back to jquery, i am suggesting that the next really successful widespread framework is going to get adopting by solving a specific widespread problem in a way that appears simple to the consuming developer...
as for jquerys run, it had the best run of any javascript framework in history, by a wide margin... and it really got supplanted not by other frameworks, or even by just losing popularity... it was so successful that it drove all the modern browsers to adopt its api and build it natively into the browser engine...
When a developer starts a new javascript project he/she is stuck with the task of choosing from an array of frameworks, backends, libraries, bundlers, etc.
Also, like jQuery, Meteor is doing something in the opposite direction as all of these other frameworks. Rather than being just one piece of the pie and leaving the rest up to the developer, it simplifies development end-to-end (in theory).
If this is true then no wonder meteor hasn't gained the popularity they were hoping for. Webforms just tries to put this layer of abstraction over the web, which severely limits its flexibility, and means you are developing against webworms as opposed to the web itself. I know some people and companies are willing to make that trade off because they want the rapid development benefits, but I think the majority of experienced developers understand the long-term drawbacks to this scenario.
re: popularity of jquery... jquery makes it easier for you to interact with the DOM. WebForms (and maybe meteor? I don't know) makes it HARDER to interact with the DOM.
I wouldn't say that jQuery is something that should be avoided. It depends on your current experience in JavaScript. I remember that our designer at a former company was preparing the HTML markup and CSS styles for us (mainly JavaScript developers) and he was comfortable using jQuery for prototyping animations and other stuff.
The more I learned about frontend technologies the more I started to realize where it makes sense to use jQuery and where not. With increasing knowledge one starts to think more about optimizing code and reducing the amount of libraries used etc. At the current company I'm working now, we also had use cases where we had to use native JavaScript due to some restrictions.
All in all, we still have a fair usage of jQuery and I honestly don't see anything wrong with that.
>> Its success has nothing to do with looking in the other direction or not redefining Javascript: it solved a problem that a lot of Javascript developers were struggling with.
I agree with this completely.
Worth noting: for jQuery, the solution was aligned with the landscape of the time. Javascript support was a mess. Vendor implementation and feature support varied. A key benefit provided by jQuery was easy, performant 'write-once' code - the library provided an abstraction over often non-trivial issues.
Parallels can be drawn to the issues that the current generation of frameworks are oriented around. As upcoming browser features stabilise and become commonplace (i.e. web components, web workers etc), I think that the popular frameworks will consequently and inevitably evolve.
well said. another important thing to remember is when jQuery came about interfacing with the DOM was really messy across browsers. Ajax queries as well. simplifying those, in my opinion, the killer features of jQuery at the time.
Interfacing with the DOM was not even something that dojo, mootools etc were doing at the time. At least that part wasn't as obvious/easy in those frameworks.
The big change I experienced with Jquery is that it operates on sets of elements. It eliminated most guards and loops I'd been accustomed to when dealing with the DOM.
+1. Meteor should try to optimize their build time (for example, when I just changed one JS file, there's no point to spend more than 20 seconds to reload a simple page) and be frontend agnostic. The main thing I like Meteor (and also why I'm still sticking around) is how it manages data and the DDP stuff. Never a fan of Blaze, but certainly not sure about this "future vision".
Frameworks succeed for diffrent reasons. I am guessing your definition of success is being widespread.
Of course, having to swap out both your front and back end or start a new app from scratch to take advantage will limit the number of applications for it.
I said more in the other thread, but I'll leave another note in this one.
What I think Meteor has the most going for them is the ultimate UX experience for the developer. If they really hone in on making it enjoyable, and dare I say fun to work on product... then they've won in my book.
Meteor has given me that feeling thus far, and given the new trends in the community I am sure they are moving in the right direction. I've spoken with the guys there and they are carefully reviewing what the best routes are to take that creates the best experience.
Meteor is not just a vision, it's a real experience you can tap into right now that benefits a very powerful suite of tools to get up and running. We have an enterprise app built with it and it's going great. Yes, it'll bite you in the ass if you don't learn how things work (pub/sub/mergebox/reactivity) but just dive in a little and you'll see it's just a library composed of other libraries that are well documented and easy to learn. It's all really quite simple really. The beauty and evil word "magic", is how they all play well with each other.
React is probably a better choice than Blaze at this point, even for the pure fact that it allows Meteor to not worry about the view and focus on the overall UX experience of the developer above all else.
I couldn't agree more, it's a god send not to have to wade through documentation and work around a hundred errors while you set everything up; before you've written any code. The freedom to iterate on new ideas quickly that a NoSQL database gives you is rather nice too (even if that's a terrible reason to choose a performance-critical part of your stack).
I'm sure all this magic comes with a penalty further down the line so I'll let you know whether it was worth it when I get there...
I completely agree and I'm excited about this vision for Meteor. The dream would be to have a go-to choice with formidable standards that Just Works.
Personally, what I wish existed was a full-stack framework AND dev ops built with the "best" open source libraries. I'm fine with not having my favorite X if it means having a set of well supported, highly performant with lots of documentation and training materials services that work perfectly together.
Starting a new project the "right way" is a pain right now. Again, I would gladly trade my favorite libraries/tools for a great full-stack solution (including dev ops, continuous integration, roll-back deployment, scalable servers, etc etc.)
Software engineering is still a new field and it's hard to establish "best ways of doing things", but I'm wondering if it'll start converging to "The Proper Way". Similar to how building houses is pretty straightforward. Of course, part of the reason that it's hard to do in software engineering is because technology keep changing so fast.. I.e. Tools from a few years ago will most likely not play well with VR stuff.
I'd strongly disagree with the idea that we need or even want one ring to rule them all. Remember different frameworks are designed to solve different problems in different ways [1][2]. Anyone who has dug deep enough into a framework or tool-set will be able to write out a very long list of unique quarks, gotchas, caveats, hidden strengths/weaknesses, and what have you. It's those differences that will make one framework more valuable in a given domain then the other, we want that because there are many, many, domains to conquer in software engineering.
IMO, innovation stops when we believe we've found "the best way of doing things". I'm all excited to check out Meteor too, but I'm not getting in line at the Apple store, I mean full-stack framework store, on the day of release to be a guinea pig for the "new best thing" at my personal expense (time).
What if we replace "best" with "good enough for most common uses"? Most of the roads and bridges we build today aren't pinnacles of innovation, they're just good enough that we don't bother optimizing them much more. With how young the software engineering field is I don't think we'll get to this point in the near future, but part of me looks forward to a day when we have widely accepted standard solutions to common problems that don't go out of style for decades.
I think there is a difference between "just good enough" and "has reached maximum efficiency". I think a lot of people want to settle at the first one, yet I see the second one nowhere in sight.
> Similar to how building houses is pretty straightforward.
Because we've been doing it for decades. The railroad wasn't straightforward to build when it first started. After a century there sure are lessons learnt. The conventional apartment building, or the conventional sky scraper, are not in the same league as some mega construction projects out there, so it's not always "straightforward".
Even though most startups and enterprises are solving very similar basic problems, the field itself is still quite young and open to innovation. In a century, perhaps building fairly complex social network with fairly high traffic might be as straightforward as setting up a Medium account, but we're not there. Like you said, there are many issues that are not easy problems to solve yet: dev ops, CI, etc.
GraphQL and Relay may be the answer but it's too young to make that switch now and Meteor is solving that exact problem. Meteor has the momentum and community to take it further. Maybe it actually adopts the GraphQL standard and unifies it into the ultimate dev UX experience.
Yeah, I went down the Relay/GraphQL rabbit hole for a good 1.5 months last year, but unfortunately there is a tremendous amount of work to set up GraphQL servers to even get your data out to Relay, and it is not real-time at the moment (although the 'community' appears to be work on it. I so wish Meteor would provide a drop-in module for just the DDP, I don't even care if its Mongo, their real-time subscription works.
You're not in any way tied to Galaxy. Meteor is just a node process under the hood, so you can run it (and likewise your MongoDB) wherever you want. Tools like Meteor Up make it very easy to do so on your choice of VM.
What that says about MDG's business model is less clear.
I predict that Meteor will won't go anywhere in 2016. I know this sounds negative so I'll try to explain. The surface area of Meteor is still too large. Keep in mind this is a venture backed company, people are getting big salaries to work on a framework. Look at what it's led to: in house tools like Blaze which even the creators are already tired of. At best Meteor will be 90% cannibalized and replaced with open source tools (as this blog post is implying), and sit properly in the same place as other CMSes, which inherently don't get that popular. What's worrying about this post in particular is it's not business focused, and the only long term company goal mentioned is "meteor will be a back end solution that makes sense." To what end? Why wouldn't you do that in a non-profit or pure open source model?
Meteor has as a better chance than ever, ESPECIALLY if 90% of what you can do in Meteor you can do in "bare metal" NPM! Meteor doesn't have to provide that many "features" to win over the NPM crowd that it has struggled to acquire thus far. It's so damn complex to implement all this stuff that most developers need help doing it.
Meteor's problem thus far has been it makes it easy but provides no way to "drop down" to a lower level and configure things like you would on "bare metal" NPM!!!! Despite its easiness, this has scared away many developers from Meteor--especially the expert developers who would otherwise evangelize once they joined Meteor.
Therefore, Meteor just needs to provide a way to BOTH do things with sufficiently less boilerplate (like it's always done well), but also allow you to drop down to make lower level tweaks as you would on "bare metal" NPM. And perhaps even an intermediate tier in between for some features.
For example, Relay + GraphQL is great but there should be the "beginner's way to Relay."
So the killer feature in fact isn't a "feature" in the traditional sense, but rather a mechanism that only a full stack framework could provide. Being the only full stack framework that matters (and the only "reactive full stack framework" in existence), Meteor is well positioned to scoop up the entire NPM market if it plays its cards right!
Unless this comment is from SMM team at Meteor, WTF? What is NPM market :)? "Bare metal" npm? Name single sizable project that uses Meteor? You do realise that for 90% of enterprise projects it's a wrong tool. There is no usable universial/isomorphic option, you can't expose API for external consumption, if you have to consume services on the backend the only cool feature that Meteor has is gone. Not to mention long term risks of what will happen to the project when vc funding runs out.
My assumption is that Meteor is moving towards becoming like any other app you can build on NPM. That means Meteor will be the wrong tool anywhere NPM/node/javascript is the wrong tool. That's a fine agreed upon limitation.
Currently Meteor is a layer above NPM, which is why I'm referring to NPM as "bare metal" NPM--you clearly knew exactly what I meant. Meteor needs to become an adjacent resource to thrive.
So my prediction is if Meteor does this correctly they will no longer scare away expert developers and grow more than they ever have.
NPM is a package manager. Expert developers are not scared it's just Meteor is horrible solution to majority of use cases that they need to address. You need to read up on what Meteor actually is and what it's limitations are. Major ones have being outlined above:
1) No usable uinversial/isomorphic option so SEO is gone.
2) you can't expose API for external consumption
3) you are tied to only supported storage backends
4) if you are not talking directly to storage layer it's only cool feature is useless
None of the above is limitation of node (or has anything to do with npm package manager).
yea I made up. But if you've been in any Meteor forum topics about NPM and support for modules etc, it would would make more sense. Meteor exists as a layer on top of NPM. It has done a lot of harm to its marketability. "Bare metal" in this case is a good thing, it's sought after deeper control which the Meteor community has awakened to realizing is a must.
"allow you to drop down to make lower level tweaks as you would on 'bare metal' NPM"
Meteor is entirely open-source and I've had no trouble diving into the lower levels to accomplish what I need to accomplish. Everything is split into reasonable packages and is relatively easy to traverse.
If anything, the Meteor team hasn't done a good enough job showing their true value (realtime via oplog->client updates, etc). Most of the current controversy stems from front-end developers jumping on the React bandwagon, splitting up the community as it stands. Not a big deal IMO.
this. and like most trends, it's shortsighted (and based upon the whims of contemporary front-end web dev fashion and not the needs of the meteor eco-system)
Part of the reason this year has been a bit of a mess is because MDG has been focusing a lot of resources on the profit-generating component of their business: meteor hosting and support. They launched Galaxy (their hosting service) just a couple months ago so it's still too early to say how successful that will be, but it could easily be in their best interests to cannibalize some of their older features if it helps to grow their userbase. For example, not having to spend developer resources on Blaze might enable them to get SQL support out the door sooner. I'm cautiously optimistic for them but wouldn't be too surprised either if they were still struggling next year.
Not having to spend money on Blaze will make them more competitive as a hosting business. Frankly, when is the last time you saw a billion dollar unicorn hosting business? Or a hosting IPO?
I doubt we will see SQL support. We will likely see something with GraphQL instead.
Heroku is probably the closest case study, in that they started as (and mostly remained in the popular conscience) a Ruby on Rails host. I believe they sold for $200+ million. Not a "unicorn", but not a small exit, for such a short period of time. They were only around as an independent company for a few years.
As a developer who is only using them for a personal project so far, I don't care one way or the other if they are incapable of becoming a unicorn - I just want them to be profitable enough to continue developing the framework. They may be under too much pressure from their investors to go that route, but wasn't hosting MDG's monetization plan from the beginning? If so, savvy investors would already know the likelihood of unicornization was low/zero when they invested.
You're certainly much more in the loop about SQL/GraphQL. Would GraphQL allow non-mongo databases to push updates out to clients for reactive updates?
Thanks for running Crater.io - I've been reading it a lot recently!
It is kind of sad that this wonderful framework, from total awesomeness, came to this situation where I am not sure what will future bring and should I make my projects in Meteor.
Meteor started with huge advantage, it is auto reloading, it has data layer that is very simple to use, it syncs across clients. On top of that, you can package mobile apps with it.
One thing I really loved is Velocity, testing runner that would display a dot in the corner of the screen, it would run a testsuite, and if it turns red, you can click and learn what test failed.
I was hoping it will be more awesomeness, instead, they eliminated Velocity, testing is not clear cut, db layer that needed most attention is not getting enough, whole focus is on frontend.
React is awesome and adding it, it really brings a lot to Meteor, but I think Blaze was good enough.
Anyhow, now I am Elixir/Phoenix dev, don't feel the same pain I did before, but any positive news from Meteor would be very much welcome.
Phoenix is the only other thing that really appeals to me as something I want to try that is fun. That was the great thing about Meteor, it got a lot of shit done, and it was fun. That's important.
What do you do to hook into Elixir? What's your tech-stack for the other side of the back-end?
I was looking into phoenix/elxir generating GraphQL but that seems pretty immature and at least a year out to be comparable with Minimongo/ddp.
I just use Phoenix/Elixir. I can wire it with React, but honestly I am starting to question this. Only if I really need React, I will actually use it.
So far I work on simpler stuff, api's and smaller apps.
This has been my feelings on meteor as well. It looked neat and I went through some of the tutorials and such, but really had no projects I could use it on. All my current projects interact with various sql database at some point. I realize that isn't as cool as all the nosql stuff, but I kept hoping they would get to it, and then kept getting disappointed.
It's a pretty narrow full stack to me if you don't have real support for sql databases. It's been sitting there for 3 years and has about the highest votes of all them. They had a post about experimental postgresql project in august(http://info.meteor.com/blog/an-early-look-at-sql-in-meteor), but it's mostly sat there with a few updates since then. It doesn't seem to be much of a priority.
I couldn't agree more. One of the most expensive things we have to do on Meteor projects is constantly re-mapping the way we think about our data so it works in a noSQL paradigm.
If they were serious about the framework they'd drop everything they're doing and focus on getting some proper relational support happening ASAP.
Why will it be any different this time compared to last time with GWT, Dojo or SproutCore?
Server - client binding javascript widget frameworks are nothing new, and they have, historically, failed to be capture broad adoption because they require a very specific backend.
If you had an excellent series of react components with data binding done via an open server specification and meteor just happened to be one implementation that backend; people would really dig that!
...but there would be a lot of people who didn't use meteor at all; and just wrote their own server implementation for it.
“but wait, if we end up using React, Relay, and GraphQL,
what do we even need Meteor for anymore?”.
...
This all boils down to one key fact: Meteor is the only
framework that controls the whole stack.
So what? Who cares? Controlling the whole stack isn't even remotely interesting unless there's some tangible benefit from it.
This is by far the weakest and least compelling part of this article.
So this is my vision of the future of web development
for 2016. React as a common front-end standard, and
Meteor starting out as one of many possible back-end
choices, but slowly becoming the one that just makes
sense.
You really need to try harder to explain why Meteor would be a compelling choice for people then.
If the front-end component api is well defined and backend agnostic, meteor seems to offer literally no particular benefit over any other backend someone might choose.
This is important because development standards are a
winner-takes-all game: once jQuery became the default, it enabled an
explosion of plugins and components built on top of it,
and every JavaScript widget became a jQuery widget.
The exact same thing might very well happen with React.
And that’s a very exciting thing for Meteor.
Thankfully we know a bit better by now, and build modules with a small surface area that are not directly tied to frameworks or plugin APIs. So no, I'm not so excited about that happening to React.
Can someone chime in as to whether React won the frontend war? As in the super majority of new project will be developed in React. I'm not that well-versed in the Node ecosystem (I got my news from ... HN). But from little I've seen, I found it hard to believe that React would be able to react the place where jQuery was (is?).
Heck, we even have a post staying on the front page today lamenting the inferiority of React.
It would be basically impossible for React to reach jQuery-like levels of adoption. The beauty of jQuery was that you could take an old, crufty pre-jQuery application, drop in a single script tag, and start writing nicer code immediately with no fuss (and refactoring old crufty code as you touched it).
You can't do that with React. I can't even imagine what it would take to migrate some 2010-era J2EE enterprise app to React, but it certainly wouldn't be just dropping in a script tag and writing your new code more cleanly.
Which means that React can only be the product of choice for new development moving forward; and even then, given how complex it is, only some subset of apps are going to bother with it. Nobody ever said "this application is too simple to bother with jQuery," because jQuery helped even simple apps, but there are legitimately huge classes of apps for which React is just massive overkill.
The comments in here today are a bit out of touch.
>You can't do that with React.
You can. Other than React's rather hefty size, there's nothing stopping you. React is just a view layer, is unopinionated about how you get your data to it, and for rendering to a DOM needs nothing other than a DOM node to render into.
Try it out. You can have 100 different React components slowly eating your legacy app alive. You just gotta be smart about it.
Drop a React component in the middle of a legacy project is IMO less fussy then jQuery code. I say that because components are standalone, so you won't mix logic for that piece.
One interesting thing about React is how some big names (Amazon, Apple, Netflix, Yahoo) rallied to React instead of creating their own libraries, whereas they all had their own-cooked libraries before.
Also, which is more of a personal opinion, but I've tried a lot of frameworks/libraries and React is the first one that really "clicked" with the way I work and design. I don't think it will "replace jQuery", but for modern single web application, I think React is the way to go. Or said differently, "Nobody will get fired for choosing React" ;)
> some big names (Amazon, Apple, Netflix, Yahoo) rallied to React
That's a bit of an overstatement. At least three of those four are also shipping major Ember apps and investing heavily in that ecosystem. (The only one I don't know for sure is Amazon.)
And at least 3 also ship apps with Angular as well, and I know Netflix has some eyes on Angular 2 as well with several key figures from Netflix having helped shape some of Angular 2's direction (at least through the push for observables).
This war talk is silly, and sort of akin to fanboyism that is often seen in stuff like video game consoles - lot of preaching & rhetoric, short on hard numbers and other meaningful metrics/facts.
I was about to abandon Angular 1 for future projects and go all in on React. And it looked fairly promising, except everything is its own little module. Good for UNIX, but not so good for modules that change so often.
Then I started catching up on Angular 2 and TypeScript. It looks like the right mix between new and opinionated. I just don't have time to research a module for data, one for building, one for testing, and one for validation. That's where an opinionated framework comes in handy.
I do hope Angular 2 takes off.
Any other Angular people out there weighing in between React and Angular 2? If I were a betting man, I say it's going to come down to those two for the next few years.
I'm no classical web developer, so I'm not be the best reference, but I used both a little bit for some realtime (mainly websocket driven) webapp for state visualization of remote embedded devices. I started with React, and I'm now on ng2 and happy with it (apart from some hopefully soon fixed bugs).
Imho both are ok. What I did not like that much with React was that the virtual DOM did not play nice all the time (strange effects can happen if you place non VDOM aware widgets inside it) and if you not take special care (keys) then reconcilation can produce a messed up representation. These things seem less problematic in ng2.
An unexpected very pleasant surprise for me was using the dependency injection mechanism in ng2 - I did not expect it do be useful because I never used something like this before. But now if any sub-sub-subcomponent in my view needs access to a status I don't need to pass it all the way down through unrelated components via props (like in React) but can directly inject it only in the using component. I also had good experiences with MVVM architecture from other projects with other frameworks, so I am happily using this approach also in ng2. For the model component I'm using service objects which are encapsulating the current state, exposing it through observables and are injected into the component (viewmodel) through DI. What I like here is that I can bind the view directly to the observables from the model with the help of async pipes and thereby get an auto-updating behavior with zero boilerplate code.
Apart from that there are obviously the major differences - angular has an inbuilt router, React not. But still I wouldn't think of Angular2 as something highly opinionated, you still have lots of flexibility.
As I am a big fan of typescript a factor for me was also that ng2 is typescript-first and I don't have to rely on possibly incomplete or 3rd party type definitions. But that might be more of a political factor, the basic typescript support for react is also good (it can even check the types of props in JSX - which currently not possible for ng2 templates) but many 3rd party libraries don't seem to provide type definitions.
We've been using Angular on one project and for a new application we were considering using just React with Node or maybe those two with Angular 1 or 2 also. However, after getting started with Aurelia we may stick with it and never consider Angular again!
It took me lots of time just to figure out to write a 'PROPER' react application. There are too many modules to choose from for routing, data acess etc..
Then I tried with Angular 2, it look me less time to get up and running with forms, routing and everything...
Or to rephrase, No React has not won the frontend war in the way and scale that jQuery won the front end war. At one point something like over 50% of all new (at the time of its peak) web applications big and small included it? No. I mean jQuery actually really lost its stranglehold primarily because the browsers actually started incorporating most of its core ideas into themselves to a point where it wasn't 'necessary' anymore.
However as far as alpha geek mindshare, react has definitely overtaken everything else in the frontend world. At least from what I can tell.
I think when you look at the companies using React now, you start to understand why it is gaining ground quickly. Couple that with the fact that Facebook has dumped a lot of efforting into the tooling around it, it makes sense to me.
I think React won the HN front page, where anyone who criticizes it or promotes another technology gets down-voted. However outside this bubble, ReactJS has a very long way to go before adoption rates make it a contender for top library (http://trends.builtwith.com/javascript/javascript-library).
React is probably too hard for casual scripters. I disagree with the OP's point about it being the new jQuery. It is however perfect for a solid engineering solution to building great web applications. It's for engineers who care about churning out a well tuned architecture and not for those who are just creating an CRUD app that just grows organically.
With React you have to Reason about abstract things pretty early, especially if you're using something like Redux. You have to know how to think about code in the abstract. A lot of people are just trying to get specific behavior on their website. They're thinking "I want a form that does this x", "I want a button that does y". They don't may not know how to think about abstract architecture and they may not see the value in it.
React doesn't really let you write code this way easily. You will run into problems with the lifetime cycle. You will be constantly fighting the library. Angular on the other hand lets you write a basic CRUD app without having to worry about those things. It's friendlier for people new to development.
I'm not advocating for Angular, I very much dislike it and I exclusively write using React, I just think React too hard or too much for normal people.
React won. And that's a good thing. Anyone reading this has one less decision to make. If you're building a JS frontend you want to be using React. You'll also want Redux to structure your application around React.
Having stated that I am trying to get up to speed on React in order to make a knowledgeable comparison to Angular 2. I've got friends who are way better JavaScript programmers than I am, ones with VC backed startups built with Angular 1, who are really struggling to learn Angular 2.
React only won the people who aren't satisfied with their current framework/situation because they didn't have the attention span to stick to one thing for more than a year. Still using Backbone. Still works.
I completely agree, with the huge caveat that React works so incredibly well with Meteor it ruins the experiences with React elsewhere. It really is a match made in heaven. Give it a try.
jQuery and React aren't in competition. Not even really tackling the same problems (though obviously there is some overlap in some areas) and neither one of them are frameworks.
React is overkill for a website. It is great for a web application. But your blog about recipes or hats for cats? You're just over-engineering at that point.
It's probably too late. The work they've done with blaze is wasted since react and angular(still) are dominant. The work they've done with MongoDB is wasted since most of the world wants SQL. So what do they really bring to the table. It feels like too little too late.
Actually our platform aims to be an entire "Wordpress for social networks". We realized that identity, security, roles, permissions, consistency and realtime updates etc. are hard to get right and building a standardized platform will free up developers to focus on what their app does instead of reinventing the wheel, etc. Not only that, but it will allow interoperating and reusability of components across all the sites.
And yes, it does routing, pagination, components and more in a way that will give Angular and React a run for their money if you check it out.
This looks fantastic! Please could you write some words aimed at potential recruits to qbix? What to expect, what not to expect. I noticed, in scanning your site quickly (... I think all content should bear the 'scanning user' in mind, but that's another topic) that php is mentioned. What php knowledge is required? What JS knowledge is required? Make it easy for people (I mean really, visitors who are pre-tutorial) to decide if they have the wherewithal for it to be worth them making a modest commitment to take it for a test drive.
You can put together a site with hardly any PHP knowledge. Just place reusable componenets on pages, or widgets that connect to ready-made backends... but then you don't really need this framework.
But if you have some basic PHP knowledge, you'd create more pages, and perhaps some backend actions.
The more PHP and JS you know, the more you can do. Unlike React and Angular, though, everything is named in a super-straightforward way, like Q.page and Q.Tool and tool.children() etc. So you just go ahead and build your site and Qbix does a ton of things for you, like dynamically swapping out css/js as you navigate pages, takes care of history and routing, activates and removes tools and their associated events, lets you subscribe to exctly the events you need, and documents conventions you should use to play nice with everything else.
Dove into react and redux and built a couple of small apps. They are amazing not because they add some "fancy" features but because they train you to think with a different, much cleaner and simpler, mindset. Before your brain "clicks" you feel miserable. After it does you think "why on earth isn't everybody using this??" and any problem is solvable by dispatching actions and building reducers (thank you Redux!).
Three days ago I spent a couple of hours on Meteor's simple-todos tutorial, trying to understand how everything was working (that is, at an abstract level). I felt great after finishing it. Two days ago I started building a service we'd like to launch within a couple of months, e-commerce like stuff. I felt miserable. Pushed the first "draft" with a customized sign up and I felt like I had no idea how to proceed.
Yesterday I spent 4 more hours, started using packages like autoform, collection2, something for bootstrap, iron-router etc. and I feel FREAKING GREAT. Again my brain clicked and now I implemented ~70% of the features with validation, defensive checks on the server for security, nice-looking popups, good overall UI... I mean, I intended it to be a prototype, maybe mocking some parts but, damn, we basically already have a MVP! In 3 days (effectively ~12 hours)! And now I already know how to implement the rest, it just feels natural now. Like when you have a solid plan and you think it through in your head and you KNOW how to implement each and every step of it.
You can hit a wall with Meteor as much as you can with any other framework (I mostly use Django). It's all about reading the docs, looking at what the community is doing and try to adhere to some "guidelines" (if there's no standard way of doing something). I will let you know how it scales when we reach a couple million users (bazinga!).
React is a rendering engine, it's covers the final piece of your web app (rendering a data structure into DOM). But whatever you do to create the data structure that gets passed to React is up to you. This keeps most of your domain logic outside the context of the React framework, you just use React as a tool to render you final data structures into DOM. So basically the API you need to know for your domain logic is just Javascript, which most people know already and it's really easy to lookup answers to your questions etc...
With Angular your domain logic exists inside the context of the framework. i.e. if you ng-repeat something you can't just filter that collection with Javascript you have to use an ng-filter to do it which is a special Angular construct. So the API you have to learn to manipulate data isn't just Javascript it's Angular-specific. And what if you don't know how ng-filter works? Well, you're tied to the Angular docs to figure it out. The Angular docs are of particularly poor quality so this coupling turns into a really serious problem if you're trying to be productive, because you're constantly reading docs to figure out how you do something in Angular.
I'm not sure how Angular2 is since I haven't used it, but to me React vs. Angular1 is a no-brainer win for React, since it's much easier to be productive in React + you can target mobile now with React Native. Something I've noticed also, there are basically no developers who have switched from React to Angular and now evangelize Angular, yet there are thousands of people who have switched from Angular to React and now evangelize React. I think that speaks for itself in the sense that anyone who has used both extensively prefers to use React.
Probably just means that Angular (at least seems to be) losing momentum and marketshare to React. It's hard to go a day without seeing something cool or exciting about React on the front page here, but all you see about Angular is either nothing or articles about the upcoming(?) transition to 2.0.
I've been using Meteor for little over a year now and to me, the real selling point for Meteor was the insane speed, productivity, and almost instant gratification that results from that speed: all of a sudden you went from having to configure a million different moving parts to just coding, almost forgetting that you are coding in the process, enjoying yourself, and suddenly seeing your features pop out of nowhere. It's quite magical.
For someone like me (I'm more of a designer who can code than the opposite), the reactivity, feedback and interaction with your code make the whole process feel much more "hands on", almost like sculpture, in the sense that you are able to poke things and see them react instantly. And that makes all the difference.
Yes, many problems do appear once you dive deeper, but I've never used another tool that brought me closer to my ideas than Meteor. And in the end, that is for me the single biggest achievement here.
Meteor started off so brilliantly. I wish the team would focus and just make it great.
Many people would complain about SQL and what not but the truth is there's a very large number of people who are quite happy with MongoDB and the fast experience building an app.
However there are some really big issues that seem to be ignored:
1) It's nice that its backwards compatible but some essential features are missing such as a router. Iron Router is available but it's practically abandoned. You can't even have URL's such as /2 on it.
It makes it hard to keep an app for the long run knowing there is a risk of an essential component about to be abandoned.
Other similar projects include Meteoric (an Ionic wrapper)
2) I wish they'd focus on making Blaze work. It works. Many people don't like react and just want an App build on V1 to work with V1.5 and V2. The lack of clarity is harmful to the use of Meteor in The Enterprise.
3) The build time. It used to be that Meteor built a project near instantly when a file was changed and hot code changed the page. Now it takes a good 20 or so seconds for a simple line change. It seems over the top.
4) Clarity and focus on direction. They spent ages pushing people to their Npm system, now they're going back. Why not start with node_modules/complete npm support instead of flipping back and forth. The volatile state of affairs with Blaze, Npm and the general structure of an app manifests risk in choosing Meteor for an actual Enteprise grade app.
5) A focus on improving what already works well over adding new features and degrading the performance of existing features.
I mentioned the build time, but other parts of Meteor such as Cordova, Blaze, Tracker, Mongo (Meteor uses MongoDb 2.6?!) would certainly help more.
I'm not sure what's happened but it seems a lot like the team is losing focus of what people actually like about the project.
I especially agree with 3). I was expecting more people to mention this. Compared with other build systems like wepback or gulp, meteor rebuild times are insane.
edit: Just checked out the Meteor Roadmap, and build times are not even mentioned there.
Only semi-related...but why do you think Mithril is always so easily dismissed? I kind of get it: huge companies are working on and adopting React. But after using Mithril, I just can't figure out why it has failed to catch the attention of more people.
Mithril succeeded in catching my attention because creating a good mobile web experience is important to me. This does not necessarily explain why it has failed to catch the attention of others, but might be a clue.
I strongly urge you to take a step back and really look at React community from 30,000 foot view. Please don't get on the hype train without taking a look at other solutions. Vue.js as far as libraries go, and Ember as far as framework go. I promise you, you'll have a better experience.
Vue.js seems like backbone. Last time i checked Ember looked way complicated. What i like about React is the simplicity. Its basically JavaScript with few React functions thrown in. As a view component its very good. I have used it in normal rails app as well.
Seeing the Discover Meteor and Kadira guys embrace React with Meteor is definitely making me want to dive back into the framework after being very hesitant over the past few months. It's great to see ~someone~ with a clear vision for the future.
Mootools is not an ancestor of jQuery, it actually was released after jQuery (by a few days).
From what I recall, the success of jQuery was not because it allowed to do more things. It was mainly because developers by then considered javascript as a lower citizen language and wanted to do frontend stuff without having to learn javascript - and jQuery allowed just that.
For (the few) javascript lovers, jQuery main advantage was to be a big decorator, not extending any native, which guaranteed there will be no conflict with other libraries when adding jQuery in a page (quite ironic, when you see how all libraries expect jQuery may be present in the page, nowadays).
I gave it a try a few weeks ago but every other package was unsupported because a new package was being developed rather than following semver, the standard server logging was terrible when I had to debug a frontend dev's memory issue. Seems like the Wordpress of realtime applications. The DDP package is interesting but only helpful to supported DB's as far as I could see. I think choosing GraphQL will just narrow their 'full stack ecosystem' again. Why not provide better low level support for your community to write GraphQL Cypher, SQL and NoSQL themselves. There are some great packages I've seen for this.
I'm sure that Angular 2 would be a better choice for a Ecosystem like Meteor. React is very nice, but annoying to find tutorials, get a decent size app going (routing etc) and Angular 2 is more mature (all the good and bad points of NG1 and other js-libs were considered). Next to Google also Microsoft is betting on Angular 2 (TypeScript). This will boost the community greatly. NG1 was slow. NG2 is amazingly fast (webworkers/server side rendering). So for a Meteor Use Case I would pick NG2. If I wanna build a simple Snippet I would use React.
Most meteor apps are stateless on the server so you can safely scale by adding more servers (and more server to Mongo if that's the bottleneck). This can be easily done with Cluster package (https://github.com/meteorhacks/cluster). It's so easy you don't even need to configure anything.
As the sibling comment said, you do the same way you scale anything else: add more servers that replicate the same data. As it becomes to large, shard your publications depending on type. Meteor's livequery works better serving a lot of similar subscriptions, so at some point you can have multiple server types each taking care of one scope.
I just started with Meteor a few weeks ago, and thought it was absolutely amazing as a prototyping tool. I figured I'd be recommending it to anybody doing an MVP.
I actually do believe there is a business model there, but it seems they are focused on the high-end with hosting and support starting at $500/month
This is fantastic. This removes efforts to maintain a random front end view layer while legitimizing the numerous react integration attempts. This will save a lot of time moving forward to phase out blaze.
My thoughts: Meteor got popular enough that the Javascript loons started pecking at it and infesting it with the general lunacy that accompanies NPM and it's ecosystem.
MDG adding easy React support was a definite win and I think using Meteor with React is -the- way to write Meteor apps. But they need to start ignoring the crazies out there and focus on their vision.
jQuery did not succeed because it was a 'good enough' competitor to dojo or prototype or mootools or extjs... it succeeded because it went completely the opposite direction. it did not attempt to be a fundamental ui framework like those guys, it didn't try to be full featured, it didn't try to change javascript to look like another language and didn't try to shift the paradigm of the front end development world.