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.
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.
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.
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.
> 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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.)
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.
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.
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.
>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.
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.
[+] [-] woah|11 years ago|reply
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.
[+] [-] swartkrans|11 years ago|reply
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.
[+] [-] primigenus|11 years ago|reply
[+] [-] thawkins|11 years ago|reply
[+] [-] purpletoned|11 years ago|reply
[+] [-] notastartup|11 years ago|reply
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.
[+] [-] greggdourg|11 years ago|reply
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.
[+] [-] TheAceOfHearts|11 years ago|reply
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.
[+] [-] KaoruAoiShiho|11 years ago|reply
The app is http://anonquest.com/ It's a realtime story writing community. Be happy to answer questions.
[+] [-] goblin89|11 years ago|reply
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.
[+] [-] lopatin|11 years ago|reply
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.
[+] [-] swartkrans|11 years ago|reply
[+] [-] vqc|11 years ago|reply
[+] [-] kyllo|11 years ago|reply
[+] [-] joshkpeterson|11 years ago|reply
[+] [-] davedx|11 years ago|reply
Stay away from Meteor until they hit 1.0, unless you're ready for pain.
[+] [-] primigenus|11 years ago|reply
[+] [-] codesuela|11 years ago|reply
[+] [-] shubhamjain|11 years ago|reply
[+] [-] general_failure|11 years ago|reply
[+] [-] notastartup|11 years ago|reply
Even front-end frameworks like Backbone.js doesn't make sense to me. I still find using jQuery more than adequate.
[+] [-] imslavko|11 years ago|reply
[+] [-] btipling|11 years ago|reply
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.
https://github.com/btipling/djanglets
[+] [-] greggdourg|11 years ago|reply
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.
[+] [-] leke|11 years ago|reply
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.
[+] [-] weego|11 years ago|reply
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.
[+] [-] BugBrother|11 years ago|reply
[deleted]
[+] [-] andremendes|11 years ago|reply
[+] [-] swartkrans|11 years ago|reply
[+] [-] vuldin|11 years ago|reply
[+] [-] pscanf|11 years ago|reply
[+] [-] adam74|11 years ago|reply
[+] [-] lingoberry|11 years ago|reply
[+] [-] drewblaisdell|11 years ago|reply
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.
[+] [-] aikah|11 years ago|reply
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.
[+] [-] BuckRogers|11 years ago|reply
[+] [-] chaostheory|11 years ago|reply
[+] [-] chestnut-tree|11 years ago|reply
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.)
[+] [-] toxicFork|11 years ago|reply
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.
[+] [-] krapp|11 years ago|reply
>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.
[+] [-] jfaucett|11 years ago|reply
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.
[+] [-] ogig|11 years ago|reply
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.
[+] [-] nhebb|11 years ago|reply
[+] [-] uptownJimmy|11 years ago|reply
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.
[+] [-] unknown|11 years ago|reply
[deleted]