

Meteor Raises $20M - brendannee
http://techcrunch.com/2015/05/19/meteor-raises-20m-to-build-the-one-javascript-stack-to-rule-them-all

======
sergiotapia
I looked into Meteor and it's amazing how everything clicks together. It's
just such a drastic change in complexity and feels like a breath of fresh air.

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.

~~~
juliangregorian
I'm apprehensive of the security model. Everything is highly ease-of-use
optimized, to the point that you can query Mongo via the browser console.

My preferred "easy/simple" model of app design is Firebase (backend and JS lib
for pure web clients), who have security figured out.

~~~
sergiotapia
What you're saying is only true on a barebones default Meteor app. Please
don't comment on a tool if you've never used it for anything other than a
hello world, you're doing a very sophisticated tool a huge disservice.

You remove the autopublish package and you can no longer query records from
the client.

~~~
debaserab2
There's no excuse for insecure defaults.

~~~
matthewdav
I disagreed, in OWASP: It is important to understand that by no means does
“Secure Defaults” mean turning off all possible network applications or
sockets and services. And neither do Secure Defaults mean a 100% secure
environment. But, they should ensure the least number of possible loopholes
and fewer drawbacks.

Likewise, no matter what languages, majority are insecure by defaults.

~~~
debaserab2
What other tech stack allows you to publicly query the application data source
by default? I think it's fair to say that shouldn't be possible and I'd be
hard pressed to believe that OWASP would disagree with that.

------
egeozcan
I think the primary focus on further development in Meteor should be
supporting additional databases officially, and after that, supporting
operational transformation and conflict resolution strategies come to mind. In
my opinion, they are the biggest hurdles towards creating reliable real-time
applications.

Official React or Angular support isn't a game-changer. They can already be
integrated easily with the reactive data providers.

~~~
kansface
How often do you need OT in practice?

~~~
dorian-graph
Depends on what you're doing. I'm needing it for my thesis -> app and will
probably use ShareJS for now.

------
shams93
Lol Meteor just literally saved my bacon, the combination of meteor + ionic
enabled me to build an entire app in less than two weeks working part time on
it and if I hadn't told the client it wasn't native there was no way for them
to tell, the performance is that good. Plus the error messaging is awesome and
the isometric approach is just a huge win, the previous version of the product
was in angular + rails, industry standard but slow as hell, absolutely did not
perform like a native mobile app, but Meteor is just fantastic in my
experience for extreme starup scenarios where we are going with Mongo anyways.
Certainly if I needed to tie into legacy sql based systems I would be looking
at loopback, but with lookback you are still stuck with the weight of the
other available front end frameworks and the back end is easier, but you still
have to do tons of boiler plate, except perhaps with react + loopback in the
case of place a really modern front end on a legacy system while still having
ok performance. Meteor feels native because you're not issuing all this old
ajax, its data format is even smaller and tighter than json.

------
ep103
I just wish it wasn't so tightly integrated into everything. I'd love to use
Meteor as a library, but I'm always afraid of choosing something that I can't
replace later.

Either way, best of luck to them!

~~~
adyus
You could always use the DDP library [1] ("REST for websockets") for realtime
transfer. It's separate from the "core" Meteor package (a collection of
packages, really).

There's also a list of libraries for other languages that communicate with
Meteor via DDP. [2]

