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.
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.
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?
"...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."
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.
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.
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.
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.
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.
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).
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.
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.
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?
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.
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.
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.
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 that's pretty nice to have baked into the framework.
In fact the only reason I'm not using Meteor now is that it's still got a hard dependency on Mongo. I was disappointed to see that SQL support has not begun to come in yet with this update. Once SQL support is there, I will definitely be looking at using Meteor, particularly now it's got first-class React support.
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 also why SQL support has been slow to come.
There's Simperium (disclaimer: I was a cofounder, YC S10). It's powering optimistic sync for millions of users of Simplenote and WordPress.com. It has JavaScript[1] and Python[2] libs, but its strength is iOS[3] and Android[4].
The team focused on internal use though, and hasn't had a chance to open source the backend and flesh out the web side of things. I hope they get a chance to do another iteration (we were bought by Automattic/WordPress and I'm no longer there).
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.
That's basically my take on it, and we also have a bunch of custom code to do similar things piecemeal, but it doesn't work very well and I envy Meteor's solution, while remaining unprepared to jump onto the framework in its entirety. But lots of "really difficult" things have been accomplished in the past, so I'm still hoping to come across a "general, flexible, tech agnostic solution to this problem" at some point!
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.
Sure. Meteor can be used to implement your backend, frontend, or both frontend & backend. Web components are a frontend concept only [from what I understand]. Meteor's frontend code can "bind" to your backend, and render real time data updates.... while web components have no concept of "backend" at all.
There could also be a desire to wrap multiple web components into an Angular directive, or wrap multiple Angular directives into a meteor module, etc.
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?)
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.
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?
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..?
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.
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.
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... )
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.
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.
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.
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.
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.
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.
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' :)
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.
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.
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?
> 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.
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 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.
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!
> 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?
I am downvoting them because shell piping is not relevant to Meteor 1.2 announcement, this topic was discussed on multiple occasions and they offer no alternative.
They're announcing "hey we have these new features" and I'm saying "hey look, they still haven't fixed this big glaring problem that is very much relevant to how their software is used".
Downvoting because it's a non-issue. If I'm copying and pasting something from the web into my terminal, it's because I trust the source.
It's not any less secure than downloading a tarball and running scripts inside of it. That's equally insecure and people have been doing that since the dawn of the internet.
What do you want them to do? The obvious solution is to change it from "curl|sh" to "curl|{something about whetehr PGP says this is properly signed by the private key belonging to public key blahblahblahblahbalhMETEOR.COMkey. If yes:}|sh"
But the problem is anyone compromising the site can just change the line from "blahblahblahblahbalhMETEOR.COMkey" to "attackerchangedblahblahblahblahbalhMETEOR.COMkey" right on the web page, and people will copy the one verified against the wrong key. So that doesn't work.
Nor do clients have caches of PGP signatures, nor is there some totally obvious third-party that you can verify it with. You can't just go:
curl|{check_if_signed_with_www.this-site.com}|sh (which would pass visual inspection - the attacker would have to change www.this-site.com to something else) because there is no obvious mechanism to do that. Who will tell you whether https://install.meteor.com/ has signed it?
If you're going to entertain the idea of the HTTPS site being compromised to serve whatever they want, well, there is precious little you can do about it.
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.
Commit a race condition to glibc,musl,uclibc and fuck up almost every software on the planet.
It's convenient and that does not mean it's a good practice but i doubt using an other method would minimize a risk when the meteor.com would actually get owned.
> i doubt using an other method would minimize a risk when the meteor.com would actually get owned.
GPG signing, keep the private key offline, publish the public key in the blockchain and have a lot of high profile technologists sign it so it can be independently verified.
But at the end it's about people ...your example with PHPUnit can be abused like this
https://thejh.net/misc/website-terminal-copy-paste
How many people do you think will bother to paste the script to a text editor and check for evil parts ?
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.