13 ms·

Getting Meteor to 1.0

93 points by yaliceme 13y ago

pdfcollect 13y ago
Any hope of writing/supporting meteor with python backend? :)
- geoffschmidt 13y ago
  Sure! The Meteor client and the Meteor server speak a protocol called DDP, which runs over websockets or HTTP long polling. Meteor clients can connect to any DDP server and vice versa. So you just need to implement a DDP server for Python. DDP is pretty simple (just a few messages) and the spec for the 'pre1' version of the protocol is in Git: https://github.com/meteor/meteor/blob/devel/packages/livedata/DDP.md https://github.com/meteor/meteor/blob/devel/packages/livedat... This is pretty close to version '1' of the protocol that will be locked down in Meteor 1.0: https://trello.com/c/kMkw800Z/53-official-ddp-specification https://trello.com/c/kMkw800Z/53-official-ddp-specification
  - 1qaz2wsx3edc 13y ago
    I love the DDP as a concept. It's akin to REST-on-steroids, over a websocket with pubsubhubbub sprinkled on top. I really wish more people knew about it, I hope drivers are adapted quickly (some have been). Interoperability & extensibility will make it a killer web feature.
    - sgdesign 13y ago
      Here's an interesting project which uses DDP to talk with a Raspberry Pi: http://pijs.io/ http://pijs.io/
    - icebraining 13y ago
      I know I sound like a fundamentalist, but how is anything like REST? It's an RPC protocol! Nothing against RPC, but it doesn't fit any of the REST constraints, except for the client-server; it's not stateless, it can't have middle-man caching and it doesn't really follow an uniform interface. It's nothing like REST (and as such it doesn't get its benefits).
      - geoffschmidt 13y ago
        Speaking as the protocol designer, the eventual intention for DDP is to model reactive data set publishing in a sufficiently semantic way that it can be cached by proxies. We didn't get there in pre1 and decided to not let that block Meteor 1.0, but it is the goal for the future when we have some post-1.0 breathing room (and when the Meteor community needs it.) The idea behind DDP is that HTTP got us three huge benefits: (1) shared tooling (I can write a caching proxy, and anyone with a website can use it); (2) interchangeable parts (your client and your server can be built with totally different languages and frameworks); and (3) easy APIs (I can describe my site's REST-y API to you in a page or two). These days, a lot of sites are moving away from REST/HTTP and toward ad-hoc, custom publishing schemes that run over websockets or a HTTP long-polling transport that is emulating websockets. Since they use these ad-hoc protocols to move around data rather than something like REST, they lose (1), (2), and (3). But all of these ad-hoc protocols are basically isomorphic to each other. DDP is an attempt to nail this kernel of data publishing functionality down semantically to the point that you can get those three benefits back. As an aside, what's the pressure that's pushing these apps away from REST? The two big ones are: - They cache data locally and need to keep the cache fresh (say they are apps that run in your browser and never reload the page, or they are native mobile apps), and they don't want to poll for updates. And/or, - They need to do joins and they care about latency. (When you are loading the news feed, you want to fetch the feed stories, the comments, and the userpic URLs in one round trip, not first request the stories, and then only once you have them request the comments.) Also, many modern apps have verbs that don't map well to REST (a RPC like transferBalance affects multiple objects and doesn't map well to the idea of updating the representation of an object identified by a URL), and many modern apps need to perform some form of latency compensation (predicting the outcome of a RPC and simulating it locally to update the client's display while waiting for the server's answer, but then reverting to the authoritative outcome chosen by the server.) DDP attempts to address these needs and run over a stream transport like websockets, while recovering some of the benefits of standardization that made REST so successful.
        icebraining 13y ago
        Thanks; I can perfectly understand the advantages of having a standard protocol, and if DDP becomes an effective standard for applications outside of Meteor, it'll be a great achievement. I just wish people were more aware of what REST really means. DDP seems like a good technology for webapps, but the issue is that I find webapps a really uninspiring trend in web development; my vision for the web is much more data-oriented than the code silos we're all making. And I believe the lack of understanding of what REST means is preventing people from seeing a bigger picture. Also, many modern apps have verbs that don't map well to REST (a RPC like transferBalance affects multiple objects and doesn't map well to the idea of updating the representation of an object identified by a URL) I've heard that a lot, and I don't doubt that it's true in many cases, but usually it seems more representative of a difficulty in the modeling process. For example, a transferBalance call certainly doesn't map well to updating any object, but creating a new Transfer (and passing the URLs of both Accounts) would be perfectly RESTful, in my opinion.
