7 ms·

Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild

153 points by waitingkuo 12y ago

nojvek 12y ago
I used Meteor for a project and almost killed myself. Its good and fancy but loads a bajillion javascript libs that you have no idea. Also loads of dependencies on specific versions. DO NOT USE IT FOR PRODUCTION PROJECTS! I've had a very very horrible experience.
modeless 12y ago
Last time I looked at Meteor I decided I wouldn't use it until there was support for server side rendering and the live updates were implemented more efficiently with triggers instead of polling. Are those implemented yet?
- imslavko 12y ago
  Live updates were implemented with listening to MongoDB replication log back on 0.7.0: https://www.meteor.com/blog/2013/12/17/meteor-070-scalable-database-queries-using-mongodb-oplog-instead-of-poll-and-diff https://www.meteor.com/blog/2013/12/17/meteor-070-scalable-d... This is a much more efficient way to get updates from the database and it also scales horizontally to multiple application servers (and multiple MongoDB replicas!) If you are curious how it works, this talk is a good start: https://www.youtube.com/watch?v=_dzX_LEbZyI https://www.youtube.com/watch?v=_dzX_LEbZyI
  - modeless 12y ago
    Very cool, thanks. Is server side rendering coming soon as well?
    - imslavko 12y ago
      The roadmap of Meteor includes "Server-side rendering" planned after 1.0. https://trello.com/c/Lz07fBAm/7-server-side-rendering https://trello.com/c/Lz07fBAm/7-server-side-rendering In my opinion, server-side rendering is a bit overrated since Google knows how to crawl ajaxy apps. SEO is a big concern but you can always render your pages with phantomjs (also a popular approach in the Angular world) or rely on Google being smart. For rendering the page to the end-user, Facebook is not rendering everything server-side, nor does Twitter. I don't have enough knowledge why, but one of the FB engineers told me that it is not really faster: you need to render it twice, send the same data possibly twice, it is hard to correctly chip into the events made on the page, etc.
      - modeless 12y ago
        I'm more concerned with end user page load speed than crawling. I find Facebook and Twitter pages annoyingly slow to load, personally. Sure, server side rendering is difficult but it's exactly the sort of hard problem that a framework ought to be able to solve for you. Edit: actually I just went to twitter and it loaded pretty fast, so I looked at the network requests and they do server side rendering for your timeline.
        imslavko 12y ago
        Hm, looks like you are right. At least the new timeline is server-side rendered. I guess they are updating parts of UI to be rendered on the server to be faster. Interestingly some websites like GitHub are doing the opposite: they are slowly bringing incremental ajax-based transitions to every page, some "real-time" features are implemented with a socket signal refreshing the whole page. One of the community solutions is "FastRender" package, which is not really about rendering. What it does, it puts most of the initial data into HTML page so you don't need to wait for the websocket connection and the data arriving to render the initial page. Improves the initial page load quite significantly: https://meteorhacks.com/fast-render/ https://meteorhacks.com/fast-render/
        deleted 12y ago
        [deleted]
jakozaur 12y ago
Meteor is so awesome. Yesterday was coding my project and was thinking about why I have to install meteorite. Today I can just use one tool... A great example of many good patterns like: Ship basic version, but well-tested one. Then add things once community starts using them (3rd part packages). Also remove quirks that confuse ppl, like auto css reloading.
acemtp 12y ago
The new package system was one of the last missing part for Meteor 1.0 so it's really a good news. And Isobuild, isopack are really promising. Can't wait to see the result!
waitingkuo 12y ago
It's very convenient that I can install both front-end package and back-end package by the same package management system!
dfabulich 12y ago
What is Isobuild? The blog post doesn't actually say, and Googling [meteor isobuild] just turns up the blog post. (Is Isobuild the tool that implements "proper single loading?")
- pinouchon 12y ago
  I too was disappointed that the blog post doesn't go into any detail about unibuild. One of the best and only explanations of isobuild is in this talk by Geoff Schmidt, one of the founders of meteor: http://youtu.be/EZUfQ1zA_NM?t=11m33s http://youtu.be/EZUfQ1zA_NM?t=11m33s [iso]build Like 'make' or 'scons' but for distributed systems. One source tree One package system Multiple languages Multiple targets Multiple architectures
  - denom 12y ago
    I think that this notion of _generality_ that meteor embraces is essentially the struggle for platform relevance. I take isobuild to mean iso-platform, one platform to rule them all. Take the discussion in the video about DDP. It's like "get on board people, we've figured it out!" There is a tension between generalities and specifics, between abstraction and things that are concrete. I don't doubt that having a solution that satisfies everyones hopes, dreams and desires would be awesome, but I feel tension when I work on meteor apps. It feels super easy to code up demos (generalities) and then once you get into the business of building out complexity you bang into trouble. It's almost as if the underlying platforms percolate up and clamor to be heard, if you stray from that meteor happy-path.
    - primigenus 12y ago
      I feel this way too sometimes, but I've come to relate it more to the fact that Meteor is relatively new, and the community has collectively built relatively few complex apps, so the documentation, available blog posts, Stack Overflow questions and answers, wikis, books, tutorials and videos just aren't really in place yet for that kind of architecture. There are more and more solutions and patterns emerging every day as more and more people try building complex stuff in Meteor, though. Just look at some of the packages by Arunoda like fast-render, subs-manager, and kadira: all designed to ease development around common bottlenecks you run into as you start to scale up. In other words, I think this problem will eventually go away as more people keep trying. Just like it did with Ruby on Rails 8 years ago :)
