Meteor hits 1.0(meteor.com) |
Meteor hits 1.0(meteor.com) |
What am I missing...
The main concerns we had was scalability and reliability.
How does 1.0 address the previous concerns that was enough to abandon meteor.js altogether?
Not a huge fan of this turn of events, either...
But yes, I agree, it's not ideal until a SQL adapter is available.
seems like their selling point is data binding + client syncing. Considering I can do that with Meteor, what's the advantage of using Ractive/React + Firebase?
1. You can reuse your existing API, or choose the stack you're comfortable with (I prefer Python to Javascript and Postgres to Mongo)
2. They are being used in production by high traffic websites (Guardian and Instagram respectively), so they're more battle tested
3. Their press releases aren't loaded with buzzwords and hyperbole
It's a bit light on details. I wouldn't say Meteor is 1.0 yet, but preparing for it. Also Worldwide Meteor day is Nov 6th, I anticipate a more formal announcement then.
A sea change in how web software gets built and consumed, in the same way Britannica yielded (had to) to Wikipedia.
> No longer do you need to provision server resources, or deploy API endpoints in the cloud, or manage a database
So you don't manage a database, but what happens to the data.
Can anyone trace an example, I don't, order or cart update from client code to persisting it on the back-end somehow? Does it use flat files...?
It's just a higher level of abstraction, not a new technology. And certainly not flat files.
Currently it uses MongoDB, though (last I heard) there are plans for Postgres and possibly more, but it will have to work like MiniMongo on the client (i.e., no ORM, and mostly the same on server and client).
It's pretty much hassle-free though, especially with some of the community packages, such as collection2 and simple-schema.
Choosing a stack on your own means more time is spent making things work, but then you know how it works. That's why I went for a MEAN stack instead of Meteor. But I'm going to try Meteor again soon!
Although this may be corrected in 1.0, single page applications in Javascript like this (whether in Angular or other tools) tend to underperform in SEO (Or not perform at all). Meteor has a sort of hack that handles SEO at the moment, but it's not particularly terrific.
Meteor's database support is presently focused on MongoDB exclusively. Expect relational and other data stores to have improved support in the near future. If you were starting a project that depended on a relational database (Postgres, MySQL, MS SQL, Oracle, etc.), Meteor would probably be a poor choice today. For many use cases, however, Meteor is terrific in my experience.
I haven't looked into fast-render mentioned elsewhere, but initial load time has always been a issue, and it seemingly gets worse as you add more functionality to your 'app'.
Personally, I'd only consider betting on Meteor for anything non-trivial once some form of incremental/optional loading of functionality was included.
quick feedback: this scares me off a bit:
200 open issues / 150 stale branches / 42 open pull requests
might be normal for open source projects of that size though
cycle times might be better indications
We've built an enterprise/b2b app on meteor, and even through all of the hard yards, it's been a success & the right choice for us.
When I first heard about meteor, back at v0.5 or v0.6 - I watched the video from their home page, and thought it was full of buzzword bullshit. I didn't have a clue what it did.
I then ended up reading about how their latency-compensation API system worked [Meteor Methods]; And instantly knew that it was for me.
Having an API that simulates itself on the client, while simultaneously performing the same work on the server, is freaking awesome. (And then rolls back automatically if they don't agree).
If you are building a real-time, collaborative tool. Meteor is the framework.
That being said, there are a few questions about integration & scalability.
Opportunities to use Meteor:
* If you can make something small, eg. an internal tool [Free mobile app with cordova!]
* If it matches a certain feature of your app - and you can segment it based on URL (eg, it's a separate app)
* You're a sadist, and you're going to port your whole app to meteor...
* You're writing an MVP and you're going to scrap it later
* You're product has realtime/ collaborative elements that are a SELLING feature [not just for your personal enjoyment].
Scalability:
* Client are always connected via websocket. Great for realtime data (no polling), crap for a website.
* As meteor instances are single threads, you can run multiple instances on the one server. Design you code for this (eg, don't store state in regular JS variables on the server - all has to be in the database). Load balance between them.
* Once the "client" has booted up. You can then connect to as many other DDP servers [backed by their own mongo instance, or the same mongo instance] as you like. This gives you the ability to segment your application based on your core feature. EG; if you're a monitoring app, shard your data by client, if you're a document app, shard by project. Have a central listing which tells them which server to connect to.
* Perform heavy lifting somewhere else. Plenty of "web workers" out there, or roll your own using Celery & Meteor-Celery package [shameless plug].
All in all. Meteor is great at what it does; and what it does, is going to be the next generation of web apps.
Disclaimer: I think Meteor is fantastic.
Never really had an issue - I can't say the same about rails! Obviously Meteor has the advantage of being younger and so less cruft has built up, but I'd bet on it still being insanely easy to deploy 4 years from now.
The Meteor team is doing an awesome job spending the VC money on making an experience that is fantastic for devs. Major props to Geoff et al.
The CSS is also bundled in production. When further changes are made to the CSS, the new stylesheet is live-injected into the running apps without reloading the browser.
if (Meteor.isClient) {
Relevant section of the docs: https://docs.meteor.com/#/basic/filestructure
In node you do that by extracting the code in a separate module and telling browserify to use the browser-specific module via your package.json.
In Meteor you can just check whether you're running in the client or server at runtime and execute different code accordingly. That's what `Meteor.isClient` is for.
It has seamless support for hashes and strings, miniredis, latency compensation, user input validations - similar features to MongoDB integration.
Right now you need to start the Redis server and set up the KV observations manually once for every Redis server you intend to use.
This support was experimental and we didn't develop it further from there. We told our community about it on a Meteor Devshop but there wasn't much interest. If there will be more interest, we will continue developing it.
One of the core developers seems to be working on it: https://github.com/meteor/redis-livedata
Basically, if you need native MySQL support (some support already exists, but it's not in core), or if you need a web-site (SEO), not web-app.
Regarding scalability, by the time your app becomes so popular to exceed thousands of concurrent users, Meteor will have improved scalability again. They've done it a few times already with Mongo oplog tailing support and whatnot. If you already have a highly popular app, it will take you time to port it to Meteor too. So scalability may seem like a problem right now, but likely won't be one in, say, half a year.
What opportunities exist in the enterprise market that specifically benefits from this feature?
* clean and much simpler code base
* automatically (reactively) updated status reports on compliance across various systems depending on numerous components throughout Google in continuous flux
* ease of onboarding new developers in the team given the simplicity and ease of learning of Meteor
Low latency (real-time) can be an important part of effective and engaging communication.
Sure, it's not for everything; I wouldn't want my email communicating word by word to my recipients as I typed.
However, enterprises usually involve a lot of communication - with team members, stakeholders, and clients. - there are many opportunities to spice things up and make them more engaging & effective.
There's also the opportunity to instantly communicate non-prose - manipulating datasets, images, graphs and charts in real time.
That said: There's nothing intrinsic in meteor that ties it to Mongo. No reason why, say, a Postgres or Memcache or whatever backend couldn't exist.
B: It is possible, perhaps even common, to write apps without server side storage at all - imagine API frontends or data aggregators.
* http://blogs.enterprisedb.com/2014/09/24/postgres-outperform...
Also +1 on the Major Props to the Meteor team. They are a model team.
1. The command will be sent to the server.
2. The command will be performed on the local database, but backing up the original local DB state so that it can be reverted if needed.
3. Immediately, any helper functions used by templates which rely on data from the DB will react to the change in the local DB and inform their template instances to update just the relevant part of the DOM.
4. The server will eventually get the request, and authorize it based on allow/deny rules.
5. If the command was allowed, the server will update the actual DB, and use MongoDB's oplog to notify all other server instances that the data has changed.
6. Server instances will send the changed data down to all subscribed clients, which update the state of their local DBs, causing the templates to re-render the relevant parts of the DOM.
7. If the request was denied on the server, the server informs the requesting client, and the client patches up its local DB to the actual DB's state, also reverting the DOM state.
So you have built-in latency compensation and full-stack reactivity by default. The client anticipates the server's response, making the application feel extremely responsive. But if something goes wrong, the client patches itself up with the actual result. Of course you can avoid latency compensation altogether where you don't want it - just avoid using the isomorphic API on the client and use RPCs instead. The servers will still inform the other server instances and push the changed data down to all the subscribed clients, but the requesting client has to wait like everyone else before the DOM is updated.
* Fully automated build chain. No matter what kind of preprocessors I use, all my code is compiled, bundled, and hot reloaded into the application. CSS updates are automatically live injected into running applications without a browser refresh. I don't have to write any build chain code, just application code.
* Isomorphic client/server APIs, with code sharing built into the build chain. I'm using the same language with the same APIs in both environments, drastically decreasing redundant code. Clients can simulate server RPCs using the same function as the server while it waits for the server's response. If I want, I can easily make the client's simulation code different from the server's such as when I want to obfuscate something, or simply disable client simulation for certain RPCs. The package system incorporates both server and client assets, allowing drop-in full-stack components, such as...
* The Accounts UI component. A drop-in, automated SRP+OAuth authentication system that's easy to customize and restyle, or build from scratch using the simple JS authentication APIs. It takes minutes to make a web application with a fully-featured and secure authentication system with password-based and 3rd party OAuth login methods. And logging in never requires a refresh.
* Already glued together. Endpoints don't have to be hooked up; they're hooked up from default. Publish data on the server. Subscribe on the client. Add authorization rules, and I have a fully functional web application with realtime data updates, with virtually no glue code.
Anyway, Meteor offers much more than data binding and client syncing. See http://www.meteorpedia.com/read/Why_Meteor
I think you need to take your curiosity to google (or the real world), and do your own research.
Since it seems like everyone wants to think of themselves as doing something huge, I'm sure the answer can't be 'no' to the second question — but I don't see any examples of significant projects being built on the platform. Actually, with that in mind, what happened to the gallery of projects built on top of Meteor? Perhaps I'm missing it.
All that being said, congratulations on reaching 1.0. There's clearly a lot of great energy and thought that went in to the project.
edit: The videos on the site weren't obvious to me at first, but after finding them I think this one is a good counterpoint: https://www.youtube.com/watch?v=QzhtQzAX_6k
You really have to build a meteor app from the ground up, so it is hard for established tech companies to get into Meteor when they already have spent years coding on another stack.
As new startups who use Meteor grow you will see those large-scale projects come about.
https://www.youtube.com/watch?v=cJbGNpmE7f0&t=8m30s
Hundreds isn't really exactly "webscale", but I'm sure they'll iron it out, or it could have just been the application that was at fault. It's one data point however on how meteor scales.
I'm not sure you'd use it to build the infrastructure of your startup on. Or a content heavy site. But I see building tools like for managing a lot of developer instances, internal tools for config, etc to possibly be pretty sweet for this.
Accomplish in 10 lines what would otherwise take 1000,
thanks to a reactive programming model that extends all
the way from the database to the user's screen.
Show me where you eliminated 1000 lines of code and how it was beneficial. Each line of code, to me, is placed with purpose and intent.
Are you eliminating thousands of lines of boilerplate? Or are you making best guess assumptions that fit the common need, and we still end up with those 1000 lines for something truly custom?
If you put together the right list of cutting-edge components like React, Firebase, Bootstrap, and some build tools, you might get a similar improvement in code simplicity. Our goal at Meteor is to give you the same benefits without making you write code to plumb between several different frameworks.
(Not that that is the only requirement you might have.)
Meter out of the box "just works," but it only works with Mongo for now, and it only works if you are all-in with the platform — on both the client and the server side. Those are two pretty big bets to make.
I would say Meteor is ideal for learning, except that it's important to learn what the request-response lifecycle is all about, and I think it can be detrimental when a "magical" framework does so much for you.
And one thing I just can't get over -- page loads in Meteor.com feel super fast. Until you realize it actually downloaded the contents (not the unseen images, of course) of the entire website! DPP is doing some interesting things, but some of Meteor is some nice magic tricks that we've seen before. 600kb+ of JS on page load is certainly an interesting concept.
Huge amount of work by a talented team. A super nice community. As for the framework itself, give it some time, let it grow, but most importantly, understand objectively its strengths and risks. It has both!
In other words, if you believe that the Flux design pattern (which involves a central dispatcher as the only entity capable of updating the data) is sound, shouldn't you stay away from Meteor's model when building large applications? Or am I missing something?
Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized javascript. That has the added advantage of letting you use a sane, strongly typed language, with all the productivity tools available for Java, and none of the quirks of javascript. http://www.gwtproject.org/overview.html
Meteor looks extremely simple to get up and started with, and I was thoroughly impressed by the implicit modularity of it all ("meteor create" makes like 3 files, I think that's awesome)
They really try (and succeed) to rid ourselves of the duplication on server and client. And if the android/ios support is as easy as it looks, this is an insanely useful framework.
I'm going to use it in my next project for sure now, just need to see how template/module composition works
Sure the git commit is a landmark, but there's nothing to offer other than 'kudos' with this link as the discussion point.
We merged the stories (in our ghetto way) and moved the comments over here.
Server side I have multiple choices that guarantee me heigh scalability, performance, and real time. Also the mongodb solo option, without sql is very restrictive.
Client side, there are great js frameworks like React, Ember and Angular that are great modular libraries.
Most of our customer projects use "old school" sql and only a few nosql-databases.
Waiting for Version 2 ;-)
I think Meteor is a great concept because of their seven principles [3], which I haven't seen in any other framework. I haven't worked with Meteor yet but will start a project in short term which uses Meteor, so I'm very excited to see how this works out.
[1] https://trello.com/c/Gf6YxFp2/42-sql-support
For everyone looking to learn Meteor the first 8 chapters of Discover Meteor are available for free for the next week. It is probably the starting book for everyone :) https://book.discovermeteor.com/starter
Also the Manning book Meteor in Action is 50% off the next week with the code jiafinal50 The book is in heavy development with updates every couple of weeks. However it is still not finished and lacks some advanced chapters still. http://manning.com/hochhaus/?a_aid=yauh&a_bid=aeff5509
Apress also has a book called Beginning Meteor but it has almost no relevant content as of yet and no updates in the last months. http://www.apress.com/9781430268369
All Packt titles are hopelessly outdated for version 1.0, so you better stay away from them.
It'll be a couple of days before a (completely) revised version is released for 1.0 though.
(Reviews can be found on Amazon: http://www.amazon.com/dp/B00MA8KVAY)
It is not done yet :)
[1] - http://techcrunch.com/2012/07/25/andreessen-horowitz-keeps-e...
Create an awesome framework that people want to use (Meteor started out as a travel guide site, I believe, and other YC batchmates wanted to use their web framework)
Step number two:
Keep building the web framework
Step number three:
Raise money to keep building that framework, with a partner who believes for the long term
Step number four:
Keep being awesome, and become the tool that a ton of devs want to use
Step number five:
Monetize with your own enterprise support and hosting
https://news.ycombinator.com/item?id=8522381
is interesting with regards to your questions.
http://blog.nitrous.io/2014/10/28/meteor-template-on-nitrous...
As for Node, there are some within the Node community who would like to bump it to 1.0 as it is clearly production ready. In Node's case, .1 vs. 1. is a just a numbering scheme issue, not a production ready issue.
Also check out a catalog of the best Meteor learning resources at http://MeteorHelp.com
I just went through the tutorial on meteor.com, and I'm impressed with the speed of getting results.
When I were to build another online app, I'd split that in building the frontend and the API composed from microservices, so that I'd be able to offer access through the UI and the web API. Is Meteor a good choice for this approach?
I am particularly excited by the potential of being able to swap out Mongo for RethinkDB (https://github.com/tuhinc/rethink-livedata).
curl https://install.meteor.com/ | sh
This despicable habit rears its ugly head again.
I want defined database strucures ;)
edit: random aside, I literally just saw the transition from the preview website to the 1.0 website as it was hotswapped in, and I have to say it looks _much_ nicer!
Secondly, why Rendr? Rendr was built for Backbone. The most recent info I can find that suggests using Rendr with React is over a year old. React can be rendered on the server just fine. The only thing you need to solve outside React is routing, getting the data and making it available to your React components. Either use stores or pass all the data as `props`.
Thirdly, why Grunt? If you talk about a "dream team", I'd think Gulp is the current hotness, not Grunt. And you don't need either of them anyway, there is so little to configure that you don't even need a full-blown build tool.
I don't have a single line of database code in my React app. All the API calls are handled by a small wrapper around my database's domain-specific HTTP API. I could use the same API with zero changes for a native mobile app or a new web app that doesn't use any of the existing code. My web server is a dumb proxy for the database API and a pre-rendered for React (the pre-renderer essentially consists of a single line of JavaScript).
I can understand the appeal of Meteor, but it's not like anything you complain about has to do with React.
(Now Angular on the other hand... let's hope you don't need any prerendering ever.)
For me it's a main advantage, I don't need to use "other" stuff to get the final effect.
I wrote few projects and it's the best framework if you start from scratch. Though it's hard to swell if you need to add it later to some existing project.
Meteor doesn't integrate with anything, but that was never a design goal. If you switch from Meteor, you can likely discard your entire stack (well, except the database obviously). It's based on node, sure, but that's an implementation detail.
Meteor is not a node-based stack. That's why it now has its won package manager instead of npm. It's a competitor to node with its own ecosystem. And that's fine.
Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the actions validation rules still apply on this executed logic and if clients disagree with the server (the privileged environment), clients cannot harm the server state.
To be fair, I'm pretty sure the previous versions did have this issue -- it was just supposed to be ultimately fixed. I could be recalling incorrectly though.
I wouldn't say the wait for 1.0 is a good indicator of stability or success, though. Node.js is still at 0.x and so is React. AngularJS took a long while to get to 1.x but is now actively working on 2.0.
Many developers are cautious about when they dare calling a product 1.0. Until the idea that "if your code is in production, it's already 1.0" gained some ground, there was barely any code on npm that wasn't stuck in pre-1.0 land.
The real indicator is how much time passes between minor or bugfix releases. Ideally the latter should happen fairly regularly and the former not too often. If Meteor hits 2.0 anytime soon, that could be a worse sign than if it sticks with 1.0.x for "too long".
- https://www.meteor.com/blog/2012/07/25/meteors-new-112-milli...
Gulp is pretty neat, until you try to integrate watch tasks. Want to run a transpiler whenever a file changes? Better don't have any compile-time errors or your stream will choke and die (without necessarily killing the process, mind you).
There are some workarounds (e.g. gulp-plumber), but depending on the actual tool you're trying to use they may not actually work -- or only work sometimes, which can be just as bad as not working at all.
Personally I've switched from Gulp to just putting scripts in my package.json file as god (or Isaac) intended. Every tool I want to use has a CLI anyway, and supports stdin/stdout, so it's all just Unix legos anyway. Except for browserify, which I replace with watchify in development for performance reasons (browserify in a large project can take a few seconds, watchify only updates the diffs).
It's not really a relevant option unless you are at liberty to swap out the entire stack. It makes more sense to compare Meteor with MEAN rather than simply AngularJS itself.
This is pretty much my experience as someone who started working on a project where the lead dev had decided to use Meteor and then quit leaving a wonky prototype with "reactive data", poor performance and missing functionality.
Now, some would say "it's not Meteors fault the UI wasn't made well!" and then I'd reply "sure, but if Meteor didn't encourage (and it seems, require) tight coupling of the data access and presentation layers, then maybe we wouldn't have spent the last 3 weeks rebuilding the entire app from the ground up just to add some missing functionality and fix UI bugs".
Honestly, I really can't figure out the lack criticism I see of Meteor around here. All these comments to congratulate on an arbitrary step in version number? I see other articles of accomplishment with a fraction of the positive encouragement and many times the criticisms. Is there a silent majority, or did I spend the last few months being underwhelmed by Meteor because I'm missing something?
Meteor embodies, for me, a tool that makes things 'easy', rather than one that makes things 'simple'.
http://www.infoq.com/presentations/Simple-Made-Easy
Anyways, that's just one developers experience and opinion, take if for whatever you feel it's worth.
It is much simpler dealing with Meteor's API's then working with documentation from 3 or 4 different frameworks that you need to accomplish the same kind of stuff Meteor does.
Meteor gives you a set of clean coherent APIS to work with to get stuff done.
Because if you started a small project in something else, it is not easy to change it to Metero later.
What he said was quite clear.
Scaling low-latency data synchronization is a challenge for scalability for sure! We are gradually building better and better drivers with persistence to MongoDB.
The scalability can vary greatly depending on your application's data schema, usage patterns and amount of writes.
If you watch the mentioned talk carefully, the speaker describes a collaboration tool with log replay with a lot of actions and running from a single box.
All my scripts are in `package.json`. I don't use Grunt or Gulp. If I want to re-bundle my client, I invoke a script that essentially does `browserify -g uglifyify lib/browser.js > dist/main.min.js`. My JSX build script and the bundler script are automatically invoked by a watcher.
This[0] is my entire build script and the only reason it's verbose is because I like to be able to execute each task separately if I want to.
The only problem with React is that it is only a view library. It only does components. The blessed solution is a Flux-like architecture as implemented by Fluxxor or Reflux, but you can integrate React into nearly anything you already have. I like the immutable/unidirectional approach React and Flux share and ended up writing my own library[1] because there were things I didn't like about the existing Flux implementations, but you don't have to do that.
I have to admit that Flux has a steep learning curve. And if you've never dealt with immutability before it can really melt your brain. But I don't see how Meteor is any easier to pick up, especially considering that it comes with its own entirely separate ecosystem (the only non-node library I use in my React app is an XHR-wrapper that replaces `request` on the client).
Does it have to use Node.js on the server can the client side framework work with any server side JSON service?
1. "I have to admit that Flux has a steep learning curve." & "But I don't see how Meteor is any easier to pick up..." are mutually-exclusive.
2. Most everything else you wrote does a pretty good job of representing why Meteor is so attractive to some of us.
With Meteor, you're developing Meteor apps. Sure, you can put a different front-end in it or replace its server-side with an API compatible equivalent, but that's like saying you can use Django without its template system or ORM (if you don't know anything about Django: you can, but Django's built-ins provide a lot of synergy that you can only get from tight coupling).
Traditionally, you would use a cookie on the client to authenticate and trigger the 'privileged' query during the http request cycle. As far as I can tell there is no way to do this with Meteor. Another way to phrase it is there is no authenticated server-side state modeling the client.
You can only view & modify data on the client that has already been published.
Data that you don't publish / is server only, will remain so.
It is very possible to use other client side frameworks such as Angular or Polymer, rather than just using Meteor's Blaze UI engine. However I find that Blaze's Template<--Helper<--Data<--Event system is extremely easy to understand and reason about.
Edit: Actually, they do seem to have a decoupled version of the Blaze UI that you could use just for your reactive DOM code and hook into a REST API. You just won't get any of the server-dependent features like full-stack automated data synchronization, hot-reload, live CSS injection, or Meteor's build chain. You just get a simple reactive template/helper/events system. http://meteor.github.io/blaze/
Meteor spans both the front-end and back-end to offer a seamless API experience when building your application.
edit: posted too soon they talk about it here https://meteorhacks.com/does-meteor-scale.html
Src: http://www.jesus.org/early-church-history/the-apostle-paul/h...