sonnym 13y ago
After seeing the first, extremely slick demo of meteor, I was, as I believe a lot of people were, extremely excited to see where the project would go. Then came the funding, and some twelve or sixteen months of development, and I finally decided to dive in. I really wanted to like it. I was predisposed to do so. But from the very beginning, I was confronted with something I consider a deal breaker. While I am wary and generally disinclined toward the increasingly popular pattern of curl an installation script and pipe into sh, in this case it is not only skeptical, it is downright ludicrous. Why would I, nay anyone, want to install an npm package this way? Should not the installation instructions simply be `npm install -g meteor`? And what if I need to work on multiple meteor projects with different versions? Surely there is support for adding it to your package.json file, but why is this not the primary means of installation and well documented? Maybe I am being overly sensitive to these issues, but it really baffled me that the very foundation upon which a meteor project is predicated would be contradictory to the typical node workflow. I will probably try meteor to spike out a project at some point in time, but I do not foresee myself using it extensively in the near future.
- misuba 13y ago
  npm install -g meteorite Then create a site with it and specify whatever local version of meteor you want. The deets: https://github.com/oortcloud/meteorite/ https://github.com/oortcloud/meteorite/
  - geoffschmidt 13y ago
    Meteor version locking is in core now (as of 0.6.0), and the rest of Meteorite (fetching packages from Atmosphere) will be folded into core as part of 1.0 :)
- flylib 13y ago
  it's because your getting a full mongo database installed and configured with it
- geoffschmidt 13y ago
  Meteor is a lot more than an npm package. For example, if you type these four commands.. $ curl https://install.meteor.com https://install.meteor.com | /bin/sh; meteor create myapp; cd myapp; meteor you're up and running with a complete stack including MongoDB, node, the dozen-ish core packages that make up the Meteor pubsub and realtime templating stack, and the 'meteor' build tool (which can do things like compile coffeescript and less, generate source maps, minify your production code, and provide a realtime development environment where whenever you save a file your app updates in your browser.) As for versioning, it's actually got a great way of doing that. Each of your Meteor projects is locked to a specific Meteor release version (similar to an Ubuntu release, it's a release-engineered snapshot of the Meteor core packages), which you can set with the `meteor update` command. And this has automatic `npm shrinkwrap` integration so that if you use npm packages alongside Meteor packages, everyone on your team is always running exactly the same versions of all of the code in your app. The Meteor tools automatically handle all the work of downloading any needed Meteor versions and keeping them installed side-by-side on your laptop, using the correct one for a given project, and notifying you of available updates.
