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

81–90 of 98 posts

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

#81

Post by jkarneges »

pbowyer wrote: post #78
pmontra wrote: post #65

Earlier quoted context omitted.

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…

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

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

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

#82

Post by twerquie »

pdkl95 wrote: post #66

So when is Meteor going to start sending actual web pages? I ask here, because seeing a blank page that consists of 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.

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.

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

#83

Post by nilliams »

jkarneges wrote: post #62
kidsil wrote: post #61

Earlier quoted context omitted.

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 r…

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 c…

> 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://www.socketstream.org

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

#84

Post by nacs »

marknutter wrote: post #80
leeleelee wrote: post #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…

I've used that combo for many projects. I gave a talk on it last year at a local AngularJS Meetup: https://www.youtube.com/watch?v=vCExKhJCUM8

Just curious, was the "hack" in the Live AMA someone just incrementing the upvote endpoint with a larger int or an actual exploit someone found.

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

#85

Post by tacone »

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

Why do you ask about Atom performance?

Not sure if I understand the reasons, BTW FYI they recently stripped off react in favor of plain DOM for performane reasons: https://news.ycombinator.com/item?id=9117028

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

#86

Post by pdkl95 »

twerquie wrote: post #82
pdkl95 wrote: post #66

So when is Meteor going to start sending actual web pages? I ask here, because seeing a blank page that consists of 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.

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.

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

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

#87

Post by trcollinson »

pdkl95 wrote: post #86
twerquie wrote: post #82

Earlier quoted context omitted.

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.

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 may…

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.

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

#88

Post by jxm262 »

clessg wrote: post #31
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.

You caught my attention with this "alot less painful than trying to use Flux with an API backend" Can you elaborate a bit on how you architect your apps with Meteor and React?

I've typically tied my Flux Action layer to my api backend (where my ajax code goes) which then dispatches to the Store layer, then the View (react components) listens to that...

With Meteor where are you hooking your api backend into the react components? I'm a little lost looking for decent examples of different Meteor/React architectures.

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

#89

Post by joepie91_ »

logicallee wrote: post #56
joepie91_ wrote: post #43

Earlier quoted context omitted.

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) -…

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

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

#90

Post by spinningarrow »

clessg wrote: post #31
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.

How are they mixed? It looks like only tabs to me.
Post reply on HN