Note that this is posted on the community wiki site hosted by one of the community members. The application running wiki is open-source: https://github.com/meteorpedia/wiki
Yep, I wrote most of it way back in the day and then someone else took up the reigns, I don't think it's been updated in a long time. It's definitely not 0.9.4 compatible at this point.
I'm working on an alternative template engine for Meteor now based on django. Currently in a big branch that's moving slow since I'm pretty busy at my regular job.
Every time I see a framework like this I ask myself: if I outgrew this, how difficult would it be to migrate away from it?
I'd love to hear if anyone has used meteor for something read and if they've had to deal with migrating to something else: how they've done it, and what issues they encountered.
For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process.
Meteor is a totally different way to write web applications. Between the merging of the concept of front-end and back, the distributed data protocol it uses, the live templates, there's nothing really else out there like it and no, migrating away from it will not be easy, but if you're a transient nomad with frameworks I'm not sure you should really use any framework.
That's because it's a higher-level abstraction than other web frameworks. Ripping out a layer and dropping down to a lower level of abstraction is always going to be a lot of work.
> For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process.
I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other.
> if I outgrew this, how difficult would it be to migrate away from it?
I'm becoming successful at fighting my urge to migrate my projects away from things I outgrow. I reason that changed preferences alone should not constitute a reason to rewrite an existing and working solution. And in case costs of adapting existing solution are higher than costs of rewriting it from scratch, then this is probably due to some unfortunate design decisions or obscure libraries/frameworks used, so these are the things to avoid.
> I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other.
That was why I eventually switched to React after trying to find ways to have Angular-like components/bindings without the DI/IoC parts of Angular (even going as far as reimplementing parts of Angular).
If you only want the bindings, maybe rivets or knockout is an alternative?
Outgrowing Meteor is a valid concern. It's intertwined with your backend and db, so it's definitely a lot of work to migrate off of.
I just want to make the distinction between that and JS frameworks that don't try to own your whole stack. Migrating from Angular is no more painful than migrating from Backbone. They're all frontend frameworks that talk to a rest api. When choosing between React, Backbone, Angular, Ember, etc ... it seems to me that migration effort shouldn't even be a consideration since a complete UI rewrite will be required in any case.
I find this troubling. Basically, I feel like we are reinventing the wheels 4 or 5 different ways but we are unable to swap out one for the other. Basically, we spend so much time writing the obvious things like CRUD in almost every permutation possible. Like back when visual basic was popular, you could easily pull together an app, here we are trying to make the web browser do things it was never originally designed for, emulating desktop like responsive app but with multiple vendor interests in trying to dominate this market, it's hard to say who to bet on and why because the developer mindshare is fragmented and we waste time trying to figure out how to create a login using Angular.js, Backbone, Ember.js etc., when short while ago you would just write a jQuery ajax or even better, render it on the server side and send it.
The whole idea of having to run phantom.js to render your website because search engine robots can't index your site reminds me awfully like trying to keep up with a high maintenance girl who is more trouble than she's worth.
It's not. And, native apps are likely going to make even more ground. I realize this runs against popular opinion, that webapps are some sort of inevitable future to replace native apps almost in their entirety, but we will see.
They can replace some native apps. With Meteor, you can now use the same basic building blocks to build your web app, iOS app, and Android app.
Maybe you won't reach the same quality on iOS and Android as you would with native apps, but for smaller teams this can be a huge time saver, especially in the early stages of a project.
So in a lot of cases it's not so much "web app" vs "native app", as "web app" vs "no app".
NodeJs is great,it's really,really powerfull and easy to use.I mean i did some crazy messaging/parrallel/realtime apps with that. At the same time, i'm not a big fan of javascript itself. It's not bad,it's just that I like more rigid,typesafe languages. I was a big fan of Actionscript 3 which is in my opinion some kind of compromise between dynamism and "statism".I'm glad i began programming in it by the way,or I would have never been able to learn java or C# afterwards.
It's overly verbose and useful for exactly one platform. Objective-C started out as a bunch of macros bolted on top of C and that ugliness is still obvious to me when I look at it. No, I don't think it's great at all.
I tried some stuff with Meteor a while back. I was very excited about the concept and really felt on board with the 'new way to write apps' stuff. It is pretty cool, but I was trying to implement a site where people could post stories and have an author badge appear on the page.
This requires joins. Mongo doesn't have joins, and Meteor doesn't even have fake joins, like Mongoose's 'populate'. There has been a lot written in the Meteor community about faking joins, as it is a persistent problem. First, I tried template helpers, but these are impossible to put into a nested template.
I looked at 5 different open source packages for serverside fake joins, but ended up doing a clientside solution (to get a feel for the 'basic' way to do things). This solution involved several functions on the clientside router, that would be called several times, with different data available each time. It is a convoluted thing to do, no matter the method.
Another thing I tried to do was purely clientside databinding, to populate the author badge in real time as the user fills a form. It's trivial to bind data to the database and have that update in realtime, but I wanted to hold off saving anything until the user hit the save button. Again, a simple task got weird. I ended up using an un-synced database collection, then saving to an identical, but synced collection.
I'm not writing off Meteor completely, but I ended up moving away from it. Node.js and a solid frontend framework have slightly more boilerplate, but are generally very flexible for whatever it is you want to do. In retrospect, one of the best things about Meteor is the one-line auth setup. This is usually a big pain, and it was nice to have it be so easy.
> It is pretty cool, but I was trying to implement a site where people could post stories and have an author badge appear on the page.
Meteorpedia, the site in the OP accomplishes this without joins. It has authors for pages. You just have to set up your schema in a way that's different from normalized SQL.
Along with my team, we built an enterprise app with meteor.js. Huge waste of resources.
I almost find that the single biggest barrier to fully investing in is Mongodb. The queries are hideous. But Meteor is heavily invested in Mongodb and I'm afraid this is what will kill it.
Meteor recently acquired FathomDB. Additionally SQL is on the cards too (http://roadmap.meteor.com) they're not exactly heavily invested in MongoDB. If anything it looks like they're giving users the choice of what to use.
If you've used other db like OrientDB, you can use SQL to query documents. Even if MongoDB added this I wouldn't rely on it, as there have been many deployments that couldn't scale properly due to MongoDB and ended up switching to another vendor. It already has the reputation of being snake oil salesman of the DB world.
Meteor in no way abstracts MongoDB away from the developer. Meteor is very tightly bound to Mongo, and Mongo permeates every aspect of coding in Meteor.
Could you make the source code of your app available so we (people who use Meteor) could take a look? Nothing that you're doing sounds hard or impossible with Meteor and I'd be glad to look through the code and help you figure out what to do to get it to work right.
Airsoc.com
Only uses mongodb, people can post stories, or articles, we show author and feed source information on the page, but there are no joins. I have never found the need to use joins anywhere. Carefull schema design makes them unnessecary.
You're confusing schema not being enforced for schema not being present. Any non-trivial app would require you to define a schema for your models, irrespective of whether you're using a relational database like Postgres or a document store like Mongo.
It's totally possible to load balance websockets. You turn the web sockets into a dumb proxy that talks to your service. You could have a bunch of SockJS servers, with people connecting to different ones communicate with each other over the actual service. If you were building chat rooms you could assign rooms to specific servers, or you could tailor your service such that it works across a distributed system.
We do something similar on BitMEX with SockJS. As long as you're not using AWS's ELB, load-balancing websockets is as easy as anything else. We use HAProxy to proxy the websocket connections as TCP, and round-robin the connections. If a server drops out, the websocket connection is disconnected and a reconnection occurs to an available server.
I think he means that if you're using a browser that doesn't support WebSockets, then SockJS's HTTP-based fallbacks will require sticky routing. If the browser does support WebSockets, then this is not a concern.
It's possible but what I meant (and failed to make clear) is that we can't actually avoid using cookies and scale up, since websockets connections aren't widely allowed on devices, calling for SockJS use and therefore, cookies adoption.
They aren't the ones who block it. Instead it's the infrastructure providers who do it.
Cloudfare started supporting it only a few months ago.
Many ISP's use proxies that disallows websockets connections.
Again, the point is: You can't claim you won't need cookies if you want to consider scaling up.
The appealing parts of Meteor is a built in security against common web insecurities.
The unappealing part of Meteor is having to learn Mongo. Ok, this part is just me being too comfortable with SQL relational table databases, and being too lazy to take the time to learn the alternatives.
The most unappealing part about any framework that claims to get you 90% there is that the 10% left is always loads of painful bullshit trying to wedge what you need into a, usually overly opinionated, overly rigid "the framework way" pattern.
Don't get me wrong, these things are fantastic for MVP/prototyping but nothing that claims to be one size fits all comes without hidden debt.
I agree with you 100%. This is why I began just vouching for micro-frameworks. Even that comes with hidden debt in the form of plugins or modules written by it's communities but it's a step above the 'write a shopping cart website in 5 minutes' type of framework.
I'm very happy with Flask because it complete gets out of the way, it's up to you to deal with pesistence, models. You choose your own sins type of approach.
The main Mongo problem imho, is when you have feature creep -- if you find out later that you must have joins. Relational databases are more flexible with changing requirements.
What if I just wanted to use Meteor for the same reason as what I currently use something like Firebase for? I'd like to combine this tool with React/Flux for the single purpose of server-side database functionality... not the entire kitchen sink. The closest thing I've found to showing how this could be done is Pete Hunt's react-meteor-preso project: https://github.com/petehunt/react-meteor-preso. This doesn't include Flex functionality, but it looks like a good start. It'd be awesome to have some more examples of this.
This "production ready" "specially for beginners" marketing about Meteor really needs to stop. They completely changed the API from under my feet, that is NOT production ready (nor for beginners, I would argue).
Stay away from Meteor until they hit 1.0, unless you're ready for pain.
I'm using Meteor and React for a side project, and compared to a previous project where I used Backbone and node.js it really is a 10x productivity boost. Since this is a side project I can spend at most an hour a day on, it really is the difference between being able to finish or not.
I just don't get this meteor.js fad. Its not even a production ready framework and yet I am seeing webapps being designed using it, meetups being held about it and blogs being written about it as if it is a breakthrough in programming web. I feel people should cool down and think it through if its architecture is even worth having or not.
same with node.js I fail to understand why someone would want to deal with javascript callback chains on the server side to build simple websites. Even some clients are convinced that somehow their application will run faster.
Even front-end frameworks like Backbone.js doesn't make sense to me. I still find using jQuery more than adequate.
node.js is useful for some specific things - specifically, doing real-time "plumbing" between data sources and sinks. There's a huge amount of libraries and support for doing that, that doesn't really exist in other communities.
So what do you use to build simple websites on the backend?
There are bad programmers and bad programming practices for every language. If you see code that has 5 levels of nested callback chains, it's only because people don't know how to write code. Have you see chromium code? It's filled with callback in c++. All this is nothing new.
Interesting, so what do you use to avoid nested callback chains? Use a workaround library? This just seems like brute force. I don't think you are required to use asynchronous callbacks in C++ to do anything, while in Node.js you are almost guaranteed to doing this.
Why would you write a CRUD app using Node.js when you can accomplish this in multitude of other well established methods? LAMP, Java, Python etc.
Nothing wrong with experimenting but for real world needs, there's no clear answer as to why you would need Node.js to redo what you used to do.
> I fail to understand why someone would want to deal with javascript callback chains on the server side to build simple websites.
I use Node/JS on the server b/c I'm hyper productive with it. Like all languages/frameworks/runtimes there are issues. But the speed of development is what keeps me on Node, despite the fact that other languages do not share some of the same weaknesses as JS.
The linked site won't display anything with Javascript disabled. Yet, when Javascript is enabled, we don't get a "web app", all we get is a page of text that could easily be coded in HTML and CSS. Presumably, building this site in meteor makes things easier for the developer. Does it make things easy for all users of the site? Look at the source code of the page after it's loaded.
...
<body>
</body>
</html>
What would a screen reader user hear? Is this site accessible? Does anyone really care?
Do sites like this point to a future where more and more web sites (not web apps) are built with Javascript frameworks? Is this a good thing? And can these sites acommodate all users? (Assuming they want to.)
On the one hand, it might be kind of disingenuous for a site about the Meteor framework to not actually be running on that framework - but on the other, I think you're right. While most users in general (not necessarily most users considering Meteor) will have javascript on by default without ad-blockers running (and it won't be an issue) there doesn't appear to be any particular client benefit to rendering a simple site like this from js.
>Do sites like this point to a future where more and more web sites (not web apps) are built with Javascript frameworks?
The pendulum does seem to be swinging in that direction. But i've seen enough posts on HN about how client-side templating has gone too far and wrecked user experience, and about developers 'rediscovering' how robust simple html/css can be, to suspect that nothing is inevitable. Trends come and go and paradigms fall in and out of fashion.
I try to approach things differently: why do people disable javascript? Is it because of security? There are ways to disable javascript only from third parties, for example, or disable certain functions (e.g. prevent alerts (natively in Chrome, or browsers extensions).
Screen readers should be able to get the current state of the page, and not read from the 'source'.
I can see some advantages of using javascript e.g. less load for the server to render things, it just becomes a directory host.
So when would you trigger the screen reader? When there is "enough content" rendered by JS? For sure not the way to go. Just dump Meteor, use React, there at least you can truly reuse the code and have it render server side.
Usability for everyone is important but basically every modern webapp is not usuable if you disable javascript. Its akin to disabling X11 and trying to use a desktop app, maybe a few fallback to a console program you can use but not many.
As for your other comments its like everything else you have your target users and you need to weigh the costs/benefits of having your app work for everyone vs. not at all for some users. If you're building an online mockup editor screen readers have zero importance, on the other hand if you're building a blog, screen readers might be very important. I think meteor does one thing quite well and thats make it easy to build "realtime webapps" i.e. webapps that have lots of user interaction/clicks, etc. This is not something you would use to build news site with lots of long text documents.
As a NoScript user I understand your point, but if screen readers can't handle dynamically generated content then they will need to evolve along with the rest of the web.
Is "accessibility" a major concern for developers? Should it be?
Did anybody ever stop to ask the masses of developers what they thought about it? And can anybody quote me the actual facts and figures around the oft-touted "need" for "accessibility"?
Because I know it's supposed to be an important concern. But it isn't a concern, in fact, for anyone I know in the business.
>What would a screen reader user hear? Is this site accessible? Does anyone really care?
Screen readers do support JavaScript. While server side rendering is one of the features I most want in Meteor, the whole "screen readers can't javascript" is just wrong.
One thing that scares me about meteor is performance and scalability. I'm afraid that if I build an app that takes off, I won't be able to afford the servers to keep the app running.
Good point, valid opinion, etc. But incorrect, I think. I think it's more likely that we are going to see most metropolitan areas in the US finally get world-class data/communications infrastructure installed. It's starting to build momentum now, really. And then there will be no going back. You will then be unable to convince the vast majority of enterprise users that they should pay for proprietary Java + server installations when they can get radically better functionality and useability from client-side technology, and at a VERY steep discount. I really think the only thing currently preventing a tidal wave of JavaScript dominance in enterprise is the (weird) reality that the US is still so retrograde on high-speed internet.
I don't think it has anything to do with the speed of the internet, rather you won't see large companies who paid millions for infrastructure built on Oracle or SAP come off it anytime soon. The people that spend this much on money won't be sold on the wonders of Javascript, that's not how they make their purchase decisions.
We've been using our Meteor-based, multi-tenant CRM/talent-management app in production for several months now. It's called Exartu and is open source hosted on github.
We originally wrote the app using sql and signalR and as we've done with many of company's (Tempworks Software) products, but we switched in no small part for the real-time reactivity offered natively in Meteor and the productivity gains from its packaging system.
At one point we used Knockout for all our binding but switched when Meteor's Blaze matured. The speed and simplicity of the templating engine coupled with the fact that js is used both client and server side reduces the learning curve as we add devs to the project.
Contrary to many comments here, I've really enjoyed using mongodb and find it fast and eminently suitable for a problem domain like CRM that is constantly in transition.
Our biggest problem with Meteor was that as a new platform there were no enterprise level apps to model after. We made the app open source (github->Exartu) in hopes to change that, and we welcome critiques to it.
79 comments
[ 3.3 ms ] story [ 145 ms ] threadI'm working on an alternative template engine for Meteor now based on django. Currently in a big branch that's moving slow since I'm pretty busy at my regular job.
https://github.com/btipling/djanglets
I'd love to hear if anyone has used meteor for something read and if they've had to deal with migrating to something else: how they've done it, and what issues they encountered.
For example, I love angular, but migrating away from angular after using it for one year would doubtless be a very painful process.
The app is http://anonquest.com/ It's a realtime story writing community. Be happy to answer questions.
I wish AngularJS’s dependency injection/forced modularity and HTML augmentation/templating were somehow independent and not requiring each other.
> if I outgrew this, how difficult would it be to migrate away from it?
I'm becoming successful at fighting my urge to migrate my projects away from things I outgrow. I reason that changed preferences alone should not constitute a reason to rewrite an existing and working solution. And in case costs of adapting existing solution are higher than costs of rewriting it from scratch, then this is probably due to some unfortunate design decisions or obscure libraries/frameworks used, so these are the things to avoid.
That was why I eventually switched to React after trying to find ways to have Angular-like components/bindings without the DI/IoC parts of Angular (even going as far as reimplementing parts of Angular).
If you only want the bindings, maybe rivets or knockout is an alternative?
I just want to make the distinction between that and JS frameworks that don't try to own your whole stack. Migrating from Angular is no more painful than migrating from Backbone. They're all frontend frameworks that talk to a rest api. When choosing between React, Backbone, Angular, Ember, etc ... it seems to me that migration effort shouldn't even be a consideration since a complete UI rewrite will be required in any case.
The whole idea of having to run phantom.js to render your website because search engine robots can't index your site reminds me awfully like trying to keep up with a high maintenance girl who is more trouble than she's worth.
The days of natively developing apps in Java and Objective-C have an apparent end in sight.
I love Node.js and Javascript. I wish this was true, but I can't bring myself to believe it yet.
Maybe you won't reach the same quality on iOS and Android as you would with native apps, but for smaller teams this can be a huge time saver, especially in the early stages of a project.
So in a lot of cases it's not so much "web app" vs "native app", as "web app" vs "no app".
NodeJs is great,it's really,really powerfull and easy to use.I mean i did some crazy messaging/parrallel/realtime apps with that. At the same time, i'm not a big fan of javascript itself. It's not bad,it's just that I like more rigid,typesafe languages. I was a big fan of Actionscript 3 which is in my opinion some kind of compromise between dynamism and "statism".I'm glad i began programming in it by the way,or I would have never been able to learn java or C# afterwards.
Once the Apple fad ends, Objective-C will be useless. It's already useless for the enterprise.
This requires joins. Mongo doesn't have joins, and Meteor doesn't even have fake joins, like Mongoose's 'populate'. There has been a lot written in the Meteor community about faking joins, as it is a persistent problem. First, I tried template helpers, but these are impossible to put into a nested template.
I looked at 5 different open source packages for serverside fake joins, but ended up doing a clientside solution (to get a feel for the 'basic' way to do things). This solution involved several functions on the clientside router, that would be called several times, with different data available each time. It is a convoluted thing to do, no matter the method.
Another thing I tried to do was purely clientside databinding, to populate the author badge in real time as the user fills a form. It's trivial to bind data to the database and have that update in realtime, but I wanted to hold off saving anything until the user hit the save button. Again, a simple task got weird. I ended up using an un-synced database collection, then saving to an identical, but synced collection.
I'm not writing off Meteor completely, but I ended up moving away from it. Node.js and a solid frontend framework have slightly more boilerplate, but are generally very flexible for whatever it is you want to do. In retrospect, one of the best things about Meteor is the one-line auth setup. This is usually a big pain, and it was nice to have it be so easy.
Meteorpedia, the site in the OP accomplishes this without joins. It has authors for pages. You just have to set up your schema in a way that's different from normalized SQL.
I almost find that the single biggest barrier to fully investing in is Mongodb. The queries are hideous. But Meteor is heavily invested in Mongodb and I'm afraid this is what will kill it.
My understanding was that, for better or worse, Meteor abstracts a lot of that from the developer.
Were you unhappy with the queries that Meteor generated?
Or did you find your application did not perform well, or in the way that you expected, and you believe this to be the result of the queries?
Or were there issues on the deployment/operations side of things?
I was excited and did 4 push-ups but it is a convoluted thing to do.
I'm not writing off exercise completely, but I ended up moving away from it.
Like what devices don't allow websockets? Android chrome, Mobile Safari and Desktop Chrome and Firefox do and that's like almost everyone right there.
Again, the point is: You can't claim you won't need cookies if you want to consider scaling up.
The unappealing part of Meteor is having to learn Mongo. Ok, this part is just me being too comfortable with SQL relational table databases, and being too lazy to take the time to learn the alternatives.
Don't get me wrong, these things are fantastic for MVP/prototyping but nothing that claims to be one size fits all comes without hidden debt.
I'm very happy with Flask because it complete gets out of the way, it's up to you to deal with pesistence, models. You choose your own sins type of approach.
The main Mongo problem imho, is when you have feature creep -- if you find out later that you must have joins. Relational databases are more flexible with changing requirements.
Stay away from Meteor until they hit 1.0, unless you're ready for pain.
Even front-end frameworks like Backbone.js doesn't make sense to me. I still find using jQuery more than adequate.
There are bad programmers and bad programming practices for every language. If you see code that has 5 levels of nested callback chains, it's only because people don't know how to write code. Have you see chromium code? It's filled with callback in c++. All this is nothing new.
Why would you write a CRUD app using Node.js when you can accomplish this in multitude of other well established methods? LAMP, Java, Python etc.
Nothing wrong with experimenting but for real world needs, there's no clear answer as to why you would need Node.js to redo what you used to do.
I use Node/JS on the server b/c I'm hyper productive with it. Like all languages/frameworks/runtimes there are issues. But the speed of development is what keeps me on Node, despite the fact that other languages do not share some of the same weaknesses as JS.
Do sites like this point to a future where more and more web sites (not web apps) are built with Javascript frameworks? Is this a good thing? And can these sites acommodate all users? (Assuming they want to.)
>Do sites like this point to a future where more and more web sites (not web apps) are built with Javascript frameworks?
The pendulum does seem to be swinging in that direction. But i've seen enough posts on HN about how client-side templating has gone too far and wrecked user experience, and about developers 'rediscovering' how robust simple html/css can be, to suspect that nothing is inevitable. Trends come and go and paradigms fall in and out of fashion.
Screen readers should be able to get the current state of the page, and not read from the 'source'.
I can see some advantages of using javascript e.g. less load for the server to render things, it just becomes a directory host.
As for your other comments its like everything else you have your target users and you need to weigh the costs/benefits of having your app work for everyone vs. not at all for some users. If you're building an online mockup editor screen readers have zero importance, on the other hand if you're building a blog, screen readers might be very important. I think meteor does one thing quite well and thats make it easy to build "realtime webapps" i.e. webapps that have lots of user interaction/clicks, etc. This is not something you would use to build news site with lots of long text documents.
Did anybody ever stop to ask the masses of developers what they thought about it? And can anybody quote me the actual facts and figures around the oft-touted "need" for "accessibility"?
Because I know it's supposed to be an important concern. But it isn't a concern, in fact, for anyone I know in the business.
Screen readers do support JavaScript. While server side rendering is one of the features I most want in Meteor, the whole "screen readers can't javascript" is just wrong.
We originally wrote the app using sql and signalR and as we've done with many of company's (Tempworks Software) products, but we switched in no small part for the real-time reactivity offered natively in Meteor and the productivity gains from its packaging system.
At one point we used Knockout for all our binding but switched when Meteor's Blaze matured. The speed and simplicity of the templating engine coupled with the fact that js is used both client and server side reduces the learning curve as we add devs to the project.
Contrary to many comments here, I've really enjoyed using mongodb and find it fast and eminently suitable for a problem domain like CRM that is constantly in transition.
Our biggest problem with Meteor was that as a new platform there were no enterprise level apps to model after. We made the app open source (github->Exartu) in hopes to change that, and we welcome critiques to it.