rglover 13y ago
Thanks for posting this. Great overview of what to look forward to. As someone writing an app in production based on 0.6.5, should I plan on any big "rewrites" as the framework approaches 1.0? A better question might be, what will be backwards compatible and what will I have to scrap? It sounds like packages are the one area I should be the most careful with...
- akbar501 13y ago
  There will be breaking changes as Meteor moves from 0.6.5.1 to 0.7 to 0.8 up until it reaches 1.0. This is part of the bargain of working with pre 1.0 software (APIs etc. will be stabilized once 1.0 is reached). I have found these "breaks" are minor and usually require a few minutes to fix. That said, I also tend to lag behind by a few weeks as other in the community work through the details of the breaking changes. Meteor Hacks (http://meteorhacks.com http://meteorhacks.com) and EventedMind (https://www.eventedmind.com https://www.eventedmind.com) are two great resources.
barkingcat 13y ago
I'd love to see freebsd support for the install scripts. Last I looked support was in its infancy. Maybe I should revisit.
sgdesign 13y ago
If you're curious about Meteor, I recently wrote a short introduction to it from the point of view of front-end JS developers: https://www.discovermeteor.com/2013/09/17/meteor-for-front-end-engineers/ https://www.discovermeteor.com/2013/09/17/meteor-for-front-e...
akbar501 13y ago
Congrats to the MDG team on having 1.0 within reach, and thanks for releasing an amazing platform. Meteor is one of those platforms that you should try. I could give you a menu of features, but the productivity boost from Meteor is one of those things you really should experience. The productivity boost is very real and its quantifiable. An experienced developer can get a very good feel for Meteor over a single weekend: 1. Buy the book: http://www.discovermeteor.com http://www.discovermeteor.com (the book is $39...I did not purchase the other packages) 2. Spend a weekend doing nothing but coding Come Monday morning you'll know what Meteor is about. PS: I am not part of MDG, and I have nothing to do with the book (other than having bought a copy).
- puller 13y ago
  When you say it is quantifiable - can you actually quantify it for us, or is this just hyperbole?
  - parasj 13y ago
    TL;DR: It's great for realtime apps, but not so much for the traditional web app as compared to something like RoR. My perspective as someone who has been using it since its release. It depends on what kind of app you are building. Coming from RoR, Meteor actually is more of a pain given that it still has edge cases that can eat developer time, especially once you dive past the initial levels of tutorials and documentation. RoR also has well established best practices and norms, unlike Meteor and perhaps Node.js as a whole. This means you will be writing a lot more boilerplate code. Meteor has some memory issues as well at times. You have to be aware of memory leaks and will frequent the profiler often, especially with large client-side applications. I've had some projects that I've worked on in Meteor hit 1GB of RAM client-side. Recent releases have been working on this, though. Live reload and hot code pushes are kind of a moot point with something like the Live Reload plugin for Sublime Text or equivalent. For realtime applications, Meteor is a whole different beast. Realtime applications are much easier to code. I'm comparing this to making a realtime Node.js application. Meteor takes care of the boilerplate for you, pushing changes automatically to the client. It's not difficult to do something like socket.io and node.js but it is nice to have that all handled for you. It's great for getting an application off the floor - it has a lot of that magic RoR had when it was released. Once applications get more advanced, the structure and maturity of RoR make it easier to work with. These issues are things Meteor is working on, especially in terms of stabilizing the spec/API and working on fixing the edge cases. With 1.0, it seems they are bringing some more stability to it by making it production ready. Its strengths are much more apparent in realtime applications as compared to a traditional web framework. Edit: As compared to other node.js frameworks like Express, Meteor is much easier to work with - I probably would not go back to raw Express after Meteor. It's been moving fast to 1.0 where many of the issues I've had with it should be resolved with stability and as edge cases are resolved.
parasj 13y ago
I've been using Meteor since its release and its been great at making apps at maximum velocity. You mentioned that some people are already scaling Meteor across multiple servers. Looking at it, round robin load balancing won't work given requests to a server seem to be stateful. How is that being done as of now? Do you guys have any guidance on how to do that?
- geoffschmidt 13y ago
  Yes, if you're using DDP over sockjs instead of just over websockets (which Meteor currently does out of the box to support older browsers), you'll need to use a HTTP proxy with sticky session support. This will be in the official docs at some point, but for now, Arunoda's blog post about this is a great starting point: http://meteorhacks.com/load-balancing-your-meteor-app.html http://meteorhacks.com/load-balancing-your-meteor-app.html
joeblau 13y ago
I made a meteor app and it was one of the best experiences I've ever had making a web application. Even though what I made was fairly basic, the ease of creating a real-time application was amazing.
prottmann 13y ago
Hope you finish soon. I am excited than for an review of meteor and derby, i think that this are the two most exciting projects at the moment.
aphelion 13y ago
I'm very impressed by the technology behind Meteor, I just wish it weren't quite so "opinionated". It relies on standard parts of the node/js web stack, it would be great to have a stand-alone library that supported DDP for front-ends and servers of the developer's choosing.
mark_l_watson 13y ago
Earlier this year, I did an experiment: I implemented the design for a reasonably simple rich web app using two different stacks: Clojure on the server Clojurescript for the client, and the other being Meteor. I have lots of Clojure experience but little Javascript experience. Still, the Meteor implementation took me half as long and had more features. That was a surprising result for me.
MrBra 13y ago
Metheor got about something like 16M $ in funding, if I remember good, and they can't afford a proper microphone for the speaker? :)
- MrBra 13y ago
  comeon, downvoters, don't you have a sense of humor? ... man...
  - geoffschmidt 13y ago
    Doing AV right is hard! You can devote your whole career to learning how to do AV well, and I have a ton of respect for the skills of the people that choose this path. It's a lot more than plugging in a microphone. We do try to improve AV with every Devshop, and we have recently started to bring in AV professionals to help. But honestly, pre-1.0, I think it's way more appropriate for us to be spending our time and money on advancing the framework than on super slick video presentations. In many ways it's more like the Meteor community's time and money.
driverdan 13y ago
I've read through the documentation twice (once when it was released and again a week ago) and reviewed the basic demos. Meteor's front end structure seems like it's missing something. It has a data layer and a view / template layer but nothing else. No routing, controllers, etc. Is there a good demo / tutorial that integrates these missing components, either from meteorite libs or well known projects like Angular or Backbone?
- jacquesc 13y ago
  I agree, it's missing a good routing system. iron-router is a 3rd party solution but I didn't have good luck with it. Seems this is functionality that is core to the framework (it's hard to build anything more than a tech demo without routing).
  - jumpman222 13y ago
    Once you understand iron-router, which takes an hour or two of going through the documentation and trying examples, it really does everything you could ask a router to do. I think its worth a shot of trying it.

93 points by yaliceme 13y ago

pdfcollect 13y ago

Any hope of writing/supporting meteor with python backend? :)

geoffschmidt 13y ago
Sure! The Meteor client and the Meteor server speak a protocol called DDP, which runs over websockets or HTTP long polling. Meteor clients can connect to any DDP server and vice versa. So you just need to implement a DDP server for Python. DDP is pretty simple (just a few messages) and the spec for the 'pre1' version of the protocol is in Git: https://github.com/meteor/meteor/blob/devel/packages/livedata/DDP.md https://github.com/meteor/meteor/blob/devel/packages/livedat... This is pretty close to version '1' of the protocol that will be locked down in Meteor 1.0: https://trello.com/c/kMkw800Z/53-official-ddp-specification https://trello.com/c/kMkw800Z/53-official-ddp-specification
- 1qaz2wsx3edc 13y ago
  I love the DDP as a concept. It's akin to REST-on-steroids, over a websocket with pubsubhubbub sprinkled on top. I really wish more people knew about it, I hope drivers are adapted quickly (some have been). Interoperability & extensibility will make it a killer web feature.
  - sgdesign 13y ago
    Here's an interesting project which uses DDP to talk with a Raspberry Pi: http://pijs.io/ http://pijs.io/
  - icebraining 13y ago
    I know I sound like a fundamentalist, but how is anything like REST? It's an RPC protocol! Nothing against RPC, but it doesn't fit any of the REST constraints, except for the client-server; it's not stateless, it can't have middle-man caching and it doesn't really follow an uniform interface. It's nothing like REST (and as such it doesn't get its benefits).
    - geoffschmidt 13y ago
      Speaking as the protocol designer, the eventual intention for DDP is to model reactive data set publishing in a sufficiently semantic way that it can be cached by proxies. We didn't get there in pre1 and decided to not let that block Meteor 1.0, but it is the goal for the future when we have some post-1.0 breathing room (and when the Meteor community needs it.) The idea behind DDP is that HTTP got us three huge benefits: (1) shared tooling (I can write a caching proxy, and anyone with a website can use it); (2) interchangeable parts (your client and your server can be built with totally different languages and frameworks); and (3) easy APIs (I can describe my site's REST-y API to you in a page or two). These days, a lot of sites are moving away from REST/HTTP and toward ad-hoc, custom publishing schemes that run over websockets or a HTTP long-polling transport that is emulating websockets. Since they use these ad-hoc protocols to move around data rather than something like REST, they lose (1), (2), and (3). But all of these ad-hoc protocols are basically isomorphic to each other. DDP is an attempt to nail this kernel of data publishing functionality down semantically to the point that you can get those three benefits back. As an aside, what's the pressure that's pushing these apps away from REST? The two big ones are: - They cache data locally and need to keep the cache fresh (say they are apps that run in your browser and never reload the page, or they are native mobile apps), and they don't want to poll for updates. And/or, - They need to do joins and they care about latency. (When you are loading the news feed, you want to fetch the feed stories, the comments, and the userpic URLs in one round trip, not first request the stories, and then only once you have them request the comments.) Also, many modern apps have verbs that don't map well to REST (a RPC like transferBalance affects multiple objects and doesn't map well to the idea of updating the representation of an object identified by a URL), and many modern apps need to perform some form of latency compensation (predicting the outcome of a RPC and simulating it locally to update the client's display while waiting for the server's answer, but then reverting to the authoritative outcome chosen by the server.) DDP attempts to address these needs and run over a stream transport like websockets, while recovering some of the benefits of standardization that made REST so successful.
      - icebraining 13y ago
        Thanks; I can perfectly understand the advantages of having a standard protocol, and if DDP becomes an effective standard for applications outside of Meteor, it'll be a great achievement. I just wish people were more aware of what REST really means. DDP seems like a good technology for webapps, but the issue is that I find webapps a really uninspiring trend in web development; my vision for the web is much more data-oriented than the code silos we're all making. And I believe the lack of understanding of what REST means is preventing people from seeing a bigger picture. Also, many modern apps have verbs that don't map well to REST (a RPC like transferBalance affects multiple objects and doesn't map well to the idea of updating the representation of an object identified by a URL) I've heard that a lot, and I don't doubt that it's true in many cases, but usually it seems more representative of a difficulty in the modeling process. For example, a transferBalance call certainly doesn't map well to updating any object, but creating a new Transfer (and passing the URLs of both Accounts) would be perfectly RESTful, in my opinion.

sonnym 13y ago

After seeing the first, extremely slick demo of meteor, I was, as I believe a lot of people were, extremely excited to see where the project would go. Then came the funding, and some twelve or sixteen months of development, and I finally decided to dive in. I really wanted to like it. I was predisposed to do so. But from the very beginning, I was confronted with something I consider a deal breaker. While I am wary and generally disinclined toward the increasingly popular pattern of curl an installation script and pipe into sh, in this case it is not only skeptical, it is downright ludicrous. Why would I, nay anyone, want to install an npm package this way? Should not the installation instructions simply be `npm install -g meteor`? And what if I need to work on multiple meteor projects with different versions? Surely there is support for adding it to your package.json file, but why is this not the primary means of installation and well documented? Maybe I am being overly sensitive to these issues, but it really baffled me that the very foundation upon which a meteor project is predicated would be contradictory to the typical node workflow. I will probably try meteor to spike out a project at some point in time, but I do not foresee myself using it extensively in the near future.

misuba 13y ago
npm install -g meteorite Then create a site with it and specify whatever local version of meteor you want. The deets: https://github.com/oortcloud/meteorite/ https://github.com/oortcloud/meteorite/
- geoffschmidt 13y ago
  Meteor version locking is in core now (as of 0.6.0), and the rest of Meteorite (fetching packages from Atmosphere) will be folded into core as part of 1.0 :)