mohap 12y ago
waiting for postgresql support
niix 12y ago
Glad to see that they went with Atmosphere. Meteor has done an incredible job at adopting 3rd party implementations as their official packages.
flippyhead 12y ago
I cannot recommend Meteor enough for a large class of web applications. I've written 3 apps now using it and find it solves a good many of the problems inherent in more "typical" JS app app stack like rails + backbone.
- bellerocky 12y ago
  If you're still using Backbone, then yes, there are better things out there, Meteor being one of them. Others include React, Angular and anything else in widespread use that came out less than half a decade ago.
vqc 12y ago
As a developer and maker, one of the most important things is to ship. And as someone who is not a self-professed [insert programming language] ninja or a full-stack this or that, I can safely say that Meteor has made it much easier for me to iterate and ship. I expect that as I grow, Meteor will continue to grow as well. Excited to see Meteor get closer to 1.0.
- evanscottgray 12y ago
  Definitely agree with you on this one, Meteor has made code easier to deploy. Haven't used it in a while but was able to get my project off the ground in less than 20 minutes. Have recommended it to non 'full stack' friends and they have had great success too. Hopefully this project continues to improve on the road to 1.0!
  - jonjamz 12y ago
    Don't make Meteor sound like a toy, though, 'full stack' engineers worth their salt can do awesome things with it if they understand its inherent limitations. I ran Meteor with Redis before their official Redis implementation came out, and I used Redis pub/sub to sync in real-time between 8 different instances of Meteor in production. It rocked. Just because a framework comes out supporting only MongoDB doesn't mean you have to use MongoDB for everything. It's still on Node.js, and it still supports NPM packages, with some small caveats.
maxharris 12y ago
If you're thinking about using Meteor for something important, now that they're at 0.9.0, don't. Meteor still doesn't have a UI component API, so making reusable, reactive interface components is basically impossible (or far more difficult than it needs to be). There's a deliberately undocumented and incomplete API that's supposed to help a little bit, but you're basically out of luck if you don't want to write spaghetti code right now. Instead of shipping an API we can use, they're holding out for the "perfect" one. I wish I could go a year back in time and build my project with Angular instead of Meteor.
- mrcwinn 12y ago
  I wouldn't write a commercial, production application with anything less than 1.0. In fact, I wouldn't write a commercial, production application with anything less than a 2.1. ;-) The cost of supporting these projects early is that you're likely to be rebuilding anyway a year from now, but I think that's implicit in the version number. In my opinion, the biggest risks of Meteor are this: 1. It hitched its wagon for now to mongo, so you'll be doing the same. If you happen to believe that schemaless isn't all its cracked up to be, that's a real problem in production. 2. You're picking both a client and a server. Sure, you can strip apart DPP or Blaze, but why would you? If you're not wanting to benefit from Meteor's reactivity, you can just use any server+client combo and, say, a websocket connection or something like React.js for UI components. 3. Meteor has a financial incentive to round up as many devs into their own ecosystem (atmosphere?). They want to sell you servers, services, et cetera, like Heroku does. Nothing wrong with that, but it's something to be aware of. For all the debate about JavaScript frameworks, I have Backbone code I wrote a relatively long time ago and it's still durable and not being refactored. I can't say the same for Ember or Angular code in my experience or observation. Backbone as a library is lightweight enough that I create the framework, following good design principles, that's best for a given application. Your mileage may vary. It's not to say the people at Meteor aren't a great bunch of people who really love what they're making. Meteor does some interesting things and I think hopes to solve some complex problems. Hope they get there. I'd love to see Meteor mature and become a tool to build bigger things (UI components I agree would be a welcome step).
  - 12y ago
