Introducing Meteor 0.9.0, the Meteor Package Server, and Isobuild
meteor.com
meteor.com
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.
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...
Meteor also started putting together a manual to explain the core concepts 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 :)
Also, if your app is now "suddenly slow", I'm guessing it's been around for a while. If you don't have the proper indexes on MongoDB it's going to get slower as it loads up with more data. I've experienced this first-hand, migrating a Rails app from Postgres to Meteor/MongoDB. We have millions of records, and one missed or incorrect index can slow the whole app down, sometimes unbearably.
But I hope you are wrong about becoming a major platform for the web, unless it drasticly changes. These Node frameworks keep astounding me in their use of stateful servers and relying on vertical scaling.
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.
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.
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!
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.
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).
In your comment history I saw that you asked for reactive template variables. I know of two ways to accomplish that, 1) attach a ReactiveDict to a template instance in it's render function, 2) pass it in as a variable to the template inclusion {{>template myDict}}.
You could use reactive-object (my package), as it provides a fairly drop-in reactive object that supports arrays as reactive properties, including all the Array.prototype methods.
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.
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.
If you are curious how it works, this talk is a good start: https://www.youtube.com/watch?v=_dzX_LEbZyI
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.
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.
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/
(Is Isobuild the tool that implements "proper single loading?")
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
[iso]build
Like 'make' or 'scons' but for distributed systems.
One source tree
One package system
Multiple languages
Multiple targets
Multiple architecturesThere 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.
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 :)
It was about the fact that you can code the same way on server, browser, mobile.
Example was that you can use Http package everywhere with the same function and have the same result.
And the other example was the Cordova integration. The build system can generate the code for the whole distributed system (not just the browser).
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.
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>
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".
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?
> 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
Why do you assume that your attention is so valuable that developers should go out of their way to cater specifically to you? The number of people who disable JS is statistically insignificant.
You have chosen to break your web experience, you have no one to blame but yourself.
Normally you would use meteor for your webapplication and only render the dynamic parts with meteor instead of the entire page.