Getting started with Meteor.js(joshowens.me)
joshowens.me
Getting started with Meteor.js
http://joshowens.me/getting-started-with-meteor-js/
40 comments
One thing I was surprised to run into is how basic CRUD operations don't have an out-of-the-box solution, like they did even with Rails many years ago.
When I read the "Discover Meteor" guide and they got to the part about handling submit buttons by writing jQuery handlers with e.preventDefault and all that, I was really surprised. Similarly I didn't see obvious, baked-in solutions to validation, or sharing templates between "edit" and "create" situations.
Then, there's the built-in Meteor accounts stuff, which does not make it easy to create an admin page for users, which again I expected to be a straightfoward task. And, not only that, but once you do start to build that you read more-and-more about how allowing the client to make certain modifications is insecure, and so you should start pushing things back to Meteor methods...
Anyway, a lot of this stuff has given me pause. I love the runtime speed, but the speed of getting something up and running (in terms of dev time) seems considerably slower than the equivalent in Rails, particularly around basic CRUD operations that you just need to get out of the way before you can build the more interesting stuff.
When I read the "Discover Meteor" guide and they got to the part about handling submit buttons by writing jQuery handlers with e.preventDefault and all that, I was really surprised. Similarly I didn't see obvious, baked-in solutions to validation, or sharing templates between "edit" and "create" situations.
Then, there's the built-in Meteor accounts stuff, which does not make it easy to create an admin page for users, which again I expected to be a straightfoward task. And, not only that, but once you do start to build that you read more-and-more about how allowing the client to make certain modifications is insecure, and so you should start pushing things back to Meteor methods...
Anyway, a lot of this stuff has given me pause. I love the runtime speed, but the speed of getting something up and running (in terms of dev time) seems considerably slower than the equivalent in Rails, particularly around basic CRUD operations that you just need to get out of the way before you can build the more interesting stuff.
While not baked into the framework itself, I've found a few repositories that aim to make CRUD a bit easier: https://github.com/aldeed/meteor-autoform/ https://github.com/aldeed/meteor-simple-schema/
You aren't tied to MongoDB.
You can switch to Firebase (https://atmospherejs.com/mrt/firebase) or Parse or even REST APIs if you want. Someone is even writing a reactive MySQL driver (https://github.com/numtel/meteor-mysql).
You can switch to Firebase (https://atmospherejs.com/mrt/firebase) or Parse or even REST APIs if you want. Someone is even writing a reactive MySQL driver (https://github.com/numtel/meteor-mysql).
1. The fact that one must hack together Meteor with anyting other than MongoDB effectively makes it "tied to MongoDB". Most people who want to engage in this level of hackery in their spare time would, I think, just ignore Meteor and dive straight into some version of the MEAN stack.
2. Because that's the whole point of Meteor: that it doesn't require the same level of server-side savviness and hackery that server-side JavaScript usually requires. Meteor is trying to be something like Rails, where the barriers to entry are not quite so prohibitive for quite so many aspiring developers.
3. Meteor must have official support for one (or more) of the SQL db's in order to take off. That's not all it needs, but it's a big one. I'm interested in seeing how SQL support is implemented, and I assume we're talking some sort of ORM, but we'll see.
2. Because that's the whole point of Meteor: that it doesn't require the same level of server-side savviness and hackery that server-side JavaScript usually requires. Meteor is trying to be something like Rails, where the barriers to entry are not quite so prohibitive for quite so many aspiring developers.
3. Meteor must have official support for one (or more) of the SQL db's in order to take off. That's not all it needs, but it's a big one. I'm interested in seeing how SQL support is implemented, and I assume we're talking some sort of ORM, but we'll see.
Completely agreed. Without real proper officially supported SQL db connectors, I don't think meteor will really take off.
I say this as someone who has used it and like a lot of the features. I just can't see myself taking something to production on mongoDB.
Also, now that the meteorJS codebase is stabilizing, I think it may be time for some conventions to mature around it. Right now, it's essentially the wild west of JS.
I say this as someone who has used it and like a lot of the features. I just can't see myself taking something to production on mongoDB.
Also, now that the meteorJS codebase is stabilizing, I think it may be time for some conventions to mature around it. Right now, it's essentially the wild west of JS.
Agreed as well, with the one qualifier - "yet". It was not very long ago that Meteor lacked something as simple as authentication and method protections. While it's not clear when some of these features will arrive 100%, they will come eventually through a community-driven effort or through an officially sponsored implementation.
Yeah the lack of SQL db connectors is really surprising for a 1.0 platform; I'm sure it's going to be tricky to implement that so I give them a bit of pass on that front.
The lack of out of the box other NoSQL options is puzzling though because NoSQL db's are a lot close to each other than pure SQL is. And given the general disdain for MongoDB these days, it seems that uncoupling from that dependency would be a high priority. I'm sure there are plenty people on HN that simply won't even give it the time of day because of MongoDB.
The lack of out of the box other NoSQL options is puzzling though because NoSQL db's are a lot close to each other than pure SQL is. And given the general disdain for MongoDB these days, it seems that uncoupling from that dependency would be a high priority. I'm sure there are plenty people on HN that simply won't even give it the time of day because of MongoDB.
SQL Support:
You can query data from SQL; just include necessary NPM driver and you're away. It wont be "Realtime" though.
Other NoSQL Support: The realtime driver is the problem here.
Meteor creates "live queries" by tailing the MongoDB oplog. This works in part because "Minimongo" a javascript based mongo query engine can examine the oplog and determine what does & doesn't match a live query.
To support another NoSQL solution, this huge engineering effort would need to be reproduced.
To support "Realtime" SQL, they'd need to hook in to something like PostgreSQL 9.4's logical replication, and have a javascript based query-compiler & interpreter. (Or provide a mongo-like interface to SQL.) Not impossible, but not easy by all means.
I somewhat agree with the Grandparent (re: Firebase/Parse) - However, I'd like to see the Meteor team have their own realtime database; as the realtime paradigm changes how a lot of it would be built.
You can query data from SQL; just include necessary NPM driver and you're away. It wont be "Realtime" though.
Other NoSQL Support: The realtime driver is the problem here.
Meteor creates "live queries" by tailing the MongoDB oplog. This works in part because "Minimongo" a javascript based mongo query engine can examine the oplog and determine what does & doesn't match a live query.
To support another NoSQL solution, this huge engineering effort would need to be reproduced.
To support "Realtime" SQL, they'd need to hook in to something like PostgreSQL 9.4's logical replication, and have a javascript based query-compiler & interpreter. (Or provide a mongo-like interface to SQL.) Not impossible, but not easy by all means.
I somewhat agree with the Grandparent (re: Firebase/Parse) - However, I'd like to see the Meteor team have their own realtime database; as the realtime paradigm changes how a lot of it would be built.
What would be your hesitations taking mongoDB into production?
Personally, the lack of transactions & ACID compliance bother me - but Mongo 3.0 (Coming in March) should alleviate those concerns. [1]
[1] http://www.mongodb.com/blog/post/announcing-mongodb-30
Personally, the lack of transactions & ACID compliance bother me - but Mongo 3.0 (Coming in March) should alleviate those concerns. [1]
[1] http://www.mongodb.com/blog/post/announcing-mongodb-30
MongoDB is notorious for losing data. That alone is a deal-killer, and reason enough to stay away.
The slightly more complicated thing: it isn't even necessary for us to reinvent the database wheel, except for the fact that SQL is hard. Lots of people spend their entire careers avoiding SQL like the plague, which is okay because they have an SQL-ninja down the hall handing them queries to plug into their code. But for a lot of open-source weirdos, that ain't happening, because there's no SQL-ninja down the hall, just more JavaScript hipsters and Rails hippies. So Monongo!
Problem is, it ain't cool to lose your client's data. It's a career disaster. NoSQL is gonna have to get a LOT more robust before most professionals will accept it as a swap-in for SQL.
Lastly, and this is kinda the heart of it for me, is this: data is almost always inherently relational. And we simply haven't come up with anything better than SQL to manage this relationality. Maybe we will, I don't know. Meanwhile, it doesn't take a Bearded Old Programmer to see that there's something a little too bubbly about Mongo and its NoSQL kin.
The slightly more complicated thing: it isn't even necessary for us to reinvent the database wheel, except for the fact that SQL is hard. Lots of people spend their entire careers avoiding SQL like the plague, which is okay because they have an SQL-ninja down the hall handing them queries to plug into their code. But for a lot of open-source weirdos, that ain't happening, because there's no SQL-ninja down the hall, just more JavaScript hipsters and Rails hippies. So Monongo!
Problem is, it ain't cool to lose your client's data. It's a career disaster. NoSQL is gonna have to get a LOT more robust before most professionals will accept it as a swap-in for SQL.
Lastly, and this is kinda the heart of it for me, is this: data is almost always inherently relational. And we simply haven't come up with anything better than SQL to manage this relationality. Maybe we will, I don't know. Meanwhile, it doesn't take a Bearded Old Programmer to see that there's something a little too bubbly about Mongo and its NoSQL kin.
That is a perfect explanation, that I was looking to make.
Not to say mongoDB and noSQl don't have their place, but I don't think that place is, all of your application's data.
Not to say mongoDB and noSQl don't have their place, but I don't think that place is, all of your application's data.
Thanks for your reply.
I was asking to see if there was any crucial evaluation I had missed putting MongoDB into production.
Below are a few replies to the points you raised:
---------
Data Loss:
Agreed this is a big cloud over the head of MongoDB -
Is it still notorious for this in recent times? Hopefully DBA's for Mongo now have more experience, and the software has matured enough that this isn't a common problem. - or more than it would be for any database.
Even then, you can only fall so far if you take regular backups, and have a fail-over & data recovery plan.
--------
"SQL is hard":
I get your point - a lot of people don't like or understand SQL. However, you seem to lump them with everyone who would appreciate an alternative interface.
Personally, I quite like SQL - some would call me an SQL-ninja. However, I don't think we should be limited to SQL as the one-true-way for accessing data.
Sometimes these new "NoSQL" interface allows new technologies to emerge. For example, the reason MongoDB is being used with Meteor is two-fold:
1. Minimongo - A wholly javascript based mongo query engine. It would be a much harder engineering problem to build a similar tool for SQL / PostgreSQL. 2. Logical Replication - A Meteor instance is effectively a logical replica of the Mongo Database - only for "live" queries, which it interprets using (1)
(1) Means that queries/ their surrounding code can be isomorphic (same on client and server). To replicate this for SQL would be a huge engineering challenge. How would you even replicate complex joins etc?
(2) Logical replication was only made available in PostgreSQL 9.4 - but without a pluggable query interpreter [even for join-less queries], it still wouldn't work.
----------
Relational Data:
Agreed, that data itself is best decomposed into fully-normalised form (Even up to 6th Normal form if you like temporal data). This allows for single-location, conflict-free and consistent updates/inserts/deletes.
But data usage is inherently document based - and the generation of those documents from fully normalised data, on huge data sets with complex relations, is a massive problem!
Until we have better tools for managing documents made of relational data - eg. PostgreSQL materialised views, but update only invalidated rows, - there will still be a drive to store data (& maintain) in the format that it is read.
I was asking to see if there was any crucial evaluation I had missed putting MongoDB into production.
Below are a few replies to the points you raised:
---------
Data Loss:
Agreed this is a big cloud over the head of MongoDB -
Is it still notorious for this in recent times? Hopefully DBA's for Mongo now have more experience, and the software has matured enough that this isn't a common problem. - or more than it would be for any database.
Even then, you can only fall so far if you take regular backups, and have a fail-over & data recovery plan.
--------
"SQL is hard":
I get your point - a lot of people don't like or understand SQL. However, you seem to lump them with everyone who would appreciate an alternative interface.
Personally, I quite like SQL - some would call me an SQL-ninja. However, I don't think we should be limited to SQL as the one-true-way for accessing data.
Sometimes these new "NoSQL" interface allows new technologies to emerge. For example, the reason MongoDB is being used with Meteor is two-fold:
1. Minimongo - A wholly javascript based mongo query engine. It would be a much harder engineering problem to build a similar tool for SQL / PostgreSQL. 2. Logical Replication - A Meteor instance is effectively a logical replica of the Mongo Database - only for "live" queries, which it interprets using (1)
(1) Means that queries/ their surrounding code can be isomorphic (same on client and server). To replicate this for SQL would be a huge engineering challenge. How would you even replicate complex joins etc?
(2) Logical replication was only made available in PostgreSQL 9.4 - but without a pluggable query interpreter [even for join-less queries], it still wouldn't work.
----------
Relational Data:
Agreed, that data itself is best decomposed into fully-normalised form (Even up to 6th Normal form if you like temporal data). This allows for single-location, conflict-free and consistent updates/inserts/deletes.
But data usage is inherently document based - and the generation of those documents from fully normalised data, on huge data sets with complex relations, is a massive problem!
Until we have better tools for managing documents made of relational data - eg. PostgreSQL materialised views, but update only invalidated rows, - there will still be a drive to store data (& maintain) in the format that it is read.
Ditto: so much about Meteor just makes the day-to-day work of building something a real pleasure compared to other tools.
For me, the thing really holding it back from more serious work is that I've had real problems getting testing to work well: Velocity[1] has had a bunch of problems for me.
I hope things like the focus on MongoDB and the lack of good automated testing tools are just because Meteor is still fairly immature. It could be a really good tool for a lot of use-cases.
[1]: http://velocity.meteor.com
For me, the thing really holding it back from more serious work is that I've had real problems getting testing to work well: Velocity[1] has had a bunch of problems for me.
I hope things like the focus on MongoDB and the lack of good automated testing tools are just because Meteor is still fairly immature. It could be a really good tool for a lot of use-cases.
[1]: http://velocity.meteor.com
The lack of a testing story for Meteor was what really stalled my side project with it. Since then, Velocity has become the official testing framework but I haven't gotten the chance to dig into it. I'm disappointed to hear you've had a bunch of problems with it, as I was hoping all my testing problems would be solved next time I returned to Meteor.
I've been using Meteor for sideprojects to learn Javascript. While I like the ecosystem and meteor itself, I have found it hard (as someone new to Javascript itself) to learn "best practices" while using Meteor. I've tried several times to use different testing frameworks, but I end up getting frustrated with not knowing what I need to mock, how I should package things, etc.
meteor as a lot of "specifics" that what I don't like about it.
On first glance I thought this was a joke:
"Required
Javascript - JS first?! Yes soldier, don't question me again or I will karate chop you!
Shell (Terminal)
HTML & CSS
JSON
MongoDB
Handlebars
Git & GitHub
jQuery
LESS and/or SASS
Underscore and/or Lo-Dash
Bootstrap
NodeJS
Cordova
ElasticSearch
Ionic - Meteor Package Meteoric "
Then immediately following, "Now that you know the above you are deemed worthy to tap into the power and awesomeness of Meteor!"
Meteor's probably a good framework (I wouldn't know one way or the other since I haven't tried it), but from that summary it doesn't seem like an easy sell to someone looking for a framework to use.
"Required
Javascript - JS first?! Yes soldier, don't question me again or I will karate chop you!
Shell (Terminal)
HTML & CSS
JSON
MongoDB
Handlebars
Git & GitHub
jQuery
LESS and/or SASS
Underscore and/or Lo-Dash
Bootstrap
NodeJS
Cordova
ElasticSearch
Ionic - Meteor Package Meteoric "
Then immediately following, "Now that you know the above you are deemed worthy to tap into the power and awesomeness of Meteor!"
Meteor's probably a good framework (I wouldn't know one way or the other since I haven't tried it), but from that summary it doesn't seem like an easy sell to someone looking for a framework to use.
The author was trying to point out how many different pieces you'd have to hack together to get to the equivalent of what Meteor gives you out of the box.
So no, you don't need to install all that other stuff to use Meteor if that's what you took the author to mean.
So no, you don't need to install all that other stuff to use Meteor if that's what you took the author to mean.
GitHub as a requirement? So, I can't write a Meteor app without GitHub? :(
Thanks for this. I'm brand new to Meteor and have been looking for resources.
Does anyone have an idea of when the official Windows installation will be released? I've been struggling with trying to get this working correctly on my windows pc and signed up for their email list when it comes out. Hopefully soon?
Does anyone have an idea of when the official Windows installation will be released? I've been struggling with trying to get this working correctly on my windows pc and signed up for their email list when it comes out. Hopefully soon?
This is actively being worked on by core developers. See https://github.com/meteor/meteor/wiki/Preview-of-Meteor-on-W... if you want to try the pre-release.
How did i miss this? Thanks so much!
I don't have a date, but I believe it is the next major item on the core development group's checklist. https://trello.com/b/hjBDflxp/meteor-roadmap
For any kind of serverside development I recommend you get a Linux VM. I too prefer to develop on windows but one must understand that in this day and age no one will take you seriously of you host on Windows.
> one must understand that in this day and age no one will take you seriously of you host on Windows.
Must I? We clearly don't talk to the same people, then. Not only have I never judged someone or something based on what web host they use (seriously?), I've never heard anyone say or intimate that they would, either.
Must I? We clearly don't talk to the same people, then. Not only have I never judged someone or something based on what web host they use (seriously?), I've never heard anyone say or intimate that they would, either.
Totally agree.
Reminds me of my favorite Mac Joke though I think it could apply to Linux folks too so feel free to swop it out. ;)
"How can you tell a Mac user? Answer: They tell you"
A network support guy laid that on me a few years back, I thought it was hilarious because it's so true. I have since stopped mentioning I'm a mac user...
Reminds me of my favorite Mac Joke though I think it could apply to Linux folks too so feel free to swop it out. ;)
"How can you tell a Mac user? Answer: They tell you"
A network support guy laid that on me a few years back, I thought it was hilarious because it's so true. I have since stopped mentioning I'm a mac user...
> I've never heard anyone say or intimate that they would, either.
I'm completely in agreement with you. Unfortunately I've been to a handful of tech meetups where I've heard this exact phrase. It's like they look down on me for using windows :( I dunno, maybe it's my limited perspective but I've actually been feeling like I'm not taken as seriously when I show up to tech meetups with my thinkpad.
I'm completely in agreement with you. Unfortunately I've been to a handful of tech meetups where I've heard this exact phrase. It's like they look down on me for using windows :( I dunno, maybe it's my limited perspective but I've actually been feeling like I'm not taken as seriously when I show up to tech meetups with my thinkpad.
Honestly I think the issue really is with the compatibility problems you run into, especially when trying out newer stuff that was written to targin linux/mac first and foremost. You don't always run into issues, but every now and then you get some node-gyp build snafu or something that causes you to go on a google-fest for potentially obscure fixes. I've had a win7 laptop as my main machine for awhile, and generally did most of my development either in a vagrant VM or using Cloud 9 (fixes build issues and allows me to work on it everywhere). I think having a mac or using linux just makes your life a lot easier as a developer as long as you aren't doing .NET. Suddenly all the tutorials, example code, and default installation instructions just work.
I am of course exaggerating and it seems that you see me as "jud[ing] someone" for their choices, which I am not. What I attempted to communicate is that linux (unix?) seems to be the lingua franca of the server world. Sure there are ways to get Mongo or Redis to work on Windows. But why would you? You can scratch your head using your foot. But why would you?
You can also try meteor inside Docker https://github.com/grigio/docker-meteor
I found this, hope it helps:
http://win.meteor.com
thank you! For the moment I was using https://www.nitrous.io/ but this looks like it could be a solution to develop locally
Meteor is cool but component based architecture is even better and Meteor doesn't really lend it's hand to that. It's a lot of dom action binding/coupling.
Thanks for sharing this with HN :)
My pleasure. I like this meta-introducation approach - i.e. when there is abundance of introductions its worth make an introduction to introductions.
As a side note, one of things that made me using Meteor.js is the easiness of starting (largely to great official examples and tutorials).
BTW: I highly recommend Discover Meteor by Sacha Greif & Tom Coleman (https://www.discovermeteor.com/). One of the best tutorial books I went through.
As a side note, one of things that made me using Meteor.js is the easiness of starting (largely to great official examples and tutorials).
BTW: I highly recommend Discover Meteor by Sacha Greif & Tom Coleman (https://www.discovermeteor.com/). One of the best tutorial books I went through.
Question as an aspiring web developer with a moderate-high degree of comfort in Javascript, and low-moderate comfort in Ruby: would you recommend giving 100% to mastering Rails, or dabbling with Meteor from time to time?
The aim is to not get a job as a developer, but build my own projects.
Apologies if this kind of question is better suited for Stackoverflow
The aim is to not get a job as a developer, but build my own projects.
Apologies if this kind of question is better suited for Stackoverflow
For side small side projects, where you want start and move quickly - I totally recommend Meteor. Before knowing _any_ framework I started reading on Meteor - and literally in hours, I had a simple app.
(Actually, it's how I use it. I am mainly data scientist; I do some webdev, but its not my main thing.)
(Actually, it's how I use it. I am mainly data scientist; I do some webdev, but its not my main thing.)
@joshowens, one more comment - the compilation is excellent, but for packages I think that (especially for a newcomer) it would be better to add a one sentence desc per package (especially as one do not need to start with learning all of them!) rather than providing 3 links (if one wish, one can easily jump from Atmosphere to GitHub).
I wish there was an easy way to use a different database although I get it, it's part of what makes Meteor so easy get something up and running quickly.
My gut is that if Meteor weren't solely tied to MongoDB and instead had an easy way to switch to Firebase, Parse, etc this platform would really take off.