The State of Meteor Part 2: What Happens Next
discovermeteor.com
discovermeteor.com
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.
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.
It's as simple as 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.
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).
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 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).
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 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.
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.
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.
Why did Wordpress succeed, by the way?
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.
[1]: http://w3techs.com/technologies/details/js-jquery/all/all
Code that works without surprises, experience that accumulates, projects that can be executed reliably?
But of course that's not much fun when compared to tinkering around with to-do example apps on the new new thing.
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.
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.
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.
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'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...
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.
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).
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.
That was the magic trick that sold your client.
They proved real-time data synchronization could be simple and seamless, and everyone else had to run to catch up.
But that trick is now 4 years old, and nothing else of substance really emerged.
As Ember, Angular and React grew, you were never going to want to use their odd looking front end.
Their data sync also came with dubious claims to scalability, not the least is their tie to Mongo.
That may be fixed now, but the consequence is being tied into Meteor Galaxy.
Meteor should have thrown everything away, and become just the data layer.
Like Firebase, but open source, and backend / datastore agnostic.
They tried to standardise DDP, but it didn't catch on.
But what the world needs is a standard like GraphQL, but handling data updates, and with automatic realtime data sync.
Thatd be a wonderful legacy for Meteor.
But this won't happen, as the company needs to make money from hosting.
What that says about MDG's business model is less clear.
I doubt we will see SQL support. We will likely see something with GraphQL instead.
> Frankly, when is the last time you saw a billion dollar unicorn hosting business?
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!
I am not even sure how a CMS got mentioned and compared here.
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!
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.
None of the above is limitation of node (or has anything to do with npm package manager).
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.
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.
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.
Oh well, I guess we'll see how the next year goes.
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.
If they were serious about the framework they'd drop everything they're doing and focus on getting some proper relational support happening ASAP.
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.
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.
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.
Heck, we even have a post staying on the front page today lamenting the inferiority of React.
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" ;)
While I believe you, I'm just curious how they are being used by Amazon or Apple. Do you have references about this?
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.)
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 referencing stuff like this: http://www.youtube.com/watch?v=eNC0mRYGWgc&t=8m18s
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.
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.
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...
From the look of it, Aurelia seems promising, need to look into more before I need to comment anything.
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.
React is fundamentally different, but Aurelia (and its predecessor, Durandal) were always about making component-oriented apps.
https://www.google.com/trends/explore#q=reactjs%2C%20angular...
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.
It took a few weeks to get decent with Angular, over a month to get productive with Ember, and about a few days to figure out React.
That trend line might be more indicative of Stack Overflow searches.
https://www.google.com/trends/explore#q=reactjs%2C%20angular...
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.
>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.
They said _no fuss_.
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.
Also a CRUD app that just grows organically needs a well-tuned architecture too, once it grows large enough.
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.
This prevents Meteor from being used in any environment that needs to/wants to use a SQL db.
This prevents Meteor from being used in any form, for any application that needs to access existing data in a SQL db.
React does not prevent Meteor being adopted - not having SQL support is a dealbreaker.
If Meteor does not confront and solve this problem nothing else matters.
The only thing MDG should be doing in 2016, is SQL DB support.
After all, the fact that no other company than MDG has even tried to make it happen should be proof enough that it’s not trivial.
I did it, over the last 4 years http://qbix.com/platform
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.
Also it does a lot more: http://qbix.com/platform/features
PS: try loading all this on your smartphone!
But if you have some basic PHP knowledge, you'd create more pages, and perhaps some backend actions.
As far as the PHP and JS knowledge, see http://qbix.com/platform/guide
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.
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!).
> And Angular is… well, it’s not React.
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.
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.
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.
edit: Just checked out the Meteor Roadmap, and build times are not even mentioned there.
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).
Try running a Meteor app with >500 concurrent connections.
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
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.