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

91–98 of 98 posts

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

#91

Post by spinningarrow »

joshburgess wrote: post #48
Siyfion wrote: 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?

You'll still miss out on the client side optimistic updates.

I think the main benefit of Meteor is not that it's impossible to do what it does with other libraries/frameworks, but how easy it makes those things for you.

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

#92

Post by pdkl95 »

trcollinson wrote: post #87
pdkl95 wrote: post #86

Earlier quoted context omitted.

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

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

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

#93

Post by tylerpachal »

Rezo wrote: post #47

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

It doesn't have to be a full stack solution.

From meteor's article about the DDP protocol [1]:

"...a mobile client written in pure Objective C, with no Meteor code, can connect to a Meteor server (say, by using the ObjectiveDDP library), and the server doesn't see it as different from any other client."

[1] https://www.meteor.com/ddp

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

#94

Post by clessg »

spinningarrow wrote: post #90
clessg wrote: post #31

Earlier quoted context omitted.

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.

Yeah, they were fixed after my comment. Actually, not sure why it isn't in the history for the file, but I know for a fact that the link provided mixed them.

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

#95

Post by clessg »

jxm262 wrote: post #88
clessg wrote: post #31

Earlier quoted context omitted.

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…

In fact, there was a blog post just written about this! http://info.meteor.com/blog/meteor-the-missing-infrastructur...

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

#96

Post by jxm262 »

clessg wrote: post #95
jxm262 wrote: post #88

Earlier quoted context omitted.

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…

In fact, there was a blog post just written about this! http://info.meteor.com/blog/meteor-the-missing-infrastructur...

Cool Thanks! Do you know if there are any plans to make a sample app on github for us to follow?

I'll try to do a rewrite of the example todo app using this for practice. Seems like I have a bit to read since this would seem to change the standard flow I'm currently using in my Flux pattern. Actually stumbled across this thread which gives some good reading as well - https://forums.meteor.com/t/meteorflux-flow/920/63.

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

#97

Post by logicallee »

joepie91_ wrote: post #89
logicallee wrote: post #56

Earlier quoted context omitted.

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

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.

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

#98

Post by marknutter »

nacs wrote: post #84
marknutter wrote: post #80

Earlier quoted context omitted.

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.

I didn't bother implementing any validation rules on the backend so it was free for people to change whatever they wanted using the debugger console.
Post reply on HN