Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What's coming in Meteor 1.2, and beyond

info.meteor.com

Post reply on HN
Print view View original

31–40 of 98 posts

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

#31

Post by clessg »

liamzebedee wrote: post #8

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…

Oh man, mixing tabs and spaces...

React and Meteor work really well together. It's a lot less painful than trying to use Flux with an API backend. Super productive. Can't wait for SQL support and for them to FINALLY fix the build speed.

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

#32

Post by 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' :)

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

#33

Post by Siyfion »

honest_joe wrote: post #11
liamzebedee wrote: post #8

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…

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

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.

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

#34

Post by mcgaffin »

ruswick wrote: post #6
sarciszewski wrote: post #5

And yet they still tell people to install Meteor by piping to their shell. Incredible. http://curlpipesh.tumblr.com/ https://paragonie.com/files/blog/pipeshell.jpg

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

Docker addressed this last week at dockercon, announcing Docker Notary to securely publish and verify content.

https://github.com/docker/notary

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

#35

Post by joepie91_ »

rimantas wrote: post #26
joepie91_ wrote: post #9

Earlier quoted context omitted.

It being a common thing is the problem. It's teaching insecure habits.

Ok, I wonder how many do bother to check checksums after downloading binaries?

Many do, likely without even realizing it. It's common functionality in Linux package managers.

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

#36

Post by joepie91_ »

logicallee wrote: post #20
joepie91_ wrote: post #9

Earlier quoted context omitted.

It being a common thing is the problem. It's teaching insecure habits.

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?

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

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

#37

Post by liamzebedee »

honest_joe wrote: post #11
liamzebedee wrote: post #8

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…

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

Well I think it's a different - my app really only deals with very simple form inputs and interactive views, there's no performance issue to think of. Text editors deal with file systems, buffers, displaying text, plugins, a bunch of other things.

That being said, I get two threads inherently as a result of the client-server separation, and on the Meteor server you can properly parallelize the work as a result of its Node foundations.

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

#38

Post by acyacy »

sarciszewski wrote: post #5

And yet they still tell people to install Meteor by piping to their shell. Incredible. http://curlpipesh.tumblr.com/ https://paragonie.com/files/blog/pipeshell.jpg

There's nothing it can do more than downloading a binary and running it and it asking you to run it as root.

Except piping to shell is more convenient.

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

#39

Post by logicallee »

sarciszewski2 wrote: post #28
logicallee wrote: post #27

Earlier quoted context omitted.

if you're going to include "2a" you can refactor all of your steps into: 1. Google "meteor.com compromised" and decide whether it's currently compromised. If it isn't: 2. Run curl https://install.meteor.com|sh It saves a few steps and is equally secure - you know, since you're just going to go based on what other people think and include no programmatic check whatsoever. (your 2a).

2a can be swapped out for a better PKI system at any time. Relying on whether it's public knowledge that Meteor is compromised or not is not nearly as resilient.

so swap it out for a better PKI system. There is literally nothing in any of your steps that can't be automated, except for the totally nebulous 2a "publish in the blockchain, have lots of high profile technologists sign it" which 9/10 people are not qualified to judge.

There is no reason you couldn't automate your whole suggestion, except for that one, which makes it infeasible and open to all manner of social engineering.

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

#40

Post by logicallee »

joepie91_ wrote: post #36
logicallee wrote: post #20

Earlier quoted context omitted.

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?

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

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.

Post reply on HN