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!
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.
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 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.
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!
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.
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.
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.
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.
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
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...