

Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild - waitingkuo
https://www.meteor.com/blog/2014/08/26/meteor-090-new-packaging-system

======
kristiandupont
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
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...](https://www.eventedmind.com/classes/meteor-meteor-reactivity-
with-deps/meteor-what-is-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 :)

~~~
waitingkuo
You can also take a look at
[http://manual.meteor.com/#deps](http://manual.meteor.com/#deps) , which is
provided by meteor offically

------
maxharris
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.

~~~
primigenus
That's funny, because _not_ having to write "spaghetti code" is one of the
reasons I tell people to use Meteor. Perhaps we have different definitions.

For web apps, I tend to define spaghetti code as the huge layers of glue and
boilerplate you have to write to get your data out of your database in the
server, serialized into some JSON or XML format through your controller in
order to send to the client and into an XHR callback hell or confusing
promise-driven architecture, all so that you can finally concatenate
everything into a string inside some jQuery function where you then have to
manage your own state.

None of which even comes up when building with Meteor, since it takes care of
all of that for you, leaving you more time to build your app. So as far as
I've experienced building apps in Meteor for two years, spaghetti code is a
thing of the past. Not to mention that just the fact that the API works this
way dramatically simplifies your application architecture just as a side
effect of how the templating system, reactivity and javascript-everywhere
approach work.

Yes, there are MVC frameworks like Angular and Backbone that help you take
care of the client side of that. But they don't handle the server at all, so
IMO they still haven't matched Meteor's feature set.

~~~
mrcwinn
Backbone is not an MVC framework, and it's important to know that. It's one of
its greatest strengths as a client-side JavaScript tool. A well structured
Backbone app can stand the test of time, and I can't say that for some other
options.

Meteor shows promise, but I have to agree that without a mature UI toolkit,
you just end up with the same junk we've had for years (not speaking to other
components of Meteor).

For what it's worth, have another look at promises. They're not the same as
"callback hell" and can be a really elegant way to compose and deal with
async. It's actually really nice, when the tool is called for.

Agree with you that Meteor's built-in reactivity is really nice!

~~~
primigenus
I didn't mean to imply I thought promises are the same as callback hell - they
are completely different beasts, indeed. But I still greatly prefer the
reactive system provided by Blaze and Meteor's overall setup. I've built
reasonably complex apps with Meteor that have required no promise chaining,
and no callback nesting. They're more readable, easier to maintain, and cause
fewer bugs. One of the reasons why I greatly prefer Meteor now, because all of
those things mean that I get to do more of what I enjoy: building cool stuff.

I'm not sure why you're claiming Backbone isn't an MVC framework. It was
pretty much designed to be MVC or at least MVVM, and checking the Backbone
website, it still says it pretty much in the first paragraph: models,
collections, and views. That's fine, but I like Meteor because it doesn't need
the MVC crutch to provide structure and elegance. Somehow, it gives me more
power as a developer without also asking me to write the kind of boilerplate
code normally associated with data binding, getter/setters, models, and things
like event emitters.

If you still prefer Backbone, that's great! But I just wanted to explain to
the OP that for me, Meteor is about getting rid of spaghetti code, not adding
to it.

------
jakozaur
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.

------
vqc
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
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
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.

------
modeless
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
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-d...](https://www.meteor.com/blog/2013/12/17/meteor-070-scalable-
database-queries-using-mongodb-oplog-instead-of-poll-and-diff) 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
Very cool, thanks. Is server side rendering coming soon as well?

~~~
imslavko
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
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
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/)

------
dfabulich
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
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
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
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 :)

------
flippyhead
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
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.

------
qmaxquique
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)

------
acemtp
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!

------
nojvek
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.

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

~~~
jonperl
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
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
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.

------
mohap
waiting for postgresql support

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

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

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

~~~
dorian-graph
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.

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

------
cheepin
I wonder if Meteor will go 1.0 before NodeJS.

------
pdkl95
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
> 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
That makes me wonder: what is Lynx's market share these days?

