
What's coming in Meteor 1.2, and beyond - rgoomar
http://info.meteor.com/blog/whats-coming-in-meteor-12-and-beyond
======
Rezo
It is highly encouraging to me that Meteor is acknowledging the larger trends
in the Javascript ecosystem and promoting React to an officical frontend layer
instead of doubling down on their homegrown solution. Likewise for seamless
Babel integration and planning the move to official ES6 modules.

Buying into a full-stack solution like Meteor is a scary proposition; you're
giving up a large amount of control for a promised big increase in immediate
productivity (which I do feel Meteor delivers on). This blog post goes a long
way to alleviate my fears and makes it more likely I'll use Meteor for certain
future projects.

~~~
kidsil
Honestly I'm very likely to stick with Blaze for the time being, as I've found
it easier to follow & understand than Angular (haven't tried React yet).

I just like the sticking with general modularity approach (that really reminds
me of Ruby).

I don't think the Meteor proposition is any scarier than getting into Rails,
Django, or even Laravel. You're basically trusting a growing ecosystem that
will prevent you from re-inventing the wheel.

~~~
jkarneges
Rails, Django, and Laravel are all server-side frameworks. You could replace
one with another, without having to rewrite any client code.

Meteor is all-encompassing, covering both the client and server. That means
you have much less agility in terms of swapping out components, but of course
its convenience is unparalleled.

Actually this has me wondering, is there anything else out there like Meteor
that covers both client and server development at the same time? Maybe GWT?

~~~
nilliams
> Actually this has me wondering, is there anything else out there like Meteor
> that covers both client and server development at the same time?

There's also Derby.js and Socketstream which arose around the same time as
Meteor:

[http://derbyjs.com](http://derbyjs.com)

[http://www.socketstream.org](http://www.socketstream.org)

------
liamzebedee
Official React support - woohoo! I've been using React and Meteor together to
build a desktop web app for quantified self, and I have to say, the
combination is magnificent for productivity. The app is 90% JS and a little
CSS, and reactively updates with no extra code. MongoDB and server logic is
separated from the client-side view rendering, so if I wanted to make it a
thin client and remotely host the computations on another server it would be a
piece of cake.

An example file of code for the records overview (dashboard was a bit tabby-
spacey):
[https://github.com/liamzebedee/metric/blob/master/client/fea...](https://github.com/liamzebedee/metric/blob/master/client/features/RecordsOverview.jsx)

~~~
honest_joe
How is the performance ? For me something like Atom feels very sloppy compared
to Textmate / Sublime

~~~
Siyfion
Have you tried Atom since they shipped version 1.0? It's been sped up a LOT.

However, I don't really think that this topic has much to do with React /
Meteor, as Meteor is a full-stack web-solution, Atom is a desktop text-editor
built with web technologies (and specifically React)... It's like saying my
Ferrari goes faster than your boat, yup, on land.

~~~
honest_joe
I know but i have commented on a guy's post talking about building desktop web
apps.

Also yes i have tried the latest Atom's version. I am not bashing it's just
that i feel that the performance is still worse than the native solution
(obviously).

------
matthewbauer
When ES6 and web components come out, are we even going to need frameworks
like Meteor? It seems like all of the advantages of MVC frameworks go away
once you can create controllers and models in native Javascript and views in
native HTML.

~~~
Siyfion
It's completely different from ES6, it's a full-stack framework, so it does SO
much more than just a front-end framework.

Meteor's main selling point is the reactivity; you can call `Books.insert({
name: "test" });` on the client, in-browser and it then updates the UI
optimistically, updates the DB on the server AND propagates the change to all
other clients, which in turn updates their UIs. All with one line of code.

Take a look at DDP, one of the core building-blocks of Meteor:
[https://www.meteor.com/ddp](https://www.meteor.com/ddp)

~~~
joshburgess
Is DDP or Meteor really needed though? Couldn't you easily set this up with
RethinkDB using its Changefeeds killer feature for real-time + socket.io along
with whatever other library/frameworks you want to use without ever touching
Meteor?

~~~
xbryanx
Yes, you totally can, but I found running one command:

curl [https://install.meteor.com/](https://install.meteor.com/) | sh

so much quicker (in the short term and long term) than reading a myriad of
tutorials and then bashing my head against this configuration of several
products for multiple weeks to get what Meteor provides as part of a single
maintained and updated system.

------
DeBraid
tldr: ES6 = standard, SQL support is coming, faster builds and mobile
toolchain development a priority. Reactive rendering with Blaze, Angular or
React + Meteor is available.

~~~
mrcwinn
SQL support has always been "coming." It's been on their Trello roadmap for
more than a year. The specific messaging in this post is that the new version
of Meteor is coming late this summer, will not include SQL support, but that
SQL support is something on their radar for the future (late in the year? next
year?)

That bit is not news or anything new.

~~~
djmashko2
I think the intention is to signal that SQL is likely to be one of the things
we work on immediately after 1.2 is released.

------
leeleelee
Anyone out there using Angular and Firebase? That's been my go-to "stack" for
achieving 3-way binding of the UI, javascript model, and remote database. The
only downside is that you're locked into using firebase as a service, can't
host it locally, and you're limited to what their API supports. It's amazingly
fast in terms of ability to churn out features.

Meteor seems to be the only thing that comes close to giving offering the same
amount of productivity as I can get using Angularfire.

Has anyone used both, that can comment?

~~~
pmontra
I did the design of a project that used Angular inside Ionic with Firebase as
backend. They integrated well, no particular problem. Just be careful not to
keep websockets open unless those you really need. Close the others. They'll
keep the CPU busy and bleed the battery.

The only major problem was with Firebase itself, when we had to start
duplicating data because it's a tree and it doesn't have joins. But it would
be unfair to complain because it's like that by design and we knew what was
expecting us. Is there any service like Firebase but with joins?

~~~
pbowyer
I haven't used Firebase, but would RethinkDB with its real-time feature be an
alternative that has joins? It has the drawback that it'd be self-hosted, but
apart from that..?

~~~
jkarneges
There's also Compose.io for a hosted RethinkDB.

------
pdkl95
So when is Meteor going to start sending actual web pages? I ask here, because
seeing a blank page that consists of

    
    
        <body>
        </body>
    

Isn't very useful. ES6 is nice... _when javascript is available_. I know it's
current popular to pretend that progressive enhancement is too much work, but
that doesn't change the fact that your site doesn't even have an error mesaage
when javascript is filtered at the firewall.

~~~
twerquie
There is a difference between web pages and web applications, and Meteor is
built for the latter. There is no such thing as a progressive enhancement path
in many cases. If your firewall (?) strips out JS, then you are on a broken
network.

How does it do that anyway? Most sites are HTTPS.

~~~
pdkl95
Yes, there is a difference between pages and apps. You should still not send
only empty body tag. Click link, see blank page - how am I to know what kind
of page it is? I'm really only referring to _documents_ (like www.meteor.com,
I presume - I can't actually read it from this computer as it's a blank page).
Even on "web apps", there should really be at least an error indicating that
the app only works with JS, or maybe a link to a fallback/alternative if
appropriate.

Note: a search page is not an "app". Progressive enhancement works just fine
in almost every case that isn't a purely interactive app (i.e. google maps or
a game). It is trivial to render, as needed, the HTML template with the
header/footer, or a layout-free snippit, or simplee JSON, or whatever else is
needed. This was basically zero extra work in Rails years ago, so I don't see
why it can't be done now.

As for stripping JS, that is easy, and done for security reasons. Yes, this
requires a custom cert so the firewall can MITM the connection, which most
businesses do anyway. No, this does not make it a broken network. Javascript
is optional, and always has been. ( [http://www.sitepoint.com/javascript-
dependency-backlash-myth...](http://www.sitepoint.com/javascript-dependency-
backlash-myth-busting-progressive-enhancement/) )

~~~
trcollinson
There is actually nothing in meteor which states that you have to have only a
body tag in your html. In fact, you can very simply render html headers,
footers, and other static html without javascript. You can also handle 404 and
send static pages for such appropriately. If someone has misinformed you, do
take their opinion as nothing more than nonsense.

Now if you happen to run across a site which does not handle this properly,
that is not shocking in any way. I have found that generally speaking those
who disable javascript often complain about sites which extensively use
javascript. They say things like "you can't assume that everyone has
javascript enabled", "javascript is a security hazard and you can't expect me
or anyone else to run a site with such a blatant vulnerability", and "how dare
sites use such shotty technology to give an experience, they need to realize
we need the same experience but without all of the vulnerabilities". The list
of complaints go on and on.

The reality of the situation is this: as someone who makes consumer
applications for profit, most of us don't care about you. If you are willing
to turn off javascript, you are probably not my target user. If you work in an
organization which does something so stupid as to break ssl in order to commit
mitm attacks on your own employees in the name of security, you are probably
not my target user. I do this for profit, not to cover ever last edge case
known to man for every "security conscious" consumer of the Web. I worry about
the security of my actual users. I worry about giving them the best possible
experience. I care that they can use the product and enjoy it and will come
back again and again. Javascript is optional for you, but it is not option for
my applications. Hundreds of thousands of my users don't seen to mind.

~~~
pdkl95
> nothing in meteor

That's actually very informative. ?I guess www.meteor.com is one of those
sites that doesn't handle it properly? I? have no idea.

> Hundreds of thousands of my users don't seen to mind.

Really? Have you asked them?

Hundred of thousands of your users probably have _no idea whatsoever_ what
their browser is doing, and it is disingenuous to say that they "don't mind"
\- _especially_ when javascript is used for things like tracking reading times
and other things probably call "analytics" and a lot of us call "spying".

> I worry about the security of my actual users.

Apparently not - you just make sure your users can only be people who know
nothing about modern network security.

Remember, I'm not saying javascript applications are bad or that you shouldn't
write them[1]. I'm saying you shouldn't leave your precious "user experience"
_in the case where javascript is not available_ as a totally-useless, non-
informative blank page. Which _many_ sites have started to do, www.meteor.com
included. Thqt''S IT. All this arguing about javascript is missing the point.

[1] At _most_ , I only suggested that a lot of the time what is being made is
_not_ an application", but a fairly simple document. The only reason
javascript could be _needed_ (isntead of progressively enhanced) on something
like a simple search page is if you are trying to run spyware (such as google-
analytics) in the background, behind the user's back.

------
mark_l_watson
Great news that ES6 support is shipping this summer. You can already use
Babel, but having everything set up by default, with examples using ES6 will
be great.

BTW, I wish there would also be built in support for Typescript. I have done
some simple experiments with Meteor and Typescript but it has a do-it-yourself
feel abut it. As much as I like Typescript, I will probably just use ES6.

------
viach
I started to use meteor a month or so ago. For a person like me, from Java
Enterprise land, this tool is refreshing. Glad to see new goodness is coming,
especially SQL support.

------
jxm262
Awesome!! never saw this link they've mentioned - [http://react-in-
meteor.readthedocs.org/en/latest/](http://react-in-
meteor.readthedocs.org/en/latest/)

I've been playing with meteor just recently and am totally loving it. I really
like Blaze, but love React's component system, so not really sure which way I
want to turn now... I'm almost thinking of just implementing a React-like
dictionary in Blaze to keep it more 'component' like , because I really
dislike the jsx transpiling.

Anyway these announcements are definitely making me more convinced that I
should try Meteor in a production app. I see many good things coming for this
project.

------
liadmat
Really glad to see React Native mentioned here, albeit briefly. Hybrid mobile
apps like the ones currently supported by Meteor always feel kind of clunky,
and the 3rd party implementations of DDP for iOS/Android feel like a
workaround and not the Meteor-way of doing things. Would be interesting to see
how React Native is integrated into Meteor. Though what I really want to see
is Blaze Native.

------
resca79
I never used Meteor but I was impressed by this framework 3-4 years ago. In
the last years with the javascript client/side logic growing it looked
obsolete in some components. But now with this new support of the two most
popular framework js and the support of Sql I think that is could be get more
developers and contributors 'than ever' :)

------
waterfowl
Is anyone else unable to log into meteor.com forums? I click log in, the popup
tells me I'm already logged in, click "use this account" and it drops me back
where I was with a modal(ugh) about making an account.

~~~
djmashko2
(I work at Meteor)

I'm sorry! I haven't heard any other reports of an issue like this; what
browser/system are you on?

~~~
waterfowl
No worries, really a minor thing but is happening for me on both chrome
latest(43.0.2357.130 64bit) and firefox developer 40.0a2 on OS X 10.10.4.

Click log in, pops up a window where I either login or it says "use this
account you're logged into?" and then drops me back at the forums with a
signup modal(and when I close that, still logged out).

Meteor has been great for me though, you guys are building(have built) a
really cool thing.

------
porker
> Meteor goes with Angular/React like peanut butter goes with jelly.

Terribly, then. ;)

------
chaostheory
Wow, when did they add database support? I'm pretty surprised it's been done
before this release.

------
Everhusk
Thought for sure this post was going to be all about Galaxy. Oh well, still
didn't disappoint :).

~~~
djmashko2
That wouldn't be about Meteor 1.2 - I don't think Galaxy will ship as part of
a Meteor release, but rather as its own product.

------
joshburgess
"We're going to support React and Angular!"

Translation: We're going to support the big JS names the general public is
most aware of, because... well... please, use Meteor.

------
sarciszewski
And yet they still tell people to install Meteor by piping to their shell.
Incredible.

[http://curlpipesh.tumblr.com/](http://curlpipesh.tumblr.com/)

[https://paragonie.com/files/blog/pipeshell.jpg](https://paragonie.com/files/blog/pipeshell.jpg)

~~~
ruswick
That's a pretty common thing. I don't see the problem.

~~~
joepie91_
It being a common thing _is_ the problem. It's teaching insecure habits.

~~~
logicallee
What do you think about this solution: introduce a layer on top of SSL that
just verifies whether the private key of a certain explicitly stated site has
signed a file?

In other words, compromising the server wouldn't be enough, because that
doesn't give you the SSL key, so it would still fail "curl|is_signed_by
site.com|sh", which they can only pass if they compromise the private key?

Better than the current system?

~~~
joepie91_
> compromising the server wouldn't be enough, because that doesn't give you
> the SSL key

But it does. The server needs to have the SSL key to be able to serve requests
over HTTPS.

It may be encrypted with a password, but at that point you're severely
degrading your integrity assurances (compared to offline executable/archive
signing). Might as well do it right with offline signing, right off the bat.

~~~
logicallee
interesting. What if a script just uses the SSL infrastructure to get the
private key associated with a domain name, without actually needing anything
at that domain name to come over SSL? Then the private key does not have to be
live/online at all, but could be used to verify the shell script. This is
getting complicated, but if there is infrastructure, it should be possible to
use it.

Personally I think curl of an https URL is not the worst thing in the world.

~~~
joepie91_
I think you need to read up a bit more on how asymmetric key cryptography
works :) Verification is done using the public key, the private key is used to
_sign_ something. That's why it's so useful. This is a good read if you want
to learn more: [https://www.crypto101.io/](https://www.crypto101.io/)

Basically, the separation between 'server serving the downloads' and 'machine
signing the release' is _intentional_ , and should be maintained. Consider it
an 'airgap' of sorts, although it usually isn't one in the strictest sense of
the word.

Making release signing depend on the SSL infrastructure (which is already
rather broken in a number of ways) in any way, is a bad idea. Verification is
a different story, but secure code delivery is a hard problem anyhow.

~~~
logicallee
I understand exactly how it works. How do you get a code-signing paradigm down
to something as simple as curl | sh though? (Well not _as_ simple, but still a
human-readable one-liner that works on nearly all Linux systems.)

I thought maybe a single-line invocation might piggy-back on SSL as follows:

\- get a server's public key that is not online or able to answer requests
(because if it were it couldn't be airgapped)

\- but still use the key to verify the script that's downloaded from the
server that _is_ online.

\- only pass the code to sh if it was properly signed by the offline server.

Then the offline server could be
"[https://key.meteor.com"](https://key.meteor.com") and the private key
wouldn't have to be anywhere but an airgapped machine.

I don't know if there is more of the SSL infrastructure that I'm missing
though (I'm not an expert) or if this could practically be reduced down to a
tamper-evident one-liner (a la curl
[https://install.meteor.com](https://install.meteor.com) | sh). It would be a
marked improvement over just passing anything from a potentially compromised
server straight to bash though!

~~~
joepie91_
> How do you get a code-signing paradigm down to something as simple as curl |
> sh though? (Well not as simple, but still a human-readable one-liner that
> works on nearly all Linux systems.)

You don't, really. Not currently anyway. Retrieving a binary/archive and doing
out-of-band verification are two logically separate steps.

The problem with your suggestion is that SSL is about _transport_ security. It
verifies that you are talking to the right server, but does not provide any
guarantees beyond that.

It's not really possible to shoehorn release signing into that, without
additional infrastructure.

It doesn't matter how you combine things - the server and the signing system
are (and should be!) two separate entities, and you cannot rely on the server
to tell you who the signing system is (because that'd give you no better
security than not having a signing system at all).

> It would be a marked improvement over just passing anything from a
> potentially compromised server straight to bash though!

It wouldn't, because as far as I can tell, you're _still_ relying on the
server to tell you what the correct release signing key is. How else would you
obtain it?

~~~
logicallee
thanks - drop me a line and I'll reply, this thread is getting old and deep.
thanks for your thoughts though and hope you do write.

------
kidsil
Yeah! I knew it wasn't just my gut feeling when I went ALL THE WAY with Meteor
:)