qmaxquique 12y ago
You can try and use Meteor 0.9.0 in a Terminal.com container. I just created a snapshot for it at https://www.terminal.com/tiny/cb3Rc2NLlE https://www.terminal.com/tiny/cb3Rc2NLlE
cheepin 12y ago
I wonder if Meteor will go 1.0 before NodeJS.
BtM909 12y ago
Weird, no matter what I try, it only updates to 0.8.3 :(
- dorian-graph 12y ago
  Likewise. I reran the install script (curl https://install.meteor.com/ https://install.meteor.com/ | sh) and it removed my existing install and installing 0.9.0.
chaostheory 12y ago
Is there a time table for when meteor will support a relational database?
- jonperl 12y ago
  The only thing I found is that additional databases are under consideration for 1.1+ https://trello.com/c/6ugalZMG/54-additional-database-support https://trello.com/c/6ugalZMG/54-additional-database-support
  - jimmytidey 12y ago
    I've found the absence of joins very frustrating, as well as aggregations such SUM etc. The reason is, I presume, that these are very intensive for a reactive app. If it has to check for a re-render everytime anything is updated across 4 tables then that's expensive. Or for aggregation, everytime something new is inserted into a table.
    - jonperl 12y ago
      Joins are a really hard problem, many people have tried to support joins with a package but they all miss a corner case or have less-than-ideal performance. I think it is something we will have to wait for meteor core to support. https://trello.com/c/BGvIwkEa/48-easy-joins-in-subscriptions https://trello.com/c/BGvIwkEa/48-easy-joins-in-subscriptions In the meantime I have been using the publish-composite package and denormalizing data that has a lot of reads in an update hook using the collection hooks package. In mongo ideally you should have rich documents and not spread out relations among too many collections. However I can imagine how hard it would be to try and sync w/ a relational database without native join support.
munificent 12y ago
Great, I was just thinking the web needed another package manager this week. I'm already tired of duojs.
kristiandupont 12y ago
Having worked with Meteor for 8 months by now, my love affair with it is slowly fading. I guess I've realized that it's too far on the left on the [framework...library] scale for my liking. It's very "don't call us, we'll call you". Which is awesome when you start because you just sort of put stuff out there, functions, collections etc., and Meteor magically picks it up and does stuff with it. Yes, you can still debug everything and it's all open source so nothing is black boxed, but it's still really annoying when the magic doesn't work or worse, when it works but just not very well. As with one of my apps at the moment, that is suddenly slow. Everything works so there is no error message that I can use as a break point. But it just takes a long time for my update function to be called for whatever reason, and debugging that takes me far into territory that I don't know about and frankly don't care to know about. Libraries, on the other hand, require you to say more specifically what you want to happen, but then you can either see that it happens or not. And debug that one particular function if it doesn't, or if it's slow. I have tremendous respect for the work that they are putting in; iteration is really fast and problems are being solved quickly so there is no doubt in my mind that Meteor will become one of the major platforms of the web like Rails did, but it's going to be a while before I will be using it for new projects.
- jonperl 12y ago
  What is nice about meteor is how quickly you can get off the ground and build something with it. Then you realize: I have no idea how this stuff works. Is it secure? When do things update? Is there too much magic? But if you spend a bit of time learning how meteor’s core packages work (deps, ddp, livedata, blaze, etc) and how they work together — almost all of the apprehension disappears. I recommend digging into the Deps package first, it powers reactivity and is surprisingly simple (only 1 kb). EventedMind has great videos explaining reactivity and Deps https://www.eventedmind.com/classes/meteor-meteor-reactivity-with-deps/meteor-what-is-reactivity https://www.eventedmind.com/classes/meteor-meteor-reactivity... Meteor also started putting together a manual to explain the core concepts http://manual.meteor.com http://manual.meteor.com — the first chapter is about the Deps package. With any new concept there is a learning curve. But I believe the concepts meteor introduce are too powerful to ignore. The saying is that any sufficiently advanced technology is indistinguishable from magic :)
pdkl95 12y ago
The problem with meteor (and similar frameworks): curl -s https://www.meteor.com/blog/2014/08/26/meteor-090-new-packaging-system \ | sed -e '/[<]head[>]/,/[<]\/head[>]/ d' <!DOCTYPE html> <html> <body> </body> </html> If you want someone to read your article, actually sending that article would be useful. If that article has advanced features that require javascript, flash, or video/audio, you should probably give me a reason to whitelist the page. Sending and empty body tag, on the other hand, looks more like a rendering error than any kind of real content. Don't bother replying with the usual nonsense assertions that "everybody has js", variations of "js is mandatory/expected", or that not running js in stupid/luddite. Sorry, with pages asking for js from 10-20 hosts and the current drama about network security, js is whitelist only. So give me a reason if you want to be added to that whitelist. This means actual content, not "I'm too lazy to statically render a copy on the server".
- coffeemug 12y ago
  > js is whitelist only You're not representative of the majority of online users. Not even close, by an enormous margin (95% of people don't know what JavaScript is, let alone how to disable it; out of the remaining 5% that do know, 4.999% don't care). Given that you're in an extreme minority and wield no power in the marketplace, could you give them a reason as to why they should dedicate development time to making this use case work?
  - seanmcdirmid 12y ago
    That makes me wonder: what is Lynx's market share these days?
  - pdkl95 12y ago
    Ahh, the downvotes, as expected. > 95% of people don't know what Javascript is Indeed. So you take every opportunity to exploit that ignorance, instead of educating them that there might be risks associated with running unknown code? This is a perfect example of one of the larger problems in the tech industry. Your product could be something that helps them, despite their ignorance of the alphabet soup of technologies. Instead, you choose to make something that requires the client to take risks. Was there some technical reason this was necessary? No. Was here some huge benefit to speed or availability that wasn't available with other technologies? No. The benefit was personal convenience ("development time"). The next time you see someone annoyed at technology they don't understand, remember that YOU (and people like you) were the source of that frustration. //i'm sure this will be downvoted as well, given how selfishly narrow-minded this crowd can be at times

153 points by waitingkuo 12y ago

I used Meteor for a project and almost killed myself. Its good and fancy but loads a bajillion javascript libs that you have no idea. Also loads of dependencies on specific versions. DO NOT USE IT FOR PRODUCTION PROJECTS! I've had a very very horrible experience.

modeless 12y ago

Last time I looked at Meteor I decided I wouldn't use it until there was support for server side rendering and the live updates were implemented more efficiently with triggers instead of polling. Are those implemented yet?

imslavko 12y ago
Live updates were implemented with listening to MongoDB replication log back on 0.7.0: https://www.meteor.com/blog/2013/12/17/meteor-070-scalable-database-queries-using-mongodb-oplog-instead-of-poll-and-diff https://www.meteor.com/blog/2013/12/17/meteor-070-scalable-d... This is a much more efficient way to get updates from the database and it also scales horizontally to multiple application servers (and multiple MongoDB replicas!) If you are curious how it works, this talk is a good start: https://www.youtube.com/watch?v=_dzX_LEbZyI https://www.youtube.com/watch?v=_dzX_LEbZyI
- modeless 12y ago
  Very cool, thanks. Is server side rendering coming soon as well?
  - imslavko 12y ago
    The roadmap of Meteor includes "Server-side rendering" planned after 1.0. https://trello.com/c/Lz07fBAm/7-server-side-rendering https://trello.com/c/Lz07fBAm/7-server-side-rendering In my opinion, server-side rendering is a bit overrated since Google knows how to crawl ajaxy apps. SEO is a big concern but you can always render your pages with phantomjs (also a popular approach in the Angular world) or rely on Google being smart. For rendering the page to the end-user, Facebook is not rendering everything server-side, nor does Twitter. I don't have enough knowledge why, but one of the FB engineers told me that it is not really faster: you need to render it twice, send the same data possibly twice, it is hard to correctly chip into the events made on the page, etc.
    - modeless 12y ago
      I'm more concerned with end user page load speed than crawling. I find Facebook and Twitter pages annoyingly slow to load, personally. Sure, server side rendering is difficult but it's exactly the sort of hard problem that a framework ought to be able to solve for you. Edit: actually I just went to twitter and it loaded pretty fast, so I looked at the network requests and they do server side rendering for your timeline.
      - imslavko 12y ago
        Hm, looks like you are right. At least the new timeline is server-side rendered. I guess they are updating parts of UI to be rendered on the server to be faster. Interestingly some websites like GitHub are doing the opposite: they are slowly bringing incremental ajax-based transitions to every page, some "real-time" features are implemented with a socket signal refreshing the whole page. One of the community solutions is "FastRender" package, which is not really about rendering. What it does, it puts most of the initial data into HTML page so you don't need to wait for the websocket connection and the data arriving to render the initial page. Improves the initial page load quite significantly: https://meteorhacks.com/fast-render/ https://meteorhacks.com/fast-render/
      - deleted 12y ago
        [deleted]

jakozaur 12y ago

Meteor is so awesome. Yesterday was coding my project and was thinking about why I have to install meteorite. Today I can just use one tool... A great example of many good patterns like: Ship basic version, but well-tested one. Then add things once community starts using them (3rd part packages). Also remove quirks that confuse ppl, like auto css reloading.

acemtp 12y ago

The new package system was one of the last missing part for Meteor 1.0 so it's really a good news. And Isobuild, isopack are really promising. Can't wait to see the result!

waitingkuo 12y ago

It's very convenient that I can install both front-end package and back-end package by the same package management system!

dfabulich 12y ago

What is Isobuild? The blog post doesn't actually say, and Googling [meteor isobuild] just turns up the blog post. (Is Isobuild the tool that implements "proper single loading?")

pinouchon 12y ago
I too was disappointed that the blog post doesn't go into any detail about unibuild. One of the best and only explanations of isobuild is in this talk by Geoff Schmidt, one of the founders of meteor: http://youtu.be/EZUfQ1zA_NM?t=11m33s http://youtu.be/EZUfQ1zA_NM?t=11m33s [iso]build Like 'make' or 'scons' but for distributed systems. One source tree One package system Multiple languages Multiple targets Multiple architectures
- denom 12y ago
  I think that this notion of _generality_ that meteor embraces is essentially the struggle for platform relevance. I take isobuild to mean iso-platform, one platform to rule them all. Take the discussion in the video about DDP. It's like "get on board people, we've figured it out!" There is a tension between generalities and specifics, between abstraction and things that are concrete. I don't doubt that having a solution that satisfies everyones hopes, dreams and desires would be awesome, but I feel tension when I work on meteor apps. It feels super easy to code up demos (generalities) and then once you get into the business of building out complexity you bang into trouble. It's almost as if the underlying platforms percolate up and clamor to be heard, if you stray from that meteor happy-path.
  - primigenus 12y ago
    I feel this way too sometimes, but I've come to relate it more to the fact that Meteor is relatively new, and the community has collectively built relatively few complex apps, so the documentation, available blog posts, Stack Overflow questions and answers, wikis, books, tutorials and videos just aren't really in place yet for that kind of architecture. There are more and more solutions and patterns emerging every day as more and more people try building complex stuff in Meteor, though. Just look at some of the packages by Arunoda like fast-render, subs-manager, and kadira: all designed to ease development around common bottlenecks you run into as you start to scale up. In other words, I think this problem will eventually go away as more people keep trying. Just like it did with Ruby on Rails 8 years ago :)

mohap 12y ago

waiting for postgresql support

niix 12y ago

Glad to see that they went with Atmosphere. Meteor has done an incredible job at adopting 3rd party implementations as their official packages.

flippyhead 12y ago

I cannot recommend Meteor enough for a large class of web applications. I've written 3 apps now using it and find it solves a good many of the problems inherent in more "typical" JS app app stack like rails + backbone.

bellerocky 12y ago
If you're still using Backbone, then yes, there are better things out there, Meteor being one of them. Others include React, Angular and anything else in widespread use that came out less than half a decade ago.

vqc 12y ago

As a developer and maker, one of the most important things is to ship. And as someone who is not a self-professed [insert programming language] ninja or a full-stack this or that, I can safely say that Meteor has made it much easier for me to iterate and ship. I expect that as I grow, Meteor will continue to grow as well. Excited to see Meteor get closer to 1.0.

evanscottgray 12y ago
Definitely agree with you on this one, Meteor has made code easier to deploy. Haven't used it in a while but was able to get my project off the ground in less than 20 minutes. Have recommended it to non 'full stack' friends and they have had great success too. Hopefully this project continues to improve on the road to 1.0!
- jonjamz 12y ago
  Don't make Meteor sound like a toy, though, 'full stack' engineers worth their salt can do awesome things with it if they understand its inherent limitations. I ran Meteor with Redis before their official Redis implementation came out, and I used Redis pub/sub to sync in real-time between 8 different instances of Meteor in production. It rocked. Just because a framework comes out supporting only MongoDB doesn't mean you have to use MongoDB for everything. It's still on Node.js, and it still supports NPM packages, with some small caveats.

maxharris 12y ago

If you're thinking about using Meteor for something important, now that they're at 0.9.0, don't. Meteor still doesn't have a UI component API, so making reusable, reactive interface components is basically impossible (or far more difficult than it needs to be). There's a deliberately undocumented and incomplete API that's supposed to help a little bit, but you're basically out of luck if you don't want to write spaghetti code right now. Instead of shipping an API we can use, they're holding out for the "perfect" one. I wish I could go a year back in time and build my project with Angular instead of Meteor.

mrcwinn 12y ago
I wouldn't write a commercial, production application with anything less than 1.0. In fact, I wouldn't write a commercial, production application with anything less than a 2.1. ;-) The cost of supporting these projects early is that you're likely to be rebuilding anyway a year from now, but I think that's implicit in the version number. In my opinion, the biggest risks of Meteor are this: 1. It hitched its wagon for now to mongo, so you'll be doing the same. If you happen to believe that schemaless isn't all its cracked up to be, that's a real problem in production. 2. You're picking both a client and a server. Sure, you can strip apart DPP or Blaze, but why would you? If you're not wanting to benefit from Meteor's reactivity, you can just use any server+client combo and, say, a websocket connection or something like React.js for UI components. 3. Meteor has a financial incentive to round up as many devs into their own ecosystem (atmosphere?). They want to sell you servers, services, et cetera, like Heroku does. Nothing wrong with that, but it's something to be aware of. For all the debate about JavaScript frameworks, I have Backbone code I wrote a relatively long time ago and it's still durable and not being refactored. I can't say the same for Ember or Angular code in my experience or observation. Backbone as a library is lightweight enough that I create the framework, following good design principles, that's best for a given application. Your mileage may vary. It's not to say the people at Meteor aren't a great bunch of people who really love what they're making. Meteor does some interesting things and I think hopes to solve some complex problems. Hope they get there. I'd love to see Meteor mature and become a tool to build bigger things (UI components I agree would be a welcome step).
- 12y ago