flylib 13y ago
it's because your getting a full mongo database installed and configured with it
geoffschmidt 13y ago
Meteor is a lot more than an npm package. For example, if you type these four commands.. $ curl https://install.meteor.com https://install.meteor.com | /bin/sh; meteor create myapp; cd myapp; meteor you're up and running with a complete stack including MongoDB, node, the dozen-ish core packages that make up the Meteor pubsub and realtime templating stack, and the 'meteor' build tool (which can do things like compile coffeescript and less, generate source maps, minify your production code, and provide a realtime development environment where whenever you save a file your app updates in your browser.) As for versioning, it's actually got a great way of doing that. Each of your Meteor projects is locked to a specific Meteor release version (similar to an Ubuntu release, it's a release-engineered snapshot of the Meteor core packages), which you can set with the `meteor update` command. And this has automatic `npm shrinkwrap` integration so that if you use npm packages alongside Meteor packages, everyone on your team is always running exactly the same versions of all of the code in your app. The Meteor tools automatically handle all the work of downloading any needed Meteor versions and keeping them installed side-by-side on your laptop, using the correct one for a given project, and notifying you of available updates.

rglover 13y ago

Thanks for posting this. Great overview of what to look forward to. As someone writing an app in production based on 0.6.5, should I plan on any big "rewrites" as the framework approaches 1.0? A better question might be, what will be backwards compatible and what will I have to scrap? It sounds like packages are the one area I should be the most careful with...