[1] [https://www.meteor.com/ddp](https://www.meteor.com/ddp) [2]
[http://meteorpedia.com/read/DDP_Clients](http://meteorpedia.com/read/DDP_Clients)

------
murbard2
I'm actually looking into meteor at the moment, and the financial backing is a
big plus, as it gives me some guarantee that the project will keep being
maintained for the foreseeable future.

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?

~~~
sergiotapia
Do yourself a favor and set aside a weekend to go through this book:
[https://www.discovermeteor.com/](https://www.discovermeteor.com/)

All of your questions are answered there.

~~~
afandian
As an onlooker that's discouraging. Can you give one-line answers to the
points above?

~~~
DiNovi
Cant tell if this is sarcasm or not :P

~~~
afandian
No, genuine comment. Those are reasonable questions, and the answer "spend a
weekend reading a book" isn't great.

------
cdnsteve
Has anyone seen DDP used outside of Meteor?
[https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP...](https://github.com/meteor/meteor/blob/devel/packages/ddp/DDP.md)

~~~
rgoomar
I haven't seen a push for it outside of Meteor yet, but i'm sure that is one
of the things that they would want to push for later.

Although, there are various DDP clients for other languages as you can see
here:
[http://meteorpedia.com/read/DDP_Clients](http://meteorpedia.com/read/DDP_Clients)

------
TimJRobinson
Is anyone here running Meteor in production? I've seen so many intro's and
demo's and prototypes but have yet to see any actual products / companies
built around it yet.

~~~
clement75009
A couple months ago we launched edgee, a platform for sharing high-quality
content in carefully curated collections, called edgees. The app runs on
Meteor and we're very happy with it.
[http://www.edgee.com](http://www.edgee.com)

~~~
MajinOLesedi
Great site, awesome UI. I'm also working on a web app using Meteor. This just
gave me some inspiration.

~~~
clement75009
Thanks for the kind words :)

------
nichochar
I like meteor, I think it's a good framework, that solves well the "Make a
webapp with non critical data but where real time is critical" problem.

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

~~~
wmf
It's way too late for that anyway. AFAIK DerbyJS was better than Meteor all
along but no one has heard of it.

~~~
akhatri_aus
I've heard of it and have used both and disagree.

Keep in mind both are open source projects. The community has been immensely
successful filling up Meteor's gaps.

~~~
gooseus
The investors are extremely appreciative of that... it'd be a shame if they
had to invest in actual filling out their own gaps with the 20M they've
raised.

That money is better spent convincing other developers that Meteor has no
gaps.

------
galfarragem
I think the main issue with Meteor is that it has the possibility to change
the status quo and be an important player in the market. That 'pisses' a lot
of people (like once rails did) because it might turn some of their personal
investment into obsolete. I am not 'invested' (my background is not CS) but if
I was, I would certainly be pissed also.

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.

------
smaili
Not trying to sound like a jerk, but I'm just wondering is it really a good
thing to put on your homepage that there are nearly 12K questions posted on
StackOverflow about Meteor? Seeing a number like that makes me wonder if maybe
the documentation and or APIs are not very well done if it's generated that
kind of activity on SO.

~~~
gooseus
Maybe you're right and everyone else on this comment thread are suffering from
some cognitive dissonance?

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.

~~~
ibejoeb
I wonder where all of the dislike for Meteor originated. It's a cool product
built buy some really smart people. They have the best cli tool I've used in a
dev environment, and they're making a ton of progress. They're constantly
publishing materials on integrating with third-party components including
react, rethinkdb, famo.us.

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.

~~~
gooseus
Seems to me I'm one of the few people who are willing to openly express their
dislike while also having a real life use case where it caused harm to a
startup actively seeking funding.

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.

~~~
ibejoeb
How did Meteor fail and cause harm?

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/](http://angular-meteor.com/).

* Here's talk given about using React: [https://youtu.be/-QtrkXKvQFc](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...](https://github.com/meteor-stream/meteor-postgres/wiki/Getting-Started)

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.

~~~
gooseus
If I want to use Angular, I can include a single javascript file and then
bootstrap my entire page, or a portion of the page with an application module.

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.

------
smanuel
That's cool. Does Meteor actually make, sorry for using such a dirty word,
money from something?

~~~
rezistik
Some investments are multipliers not profit centers.

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.

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

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.

------
danenania
Beginner question: how does Meteor handle storing server-side web socket
connections in a scalable way? Are they kept in ram? Redis? Mongo's ram?

The complexity of this is why I always end up reaching for hosted WS solutions
like pusher or fanout.io.

~~~
merb
Why is this complex? There are so many ways for pub/sub implementations.

However I always ended up using Playframework for WS, since it's really really
easy to set this up in a scalable way.

~~~
danenania
WS are fundamentally more complex than HTTP since connections are stateful and
that state needs to be stored somewhere. It's another dimension that needs to
be properly distributed and load balanced to be scalable.

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.

------
rywalker
Congratz to a very smart team. Love how Meteor seeks to include other good
Javascript frameworks into the platform (like React, Angular), rather than
trying to force an artificial "one true way" — looking forward to seeing
Galaxy.

------
auvi
Can anybody tell me what is the business model of Meteor? If they are getting
investments, the investors has some idea of a ROI and what that could be?

~~~
rglover
They're working on a paid hosting platform called Galaxy that will be designed
for quick, easy deployment of Meteor apps. If you work with the framework now,
you can deploy to an early version of Galaxy using the command `meteor deploy`
(yes, that's it) from your project directory. The goal is to keep that level
of simplicity, but offer a platform that's production-grade.

------
richenglish
What happens to Meteor if Galaxy fails as a commercial endeavour?

~~~
DeBraid
[https://github.com/meteor/meteor](https://github.com/meteor/meteor) is open
source, so the community will be tasked with maintenance in the case of MDG
running out of money.

~~~
gooseus
When Meteor is no longer commercially viable and runs out of venture capital
brewed hype-juice everyone will jump to the Next Big Thing and companies that
listened to their Meteor evangelist will have to furiously find someone to
port from Meteor to ANYTHING so they can continue to build features and
support new services.

Bless me with your downvotes Meteor zealots! I'll still be here when Meteor is
has gone the way of Flash and ColdFusion.

~~~
rralian
As mentioned, it's open source and gaining traction. If MDG goes away, I see
no reason why meteor could not or would not stand as a viable web framework.

~~~
gooseus
Gaining traction because of the venture capital hype juice I mentioned.

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.

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

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.

~~~
gooseus
What about "isomorphic javascript" needs to be addressed? That was a term that
almost seems invented as a problem for Meteor to solve. The fact that code in
completely different environments (browser vs server) needs to look different
is not something that needs to be addressed.

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.

------
M8
Oh, so that's why they have been trying to sell it here on HN.

------
arxpoetica
A few of us have been happily hacking away on SocketStream
([https://socketstream.com/](https://socketstream.com/)) for quite sometime.
It's a smaller, piecemeal framework that borrows more from the community of
Node pluggable/playable modules.

With this 20M, Meteor just became a heavy-weight—

That said, I still like the idea of a more community-drive approach.

~~~
arxpoetica
Also, shameless plug, but we've been keen to sponsorship and/or other
contributors to get a little more momentum in the SS community. Ping me over
here if interested so I don't completely derail this thread. ;)
[http://robertlangfordhall.com/contact/](http://robertlangfordhall.com/contact/)

------
BurningFrog
Is anyone hiring Meteor developers? In the Bay Area?

~~~
dweldon
Yep, Edthena is! You can see our profile and job description here:

[http://careers.stackoverflow.com/company/edthena](http://careers.stackoverflow.com/company/edthena)

If interested, you can apply through the site or just email me: dave at
edthena dot com

------
dovg
Serious question: does Meteor scale well in these days?

~~~
davidjwoody
Just published a post related to this topic. Short answer: Yes. -
[http://blog.differential.com/scaling-meteor-
to-20000-users-i...](http://blog.differential.com/scaling-meteor-
to-20000-users-in-7-days/)

~~~
Everhusk
Awesome job and congrats on the massive traction on launch day. Thanks for
sharing!

------
Kiro
What I don't understand with Meteor is how you can build secure applications
if you actually write your database queries in the front-end. Can someone
enlighten me? How do you hide logic or prevent people from manipulating
however they want?

~~~
djmashko2
Database modifications on the client are usually disabled in Meteor. There are
two ways to control database access in Meteor:

1\. You can write allow/deny permissions rules to allow only certain
modifications: [http://docs.meteor.com/#/basic/Mongo-Collection-
allow](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](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)

------
_greim_
My worry is that with JavaScript-based stacks evolving so fast these days,
monied interest in one way of doing things would ultimately be incentivized to
suppress better ways of doing things, as they emerge.

------
aliakhtar
For those who're looking for a full stack framework, I can't recommend GWT
enough. GWT lets you write java for both client & server, and then compiles
the client code to javascript. This compiled js is highly optimized and your
css / images / html templates are bundled together to minimize HTTP requests.
On the server side, this lets you use java which is a lot more performant than
javascript is.

~~~
smileysteve
> On the server side, this lets you use java which is a lot more performant
> than javascript is.

Is it?
[http://benchmarksgame.alioth.debian.org/u64/javascript.html](http://benchmarksgame.alioth.debian.org/u64/javascript.html)

~~~
aliakhtar
Yep:
[https://www.techempower.com/benchmarks/](https://www.techempower.com/benchmarks/)

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.

------
neumino
Woot, congrats folks!

------
atmosx
Out of curiosity, did ever rails raise any money?

------
yedpodtrzitko
[https://xkcd.com/927/](https://xkcd.com/927/)

------
debaserab2
It's amazing how many developers willingly giving up their entire tech stack
in exchange for a proprietary one.

If it was MSFT trying to pull this off, would the reaction on HN be as
positive?

~~~
trcollinson
Maybe I am getting lost in your comment but, are you trying to suggest that
Meteor is a proprietary stack?

------
pdkl95
_sigh_

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](http://cr.yp.to/talks/2015.05.08/slides-
djb-20150508-a4.pdf) )

~~~
akhatri_aus
Most sites use javascript anyway. How is this different? If people want to use
Meteor to solve their business problem (even internally) how does the
negligibly low chance of a great canon infecting a site make this different.

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.