qmaxquique 12y ago

You can try and use Meteor 0.9.0 in a Terminal.com container. I just created a snapshot for it at https://www.terminal.com/tiny/cb3Rc2NLlE https://www.terminal.com/tiny/cb3Rc2NLlE

cheepin 12y ago

I wonder if Meteor will go 1.0 before NodeJS.

BtM909 12y ago

Weird, no matter what I try, it only updates to 0.8.3 :(

dorian-graph 12y ago
Likewise. I reran the install script (curl https://install.meteor.com/ https://install.meteor.com/ | sh) and it removed my existing install and installing 0.9.0.

chaostheory 12y ago

Is there a time table for when meteor will support a relational database?

jonperl 12y ago
The only thing I found is that additional databases are under consideration for 1.1+ https://trello.com/c/6ugalZMG/54-additional-database-support https://trello.com/c/6ugalZMG/54-additional-database-support
- jimmytidey 12y ago
  I've found the absence of joins very frustrating, as well as aggregations such SUM etc. The reason is, I presume, that these are very intensive for a reactive app. If it has to check for a re-render everytime anything is updated across 4 tables then that's expensive. Or for aggregation, everytime something new is inserted into a table.
  - jonperl 12y ago
    Joins are a really hard problem, many people have tried to support joins with a package but they all miss a corner case or have less-than-ideal performance. I think it is something we will have to wait for meteor core to support. https://trello.com/c/BGvIwkEa/48-easy-joins-in-subscriptions https://trello.com/c/BGvIwkEa/48-easy-joins-in-subscriptions In the meantime I have been using the publish-composite package and denormalizing data that has a lot of reads in an update hook using the collection hooks package. In mongo ideally you should have rich documents and not spread out relations among too many collections. However I can imagine how hard it would be to try and sync w/ a relational database without native join support.

munificent 12y ago

Great, I was just thinking the web needed another package manager this week. I'm already tired of duojs.

kristiandupont 12y ago

Having worked with Meteor for 8 months by now, my love affair with it is slowly fading. I guess I've realized that it's too far on the left on the [framework...library] scale for my liking. It's very "don't call us, we'll call you". Which is awesome when you start because you just sort of put stuff out there, functions, collections etc., and Meteor magically picks it up and does stuff with it. Yes, you can still debug everything and it's all open source so nothing is black boxed, but it's still really annoying when the magic doesn't work or worse, when it works but just not very well. As with one of my apps at the moment, that is suddenly slow. Everything works so there is no error message that I can use as a break point. But it just takes a long time for my update function to be called for whatever reason, and debugging that takes me far into territory that I don't know about and frankly don't care to know about. Libraries, on the other hand, require you to say more specifically what you want to happen, but then you can either see that it happens or not. And debug that one particular function if it doesn't, or if it's slow. I have tremendous respect for the work that they are putting in; iteration is really fast and problems are being solved quickly so there is no doubt in my mind that Meteor will become one of the major platforms of the web like Rails did, but it's going to be a while before I will be using it for new projects.

jonperl 12y ago
What is nice about meteor is how quickly you can get off the ground and build something with it. Then you realize: I have no idea how this stuff works. Is it secure? When do things update? Is there too much magic? But if you spend a bit of time learning how meteor’s core packages work (deps, ddp, livedata, blaze, etc) and how they work together — almost all of the apprehension disappears. I recommend digging into the Deps package first, it powers reactivity and is surprisingly simple (only 1 kb). EventedMind has great videos explaining reactivity and Deps https://www.eventedmind.com/classes/meteor-meteor-reactivity-with-deps/meteor-what-is-reactivity https://www.eventedmind.com/classes/meteor-meteor-reactivity... Meteor also started putting together a manual to explain the core concepts http://manual.meteor.com http://manual.meteor.com — the first chapter is about the Deps package. With any new concept there is a learning curve. But I believe the concepts meteor introduce are too powerful to ignore. The saying is that any sufficiently advanced technology is indistinguishable from magic :)

pdkl95 12y ago

The problem with meteor (and similar frameworks): curl -s https://www.meteor.com/blog/2014/08/26/meteor-090-new-packaging-system \ | sed -e '/[<]head[>]/,/[<]\/head[>]/ d' <!DOCTYPE html> <html> <body> </body> </html> If you want someone to read your article, actually sending that article would be useful. If that article has advanced features that require javascript, flash, or video/audio, you should probably give me a reason to whitelist the page. Sending and empty body tag, on the other hand, looks more like a rendering error than any kind of real content. Don't bother replying with the usual nonsense assertions that "everybody has js", variations of "js is mandatory/expected", or that not running js in stupid/luddite. Sorry, with pages asking for js from 10-20 hosts and the current drama about network security, js is whitelist only. So give me a reason if you want to be added to that whitelist. This means actual content, not "I'm too lazy to statically render a copy on the server".

coffeemug 12y ago
> js is whitelist only You're not representative of the majority of online users. Not even close, by an enormous margin (95% of people don't know what JavaScript is, let alone how to disable it; out of the remaining 5% that do know, 4.999% don't care). Given that you're in an extreme minority and wield no power in the marketplace, could you give them a reason as to why they should dedicate development time to making this use case work?
- seanmcdirmid 12y ago
  That makes me wonder: what is Lynx's market share these days?
- pdkl95 12y ago
  Ahh, the downvotes, as expected. > 95% of people don't know what Javascript is Indeed. So you take every opportunity to exploit that ignorance, instead of educating them that there might be risks associated with running unknown code? This is a perfect example of one of the larger problems in the tech industry. Your product could be something that helps them, despite their ignorance of the alphabet soup of technologies. Instead, you choose to make something that requires the client to take risks. Was there some technical reason this was necessary? No. Was here some huge benefit to speed or availability that wasn't available with other technologies? No. The benefit was personal convenience ("development time"). The next time you see someone annoyed at technology they don't understand, remember that YOU (and people like you) were the source of that frustration. //i'm sure this will be downvoted as well, given how selfishly narrow-minded this crowd can be at times