akbar501 13y ago
There will be breaking changes as Meteor moves from 0.6.5.1 to 0.7 to 0.8 up until it reaches 1.0. This is part of the bargain of working with pre 1.0 software (APIs etc. will be stabilized once 1.0 is reached). I have found these "breaks" are minor and usually require a few minutes to fix. That said, I also tend to lag behind by a few weeks as other in the community work through the details of the breaking changes. Meteor Hacks (http://meteorhacks.com http://meteorhacks.com) and EventedMind (https://www.eventedmind.com https://www.eventedmind.com) are two great resources.

barkingcat 13y ago

I'd love to see freebsd support for the install scripts. Last I looked support was in its infancy. Maybe I should revisit.

sgdesign 13y ago

If you're curious about Meteor, I recently wrote a short introduction to it from the point of view of front-end JS developers: https://www.discovermeteor.com/2013/09/17/meteor-for-front-end-engineers/ https://www.discovermeteor.com/2013/09/17/meteor-for-front-e...

akbar501 13y ago

Congrats to the MDG team on having 1.0 within reach, and thanks for releasing an amazing platform. Meteor is one of those platforms that you should try. I could give you a menu of features, but the productivity boost from Meteor is one of those things you really should experience. The productivity boost is very real and its quantifiable. An experienced developer can get a very good feel for Meteor over a single weekend: 1. Buy the book: http://www.discovermeteor.com http://www.discovermeteor.com (the book is $39...I did not purchase the other packages) 2. Spend a weekend doing nothing but coding Come Monday morning you'll know what Meteor is about. PS: I am not part of MDG, and I have nothing to do with the book (other than having bought a copy).

puller 13y ago
When you say it is quantifiable - can you actually quantify it for us, or is this just hyperbole?
- parasj 13y ago
  TL;DR: It's great for realtime apps, but not so much for the traditional web app as compared to something like RoR. My perspective as someone who has been using it since its release. It depends on what kind of app you are building. Coming from RoR, Meteor actually is more of a pain given that it still has edge cases that can eat developer time, especially once you dive past the initial levels of tutorials and documentation. RoR also has well established best practices and norms, unlike Meteor and perhaps Node.js as a whole. This means you will be writing a lot more boilerplate code. Meteor has some memory issues as well at times. You have to be aware of memory leaks and will frequent the profiler often, especially with large client-side applications. I've had some projects that I've worked on in Meteor hit 1GB of RAM client-side. Recent releases have been working on this, though. Live reload and hot code pushes are kind of a moot point with something like the Live Reload plugin for Sublime Text or equivalent. For realtime applications, Meteor is a whole different beast. Realtime applications are much easier to code. I'm comparing this to making a realtime Node.js application. Meteor takes care of the boilerplate for you, pushing changes automatically to the client. It's not difficult to do something like socket.io and node.js but it is nice to have that all handled for you. It's great for getting an application off the floor - it has a lot of that magic RoR had when it was released. Once applications get more advanced, the structure and maturity of RoR make it easier to work with. These issues are things Meteor is working on, especially in terms of stabilizing the spec/API and working on fixing the edge cases. With 1.0, it seems they are bringing some more stability to it by making it production ready. Its strengths are much more apparent in realtime applications as compared to a traditional web framework. Edit: As compared to other node.js frameworks like Express, Meteor is much easier to work with - I probably would not go back to raw Express after Meteor. It's been moving fast to 1.0 where many of the issues I've had with it should be resolved with stability and as edge cases are resolved.

parasj 13y ago

I've been using Meteor since its release and its been great at making apps at maximum velocity. You mentioned that some people are already scaling Meteor across multiple servers. Looking at it, round robin load balancing won't work given requests to a server seem to be stateful. How is that being done as of now? Do you guys have any guidance on how to do that?

geoffschmidt 13y ago
Yes, if you're using DDP over sockjs instead of just over websockets (which Meteor currently does out of the box to support older browsers), you'll need to use a HTTP proxy with sticky session support. This will be in the official docs at some point, but for now, Arunoda's blog post about this is a great starting point: http://meteorhacks.com/load-balancing-your-meteor-app.html http://meteorhacks.com/load-balancing-your-meteor-app.html

joeblau 13y ago

I made a meteor app and it was one of the best experiences I've ever had making a web application. Even though what I made was fairly basic, the ease of creating a real-time application was amazing.

prottmann 13y ago

Hope you finish soon. I am excited than for an review of meteor and derby, i think that this are the two most exciting projects at the moment.

aphelion 13y ago

I'm very impressed by the technology behind Meteor, I just wish it weren't quite so "opinionated". It relies on standard parts of the node/js web stack, it would be great to have a stand-alone library that supported DDP for front-ends and servers of the developer's choosing.

mark_l_watson 13y ago

Earlier this year, I did an experiment: I implemented the design for a reasonably simple rich web app using two different stacks: Clojure on the server Clojurescript for the client, and the other being Meteor. I have lots of Clojure experience but little Javascript experience. Still, the Meteor implementation took me half as long and had more features. That was a surprising result for me.

MrBra 13y ago

Metheor got about something like 16M $ in funding, if I remember good, and they can't afford a proper microphone for the speaker? :)

MrBra 13y ago
comeon, downvoters, don't you have a sense of humor? ... man...
- geoffschmidt 13y ago
  Doing AV right is hard! You can devote your whole career to learning how to do AV well, and I have a ton of respect for the skills of the people that choose this path. It's a lot more than plugging in a microphone. We do try to improve AV with every Devshop, and we have recently started to bring in AV professionals to help. But honestly, pre-1.0, I think it's way more appropriate for us to be spending our time and money on advancing the framework than on super slick video presentations. In many ways it's more like the Meteor community's time and money.

driverdan 13y ago

I've read through the documentation twice (once when it was released and again a week ago) and reviewed the basic demos. Meteor's front end structure seems like it's missing something. It has a data layer and a view / template layer but nothing else. No routing, controllers, etc. Is there a good demo / tutorial that integrates these missing components, either from meteorite libs or well known projects like Angular or Backbone?

jacquesc 13y ago
I agree, it's missing a good routing system. iron-router is a 3rd party solution but I didn't have good luck with it. Seems this is functionality that is core to the framework (it's hard to build anything more than a tech demo without routing).
- jumpman222 13y ago
  Once you understand iron-router, which takes an hour or two of going through the documentation and trying examples, it really does everything you could ask a router to do. I think its worth a shot of trying it.