Meteor Raises $20M
techcrunch.com
techcrunch.com
The one thing that made me drop it as the choice for a primary stack was the fact that it's tied so heavily into MongoDB. Meteor has a mongodb 'server' replicated client side, that's how they can actually make Meteor so god damn snappy, it's latancy compensation.
If they were to integrate something like Postgresql into Meteor, I would easily switch over from Rails and it would become my de-facto web stack.
I'll just keep building Rails APIs with EmberJS clients until then, I do hope it's soon though. I loved working with Meteor.
https://trello.com/b/hjBDflxp/meteor-roadmap
There are some good packages on Atmosphere for PostgreSQL, but I think that it needs to be officially supported/integrated for many people to be comfortable with it.
My preferred "easy/simple" model of app design is Firebase (backend and JS lib for pure web clients), who have security figured out.
You remove the autopublish package and you can no longer query records from the client.
If there's one thing we should have learned from Rails' various security failures, it's that things must be secure by default.
Likewise, no matter what languages, majority are insecure by defaults.
One of the things I like about rails (and ember-cli) is that it is "secure-by-default". If I am going to make a choice that potentially has security vulnerabilities, I have to deliberately make that choice - I basically have to create a whitelist of things I want to allow.
It leaves a "I should triple check everything again before going live since I cannot trust the tool to do its job" thread running permanently in the back of the mind. It's such a slowdown. Don't get me wrong, it's important to read the documentation and double check settings, but insanity by default does not build trust.
That said in the case of meteor beyond the autopublish package that should be off by default, I think everything is spot on. I mostly use PostgreSQL, so I cannot use it as much as I'd like to, but hopefully that will change.
Unlike Firebase, Meteor actually allows you to send "first top 20 guest posts from November" as an example. The filtering can happen on the server, before sending the data and the data model usually fits into a sets of documents in set of collections. In Firebase, everything is part of a big subtree that is not filterable (the last time I checked).
Firebase is a good choice for keeping your real-time data. But knowing its limitations is as important as knowing its strengths.
We also have limitToFirst(), limitToLast(), startAt(), endAt(), and equalTo() methods to further filter your data.
This allows you to build queries like this:
ref.orderByChild("weight").limitToLast(2).on("child_added", function(snapshot) {
console.log(snapshot.key());
});
[0] https://www.firebase.com/blog/2014-11-04-firebase-realtime-q...
meteor remove autopublish
meteor remove insecure
The Mongo-accessible frontent is genius. This makes your prototyping much faster, and you can totally skip the "model" layer of your frontend. It matches your backend automatically. No further configuration needed. No REST endpoints, no callbacks. And yes, it's secure.
Meteor's security model is very well-designed. The list of things left for the developer to do, security-wise, is very short.
It's still important to learn your tools and understand how security works.
http://security-resources.meteor.com/
I mean, you have routers, routes, controllers, views, templates, and components - how many concepts do you need to display a ui?
Maybe it's just that I can't see the forest through the trees. Perhaps you could help me gain this perspective?
They're dropping controllers and views in a month, with Ember 2.0. They're being replaced by components.
So really you will only work with routes and components - which should make things much easier to understand.
It seems like Ember is going to become a bit more like React (which I'm very fine with).
I'm not a huge fan of isomorphic JavaScript. While it seems great for prototyping, I have doubts on its stability, security, and ability to scale. It seems to be a knee-jerk reaction to just having the technology to write web-client and web-server code in the same language and the emergence of SPAs.
The thing is, we've had working client-server application architecture (which is what an SPA is) for decades. Every multiplayer game you've ever played. Chat programs. Etc. Nobody would risk the headache of tightly-coupling your data layer, presentation layer, and business layer just to save a few lines of code. We separate our concerns in our code itself with MVC frameworks, why are isomorphic frameworks trying to tightly-couple our actual application layers? It's a little bit contradictory to me.
While Meteor seems like a great tool for a couple of newbie developers to rapidly prototype an idea, I'm still not convinced it has the potential to grow into a reasonable architecture.
Official React or Angular support isn't a game-changer. They can already be integrated easily with the reactive data providers.
Either way, best of luck to them!
There's also a list of libraries for other languages that communicate with Meteor via DDP. [2]
[1] https://www.meteor.com/ddp [2] http://meteorpedia.com/read/DDP_Clients
It is indeed a breeze to prototype applications with it, but I am a little bit concerned about the costs of getting an actual production ready site with it.
For intance, when is it ever OK to let your client write directly in the database, even for their own data? If you're going to pass their calls through a deny and allow call, why not just expose RPCs to the client that will handle any writing?
It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.
Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?
All of your questions are answered there.
Is there a benefit to using meteor beyond the fast prototyping? I'm not saying that's not potentially a huge benefit, but once you're done with your prototype, I still feel like you have to rewrite the whole thing.
If you have a client-side mirror of your server-side database whose changes are monitored by the templating engine, you can execute what Meteor calls "latency compensation", where changes users make are instantly reflected in the UI and synced to the server in the background. This is a central feature of Meteor. More here: https://www.meteor.com/full-stack-db-drivers and in this Youtube video: https://www.youtube.com/watch?v=tqLbodVH3dw
> It seems that a lot of the light versality you have at prototyping time is lost whenever you have to get it production ready. There is definitely some value in light prototypes, but it looks like a real pain to go from prototype to production.
It's actually very easy to go from prototype to production; you just remove some convenience packages (autopublish and insecure), set up your security rules, do some basic performance tuning (eg. don't publish entire documents if you only need 3 fields, which is a standard practice for any app) and that's about it. Of course the definition of "production" varies per project, but after shipping over 20 Meteor apps since 2012 these are the most common things I tend to do.
> Likewise, I'm confused about how to get around the limitations of mongodb. Say you run a store with a finite inventory, how do you handle concurrent purchases? How about a website to enroll into classes? How about a webforum which can have exactly 5 administrators?
You can express most of these in code. Yes, in relational databases you can express constraints in the database. But then you're having a NoSQL vs SQL debate, which is sort of out of scope of this discussion.
Since meteor integrates very tightly with mongodb, a nosql database, I don't see how the limitations of nosql are out of the scope of the discussion? I also don't know what you mean by "you express most of these in code". The problem isn't writing a piece of code that expresses that constraint... the problem is doing so without introducing a race condition!
I agree, and this also exposes a weakness of javascript as a backend language. If you use Java/Scala, you have multithreading support and can sync the threads + concurrently verify that an item isn't being purchased more than X times. Which makes this problem solvable even with a NoSQL database. Javascript is single threaded though, which makes this problem a lot harder and I don't know how you'd solve it without an RDBMS with transactional support.
That does cause you to have a hard limit of one application server for the app, which can be a pretty big deal...
Plus if you have multiple servers, they will most likely need to pass messages for other things too.
Further, I tend to think that if your application is heavy enough to outgrow a reasonably fat db server with (say) 500+GB of RAM, strategies like reimplementing consistent-db-esque locking in an app server + zookeeper setup are also likely to hit some pretty weird performance issues.
Don't see why you'd need locking. Node A receives a request to buy an item, A asks nodes B, C, and D to confirm that the item is in stock in each node's internal state. If all give the OK, A lets the purchase go through. If node B goes down, then A just asks C and D. I don't see the need for locking or a master/slave.
> a reasonably fat db server with (say) 500+GB of RAM
You have a single point of failure with a single, monolithic server. If its hd dies, you will be in serious trouble restoring terabytes of db.
-----
> Don't see why you'd need locking. Node A receives a request to buy an item, A asks nodes B, C, and D to confirm that the item is in stock in each node's internal state. If all give the OK, A lets the purchase go through. If node B goes down, then A just asks C and D. I don't see the need for locking or a master/slave.
Presumably in order to ensure that B, C, and D can consistently check the object's state, nothing else can be allowed to write to it at that time - A effectively has to lock the object using zookeeper. You then have to make sure that the object gets unlocked if A goes down after locking it, or most particularly if A hangs, keeping the zookeeper session open? Otherwise your other app servers could get caught in a very long or infinite lock wait.
You've also got to keep track of the rest of your code, and make sure it never alters these same objects without locking. I'm assuming here that you only distributed-lock objects when you absolutely have to, in order to improve performance: otherwise you're going to start hitting some of the issues that make it hard to cluster relational DBs with decent performance (modulo some coarser lock granularity for a document-based system).
As you add complexity to this approach (say, perhaps you need to work on two objects at once), you also start having to think about other problems like deadlocking, or what happens if your zookeeper session fails part way through your work, where you've made half of the changes you want to make, and you can't easily roll back. This is all fine if you have programmers who are competent to think about these kinds of problems, but they're typically pretty expensive - and my experience is that most people just don't really bother to think about it.
> You have a single point of failure with a single, monolithic server. If its hd dies, you will be in serious trouble restoring terabytes of db.
Any system of value will of course have a replica, meaning you're perhaps more likely to be worried about network problems than the server falling over. Of course this is still less reliable than a perfectly implemented multi-master distributed system, but it's also hugely easier to use correctly - and the likelihood of failure of a single node is actually very low. Obviously if you literally cannot afford any downtime, maybe you go with a distributed system (or follow the banks and use mainframes..), but businesses that will be killed by network blips are certainly in the minority.
As for your second question. There are certainty use cases where MongoDB isn't appropriate, and support for other databases is on Meteor's roadmap. For now there are some community created packages for interfacing directly with SQL databases in place of MongoDB, but there are a number of issues with them. You could also pipe data in and out of an SQL database inside RPCs, however the data would not be updated in 'real-time' to clients. I anticipate SQL databases will get some good support options in time.
You don't have to use the client-side insert/update/remove syntax if you don't want to. Unless you add an 'allow' call to let some of them through, they will all be automatically rejected by the server.
(I work at Meteor)
Building that functionality out yourself from scratch could be difficult, since all of the components of Meteor work together to make that experience possible.
Good question. A pattern I like to use for this in Meteor is to rely solely on their Method calls which allow you to restrict any database ops to the server side. The trick is that you lock down all client-side writing from the get go so you're not trying to guess whether you set your rules properly. Here's an example of that pattern: https://gist.github.com/themeteorchef/194a803f8a28840f475f.
Re: concurrent purchases in your store example, you can actually strip reactivity from certain database queries. So, on the front-end you can prevent state shifting out from under users. To control data on the server, you could have a method that checks whether or not the inventory has been depleted before allowing certain operations (e.g. routing to a new page, manipulating the database, etc). Definitely possible to do this without going bonkers.
Does that answer what you're looking for?
Regarding the concurrent store, forget event about the client. You need to check whether or not the inventory has been depleted and then update the inventory, and create the client's invoice. That means blocking calls, double staged commits, and a whole lot of nasty things that have nothing to do with reactivity and everything to do with integrity.
In the prototyping sense, yes. I've been working with Meteor for about two years and the pattern I shared above still feels magical when you realize what it's doing in just a few minutes of work. The client-side writes are still okay. The big problem is remembering to specify the correct allow/deny rules.
The pattern above is a sort of brute force approach to saying "I'm an idiot, I'll forget to set rules, let's make this a non-issue." Of note, I recall some chatter about dropping allow/deny rules altogether in the future, so there's likely a better solution on the horizon.
> You need to check whether or not the inventory has been depleted and then update the inventory, and create the client's invoice.
This isn't as big of a problem as it's being made out to be. Really just a few lines of code, e.g.:
```
// Fetch just makes this an array instead of a Mongo cursor.
// The fields part just strips the returned object(s) back
// with only those fields + the _id of the object.
var inventoryAvailable = Inventory.find({product: productName}, {fields: {"available": 1}}).fetch();
if ( inventoryAvailable.available > 1 ) { // Call some purchase function. } else { // Throw an error back to the client. }
```
Re: the concern around race conditions between customers, Meteor could actually have a leg up on this. Because you have reactivity, if say there was only 1 of an item left, if one customer completed the purchase before another, you could throw up an overlay on the slower customers screen saying "uh oh, the last one of these just got snatched up...get on the waiting list?"
A lot of ways to skin this cat :)
Although, there are various DDP clients for other languages as you can see here: http://meteorpedia.com/read/DDP_Clients
There have been some discussions with Asana (asana.com) teams who are building their new data store with a DDP API published for their clients.
I have such high hopes for Meteor!
But you make some good points. Meteor is not for everything, and if I had known from the start that Sidebar would end up being just a list of links I might have used a different stack (like Rails, or even a static site generator).
- http://www.quora.com/Which-startups-use-Meteor-in-production - http://www.quora.com/What-open-source-software-uses-Meteor-f...
I've also used angular, which I also like, but has a little bit more of a learning curve drawback.
I do unfortunately believe that a project or framework should make it not because it's CEO or leader is good at selling something, pitching VC's, and creating a brand, I think a project or framework should make it because it is the crowdsourced best solution to a problem. And this kind of money raising worries me a little, because it gives an unfair advantage to a framework. Now meteor might be the best answer, but if it's not, this is a shame and we all stand to miss out on a potential right answer for this...
Anyway, all of this is a little moot because I believe you shouldn't be using javascript for this kind of stuff ^^ but that's another debate altogether
Keep in mind both are open source projects. The community has been immensely successful filling up Meteor's gaps.
That money is better spent convincing other developers that Meteor has no gaps.
People here are even pissed that they got more money and other frameworks didn't. Nobody invest (their money at least) without a good risk/reward ratio.
It means the community is very at it and its a place to go if you have a question and don't want to dive into the docs
Alot of people do prefer personalised answers over the effort of finding it in docs, sad reality.
I'd be willing to bet much of those SO questions and replies are a part of keeping up the Meteor hype with most questions being answered by a core group of devs.
The PR machine for Meteor is crazy. It's funny because this 20M will go to generating more hype and PR opportunities, while the actual development will fall to these wide-eyed open-source evangelists who will give up their time for free to make it better.
Then Meteor will be sold to Facebook and all these open source developers will realize that their work was driving up the valuation for a bunch of investors who couldn't care less about their code or the products it powered.
I'm having a relatively cynical day, I can't tell if I woke up this way or if this Meteor news is what set me off.
Either that or they're a part of their huge open source community which will still work tirelessly to make the framework better, even if Meteor isn't commercial viable and people move on to the next best thing.
I'm sure the truth is based more on who's in the room at the time than anything else.
I hear you about the potential implosion by acquisition. It's definitely a risk. It's not much different than other burgeoning technologies in that regard.
Meteor is advancing a new paradigm of building consumer applications, much like Django and Rails did for REST. It lowers the barrier to entry, and it really has the potential to expose a new generation of programmers to modern techniques.
I also think they've been pretty clear about when Meteor is unsuitable, despite the hype. It's not going to magically scale. It's not a bad place to start, though.
I am all in.
I was brought into a company where the lead dev was doing everything in Meteor, if I wasn't open to Meteor at the time I would not have taken the job. Over the course of 6 months I watched this dev utilize their ability to sound smart to fool everyone into thinking Meteor was the right tool for the job when they really just wanted to become a Meteor expert since they thought this would be the next .NET that would give them sweet cushy consulting gigs in industries with crazy technology budgets.
I worked with the technology and was unimpressed. Everything needs to go through Meteor and it leaves no room for flexibility. Going with Meteor is an all-in strategy... and anyone who knows strategy ought to know that going all-in is for when you're exceedingly confident or exceedingly desperate.
I recognize Meteor's utility as a rapid prototyping tool. I will openly say anywhere that if you have little development resources and want to build out a proof of concept. Yes, utilize Meteor. But if you don't throw it away after you've shown whoever needs the proof, you are asking for trouble.
The problem with lowering the bar with a new paradigm exposed to a new generation of programmers is that they're being taught bad habits and bad patterns. Tightly coupling the front and back end (what "isomorphic javascript" really means) is Meteor's main selling point. Tight coupling of systems is a universally accepted anti-pattern and anyone who has a product that eventually requires flexibility in their client-server communication is going to find themselves stuck when everyone just stares blankly repeating "but... DDP?"
Creating a new generation of programmers who call themselves rockstars because they know how to run a couple Meteor CLI commands and make a Todo list app in 20 minutes is not going to make the Internet a better place.
It sounds like you were in an organization where there was some fundamental disagreement that caused the contention.
I don't have any skin in the game, but I find this account to be an unfair characterization of Meteor, so I'd like to refute some of your claims.
First, I really don't know where you got the idea that Meteor is an all-or-nothing stack. Sure, it provides everything you need, but you're not compelled to use what it provides. Meteor works very well with all sorts tech.
* The website has a whole subdomain devoted to using it with Angular: http://angular-meteor.com/.
* Here's talk given about using React: https://youtu.be/-QtrkXKvQFc. I'm currently doing this with great results.
* Here's one of a few projects providing support for PostgreSQL: https://github.com/meteor-stream/meteor-postgres/wiki/Gettin...
Basically, if there is javascript support for it, you can use it with Meteor.
Secondly, it's disingenuous to say that Isomorphic Javascript is just bad tight coupling by invoking "universally accepted anti-pattern" because someone can come along and spout equally broad and obnoxious engineering-speak, calling it DRY and touting its core principle of code reuse as best practice.
Now, I am genuinely interested in specific shortcomings and outright failures of the technology. If you had a bad experience with DDP, I'd like to hear about it so I don't make the same mistake.
If I want to make an application where one page is an Angular client app and the other is an Ember app, but they're both served by the same server and communicate to the same API you can do that with number of server-side frameworks and architectures... not Meteor though.
Meteor is an all-encompassing server+client package. You'd need to include all your angular application code along with all your ember application code because they share the same meteor server application and meteor is not built to separate clients from servers.
My bad experience and much of my frustration comes from Meteor's hype machine. This person was hyping Meteor as a production ready framework to a startup when it was not... hell it hadn't even reached the arbitrary 1.0 version number yet.
In fact, when Meteor upgraded to 0.9 it force upgraded everyone... i couldn't run `meteor -v` without Meteor saying "Upgrading to v0.9...", which of course would break all the atmosphere packages we were dependent on to have Meteor connect with all the normal functionality that NPM modules would offer.
Meteor evangelists will say "oh, but it wasn't 1.0 and atmosphere isn't a thing, or whatever", because it's always a deflection when it comes to this conversation. The fact that this is a thing that COULD happen is never addressed, the architecture and patterns that led to something like that happening is just ignored.
Disclaimer: I'm one of these "wide-eyed open-source evangelists", I guess.
http://larseidnes.com/2015/01/05/the-wtf-factor-quantifying-...
I've heard people using Meteor on Heroku, DO, etc. but I've always wondered why someone would choose Meteor's hosting rather than host Meteor on Heroku (for example) and use a ton of other available plugins.
That's interesting. Thanks!
If you invest in 9 companies that use Meteor then investing in Meteor means you've invested in those 9 companies. It's an investment in infrastructure.
Until they stop using Meteor.
Except that I don't think you could find a single a16z, Matrix, or Trinity startup actually using Meteor in production.
Meteor is great for toys and prototypes. But as soon as you start wanting to build an actual organization and team, it's the exact opposite of what you want.
The complexity of this is why I always end up reaching for hosted WS solutions like pusher or fanout.io.
However I always ended up using Playframework for WS, since it's really really easy to set this up in a scalable way.
It's not something you need to worry about for small applications, but for a scalable architecture, it's important to know the details of how this works. What happens to Meteor (or Play) with 100k simultaneous connections? How much ram and how many servers will I need? How do I load balance WS data between them? Will another datastore like redis be required? If so, how does it integrate with the framework? What if I outgrow a single instance of that datastore?
If I use pusher, I don't have to think about any of this.
It's a terrible model, but hey... Clinkle.
Bless me with your downvotes Meteor zealots! I'll still be here when Meteor is has gone the way of Flash and ColdFusion.
There are lots of open-source and "viable" web frameworks out there.
People want Meteor because it makes a lot of promises regarding productivity, but (as the presence of this article and multiple comments prove) the real interest is in a framework that has money for continued development.
So without the financial backing Meteor is just another open-source web framework. Except if that happens, instead of just replacing it with Angular, Ember, Knockout, etc, you'll also have to replace the entire backend too!
I've already had to do this and while I enjoyed it in some ways and learned a bunch... I really don't think that my company enjoyed paying me to rebuild a platform that they already paid for because the Meteor evangelist they hired before me decided they wanted to be an overpaid consultant instead.
I can't speak for others, but the reason I find meteor interesting is because it's one of the only frameworks to address isomorphic javascript, and because it has some really interesting realtime features out of the box. The fact that it's backed by a team that has some venture funding (and therefore some runway to continue improving it) is a definite plus.
> So without the financial backing Meteor is just another open-source web framework.
I don't understand this point. Even _with_ the funding meteor is just another open source framework. Isn't it great that we have a number of open source framework options to suit different needs?
> I really don't think that my company enjoyed paying me to rebuild a platform that they already paid for because the Meteor evangelist they hired before me decided they wanted to be an overpaid consultant instead.
You haven't really explained _why_ you needed to rebuild it. Perhaps meteor didn't suit the use case for this project or perhaps you felt more comfortable/productive in another framework. You haven't really made a case against meteor or a convincing argument about why adopters would need to switch to another framework if MDG failed as a commercial business.
A) With financial backing Meteor is an open-source framework which MUST provide an ROI for those backers.
B) Read the comments, the reason Meteor is more hyped is because it is funded. The reason people use to justify the enormous investment in building a production app with Meteor is based on it being funded. Take away the funding and you take away a compelling reason to use it... so if that reason is removed after you have already invested, you have lost on your investment.
Meteor was not the right tool for the job, but good luck trying to have that conversation with a Meteor evangelist. Just like any other evangelist they're pragmatic when it suits their argument and dogmatic whenever it doesn't.
In closing, I'm not against Meteor as a tool. I love tools and I love a lot of the concepts in Meteor (not isomorphism, that is a fools errand).
What I don't love are people/companies that misrepresent themselves and put more money into sounding good than they do into actual being good.
My experience using Meteor was resoundingly negative and yet negative experiences are shouted down while positive ones are lauded. The "maybe it didn't suit your use case" only comes up when I show I'm willing to stick to my guns and articulate myself.
Want to convince me Meteor is really dedicated to being a great and lasting web framework and not just a cash grab? Why don't you put an article to the front page of HN describing the use cases that Meteor ISN'T good for?
You admit they exist, so why not, right? They could learn a ton about their product while being brutally honest about its limitations with the community they want to win over.
Of course, it'll never happen, because Meteor isn't really a community project to build the next best framework. It's an investment vehicle and no investor would ever willingly let doubt be shined on their investment vehicle.
With this 20M, Meteor just became a heavy-weight—
That said, I still like the idea of a more community-drive approach.
http://careers.stackoverflow.com/company/edthena
If interested, you can apply through the site or just email me: dave at edthena dot com
Feel free to reach out to me directly at kevin at hedgy dot co
1. You can write allow/deny permissions rules to allow only certain modifications: http://docs.meteor.com/#/basic/Mongo-Collection-allow
2. You can not use client-side modifications at all and instead write all of your database code inside Methods, which are basically supercharged RPCs that give you automatic optimistic UI updates: https://www.meteor.com/try/10
I think this issue comes up a lot because new Meteor apps come with the "insecure" package by default to enable faster initial development and debugging, but most or all production apps will remove this package.
(I work at Meteor)
Is it? http://benchmarksgame.alioth.debian.org/u64/javascript.html
Its also fairly obvious that a statically typed / compiled language will have better performance than an interpreted language. Compiler optimizations make a huge difference as well.
Also, even the link you gave shows js being slightly faster in 2 or 3 benchmarks, but for the remaining 4-5, java is significantly faster.
If it was MSFT trying to pull this off, would the reaction on HN be as positive?
At least judging by www.meteor.com, they are still insisting their users accept the risks[1] of javascript and sending an empty body tag.
[1] If you think these risks don't exist, you haven't been paying attention. I don't care if you want to run exploit code from an ad or be used as ammunition by the Great Cannon; just don't insist that others must accept that risk if they want to read your page (slower loads or reduced functionality with the javascript is perfectly fine).
edit:
So you all value convenience over safety. really, it's probably because you're so used to spying on people that the idea of losing that ability is a thought you cannot abide. After all, why would the idea of losing javascript be attacked so strongly? This gets downvotes faster than anything else. What a lot of website developers don't seem to understand is that recording hover times, click paths, reading times and the like may be "metrics" or "important business data" to you, to normal people that is "creepy peeping-tom" behavior.
I know, you're thinking that this is off topic, or that it's just a tool. No, you're making a political/sociological decision by forcing people to take the risk of javascirpt - and business recording information about people is risk #1.
The non-technical people I know, after slowly learning about how the tech industry really works, have been doing a lot to reduce their internet use. A few have turned luddite. Others are trying to reduce their dependence on network services. That is the end game of people finding out the real price of using some webapp - you're driving people away from the entire concept.
Of course, I'm wasting my breath - clearly the features of some tool are more important than the reality of the future you're creating.
Either that, or djb is right. ( http://cr.yp.to/talks/2015.05.08/slides-djb-20150508-a4.pdf )
There's also a couple of libraries that implement server-side rendering if the blank page is something that disturbs you.
Ps the loads are faster due to caching & are highly CDNable as they don't change at all. Mostly static.
For the great canon issue: it's not difficult to check against a hash on the script either right? Besides not exlusively being a Meteor problem.