I feel like Meteor has been floating along for along time without significant traction beyond toy-projects. I remember seeing (I think?) Meteor at Djangocon and being impressed, but feeling like using it was an all or nothing decision given the pace of how quickly front end development was -- and still is -- changing.
A year or two later I looked at it for a small project but saw it was still exclusively tied to mongoDB.
Are there any major sites or businesses using meteor?
I think the problem with Meteor was mainly that it started punching above its weight too soon. All these fancy demos and then you looked under the covers and it was... basically irresponsible from a security standpoint to ship anything that mattered on Meteor. I know that's been fixed now, but so many people like myself never gave it a second chance. And I wonder if it will ever really get that second chance or if something like it is what will get attention instead.
It's a cautionary tale about why you need to be very clear that your demo alpha isn't fit for general consumption yet. I think that, in the rush to get attention, the Meteor people didn't do a very good job of that. Therefore everyone who took a deep look thought they had uncovered a foul truth that Meteor wasn't what it was hyped to be. And they did. Because the people promoting it didn't talk about that.
How old is the release you're talking about? I started using Meteor about 18 months ago, and I don't have a clue about what you're referring to. Security has been a complete non-issue for every release I've ever seen.
---
> I know that's been fixed now, but so many people like myself never gave it a second chance.
But what's stopping you from looking now? Meteor security is great, and you should give it another look. One interesting bit: there are only 16 srp implementations listed on the srp page on wikipedia, and Meteor is one of them! http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
I know it might be bad form to link to a video of something I built, but I don't think that the work I've been doing for the last 18 months amounts to a toy project: https://www.youtube.com/watch?v=8v5nSxchwRA
It seems like all the recent client-side frameworks are really desperate to jump on the React bandwagon somehow.
I suppose this could be seen as validation that the new approach it takes to rendering and organizing UI is a good one, if competing frameworks are trying to mimic or integrate with it.
I'm looking at React now, as our first experience of Angular had a really steep learning curve, and it's going to be a hard sell to our UI team who have been writing Wicket for a long time - we're moving away from Wicket in some areas as it doesn't handle complex dynamic UI very well. It's got the AJAX support if you don't mind a trip back to the server for every state change, but when it goes wrong, the debugging gets really hairy.
React's component orientations look at little easier to pick up and get going with, and it'll be a lot more familiar feeling to our UI team who have been passing data down a tree of components for some time now.
However, I have yet to build anything substantial in it, but so far I'm hopeful (I shall disregard Flux for now, we may not require its complexity just yet). The data binding all looks to be one way, and each component looks testable in its own right.
So hopefully I'm not just jumping on yet another bandwagon.
Have you considered EmberJS as an alternative? React may be the best thing since sliced bread, but as Rich Harris, author of Ractive, writes [1]:
> Ractive uses similar techniques to Glimmer - it parses the template into a structure such that it's very easy to identify which DOM nodes need to be updated when data changes. This is different to how React (for example) handles DOM updates, which involves re-rendering everything and then running a diff.
> The two approaches both have the same goal - minimising DOM updates - but go about it in very different ways. Each has advantages and disadvantages, and I believe we're going to develop a much clearer understanding of what they are in 2015.
If your comment is in response to the linked article:
1. Meteor isn't a client-side framework, it's a full-stack platform;
2. This post was written by a member of the community, not someone on the core team, so I don't think you can say "desperate to jump on the React bandwagon"
If this isn't what you meant, ignore my post, just wanted to mention those two things :)
Both good points. I didn't realize that this wasn't written by someone not on the core team.
As previous responses have shown, I didn't think through this comment too well. Just trying to articulate a feeling I had about a lot of recent posts regarding React, but it looks like it doesn't really pertain to this article.
Apologies for the off-topic comment, but does anyone know what this page is doing to mess up mouse wheel scrolling so it's painfully slow? I've come across a few sites that do this recently, and it drives me crazy, but I haven't found any obvious JS attached to likely event handlers so far.
Unfortunately I can't remember any other specific examples, but I've noticed the effect a few times on blog-style sites over the past few weeks, and it's sufficiently infuriating that you really wouldn't miss it.
I've been assuming it's someone's "clever" JS snippet doing the rounds, perhaps trying to normalise behaviour on some mobile browser or something along those lines. However, looking for obvious things like an onscroll or onmousewheel event handler attached to any element in the DOM turns up nothing, so whatever technique they're using to do it is new to me and I don't know how to turn it off. :-(
I'm running release channel Firefox on Windows 7 if anyone's curious. A range of other pages I have open in different tabs right now are all scrolling at my normal (much faster) speed.
I don't think we have any scroll event handlers on our blog (not 100% sure as I didn't implement the theme). It's a WP site, perhaps that's the common element -- although I don't think WP ships any JS itself...
My best guess would perhaps it's animated gifs triggering a bug in the browser for some reason?
My best guess would perhaps it's animated gifs triggering a bug in the browser for some reason?
That's plausible. Firefox has been buggy as an insect colony in recent releases, and other browsers didn't seem to have any problem with it.
In case it's useful to know: the page was also very slow to zoom at first in Firefox but then when I tried again a minute or two later it seemed to be back to normal. Again, this was a very obvious difference.
So I instantly saw the value in Meteor when I first heard about it, but I'm not really getting what's so great about React. I guess I haven't done enough front-end work to realize the need for something like it to manage large applications. If anyone could further explain why it would be worthwhile to start using React, I'd love to understand.
25 comments
[ 3.8 ms ] story [ 58.9 ms ] threadA year or two later I looked at it for a small project but saw it was still exclusively tied to mongoDB.
Are there any major sites or businesses using meteor?
It's a cautionary tale about why you need to be very clear that your demo alpha isn't fit for general consumption yet. I think that, in the rush to get attention, the Meteor people didn't do a very good job of that. Therefore everyone who took a deep look thought they had uncovered a foul truth that Meteor wasn't what it was hyped to be. And they did. Because the people promoting it didn't talk about that.
---
> I know that's been fixed now, but so many people like myself never gave it a second chance.
But what's stopping you from looking now? Meteor security is great, and you should give it another look. One interesting bit: there are only 16 srp implementations listed on the srp page on wikipedia, and Meteor is one of them! http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
Nor is Respondly: https://www.youtube.com/watch?v=zTkV3MW9mKA
I suppose this could be seen as validation that the new approach it takes to rendering and organizing UI is a good one, if competing frameworks are trying to mimic or integrate with it.
React's component orientations look at little easier to pick up and get going with, and it'll be a lot more familiar feeling to our UI team who have been passing data down a tree of components for some time now.
However, I have yet to build anything substantial in it, but so far I'm hopeful (I shall disregard Flux for now, we may not require its complexity just yet). The data binding all looks to be one way, and each component looks testable in its own right.
So hopefully I'm not just jumping on yet another bandwagon.
> Ractive uses similar techniques to Glimmer - it parses the template into a structure such that it's very easy to identify which DOM nodes need to be updated when data changes. This is different to how React (for example) handles DOM updates, which involves re-rendering everything and then running a diff.
> The two approaches both have the same goal - minimising DOM updates - but go about it in very different ways. Each has advantages and disadvantages, and I believe we're going to develop a much clearer understanding of what they are in 2015.
1. https://github.com/rich-harris/ractive-dbmonster
I haven't, but I'll have a look now. Cheers. :)
1. Meteor isn't a client-side framework, it's a full-stack platform;
2. This post was written by a member of the community, not someone on the core team, so I don't think you can say "desperate to jump on the React bandwagon"
If this isn't what you meant, ignore my post, just wanted to mention those two things :)
As previous responses have shown, I didn't think through this comment too well. Just trying to articulate a feeling I had about a lot of recent posts regarding React, but it looks like it doesn't really pertain to this article.
I've been assuming it's someone's "clever" JS snippet doing the rounds, perhaps trying to normalise behaviour on some mobile browser or something along those lines. However, looking for obvious things like an onscroll or onmousewheel event handler attached to any element in the DOM turns up nothing, so whatever technique they're using to do it is new to me and I don't know how to turn it off. :-(
I'm running release channel Firefox on Windows 7 if anyone's curious. A range of other pages I have open in different tabs right now are all scrolling at my normal (much faster) speed.
I don't think we have any scroll event handlers on our blog (not 100% sure as I didn't implement the theme). It's a WP site, perhaps that's the common element -- although I don't think WP ships any JS itself...
My best guess would perhaps it's animated gifs triggering a bug in the browser for some reason?
---
EDIT: animated gifs more likely.
That's plausible. Firefox has been buggy as an insect colony in recent releases, and other browsers didn't seem to have any problem with it.
In case it's useful to know: the page was also very slow to zoom at first in Firefox but then when I tried again a minute or two later it seemed to be back to normal. Again, this was a very obvious difference.
I hope it helps you as much as it did me.