Live data from Hacker News

What's coming in Meteor 1.2, and beyond

info.meteor.com

51–60 of 98 posts

Re: What's coming in Meteor 1.2, and beyond

#51
post #2

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.

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.

Re: What's coming in Meteor 1.2, and beyond

#52

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.

The web components spec is starting to look like a huge mess in comparison with modern JS framework component models. I think it's unlikely web components will much traction as a first tier approach to application development.

Re: What's coming in Meteor 1.2, and beyond

#53

Earlier quoted context omitted.

I've not used Meteor, but I understand one of its big selling points is 'optimistic UI', i.e. it alters models locally when changes are made, and syncs those changes with the server in the background, only changing the local model back again on failure to sync with the server. I don't know if this can be (or has been) extracted to a separate library or if this is part of the web components spec, but its something tha…

You ask a really good question. With all the myriad javascript libraries coming out weekly, you'd think we would all know of four different optimistic synch libraries off the tops of our heads, but I don't think I've seen any. Perhaps that's because in order to get it to work, Meteor has a bunch of code that (I think) watches Mongo's write-ahead-log, so you can't just make a front-end library for it. I think this is…

I had a good look for a library that does this for the app I'm currently working on, before giving up and creating a custom solution myself. My implementation is very much custom-fitted to my particular backend api and the way I'm rendering the view layer with React.

I think a large part of the reason such standalone libraries might not exist yet, is that it's really difficult to make a general, flexible, tech agnostic solution to this problem - as you've highlighted this is probably why Meteor's implementation is so tightly coupled with Mongo and why SQL integration is taking a while (assuming, surely, it must be a pretty high-priority feature on their roadmap).

In other words such a library is likely to be so prescriptive on how the rest of the stack, particularly the backend, fits around it that it only really makes sense as part of a full-stack framework, or at the very least a prescriptive full-stack architecture.

Re: What's coming in Meteor 1.2, and beyond

#54
post #29

Earlier quoted context omitted.

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…

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?

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

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

Re: What's coming in Meteor 1.2, and beyond

#55
post #29

Earlier quoted context omitted.

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…

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?

If you're willing to wait for a client-server round trip to visibly see your changes, then sure. Otherwise, you'll need a way to temporarily (optimistically) change your in-browser data model with the updates while waiting for the server to commit your changes, then figure out a way to reconcile the server commit of v2 while you might have done v3 on the client in the meantime... Optimistic updates are not at all trivial. Meteor has a ton of code that basically runs an in-RAM version of MongoDB and keeps it in sync with the server.

Re: What's coming in Meteor 1.2, and beyond

#56

Earlier quoted context omitted.

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…

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/ Basically, the separation between 'server serving the downloads' and 'machine signing the release' is intentional , and should be maintained. Consider…

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" 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 | sh). It would be a marked improvement over just passing anything from a potentially compromised server straight to bash though!

Re: What's coming in Meteor 1.2, and beyond

#57
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?

Re: What's coming in Meteor 1.2, and beyond

#58
post #51
post #2

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.

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.

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.

Re: What's coming in Meteor 1.2, and beyond

#59

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.

(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?

Post reply on HN