3 ms·

I'm not totally sure it will have been the right choice in retrospect but it was effectively this blog post: http://corner.squareup.com/2012/04/building-analyt

by gline 13y ago

I'm not totally sure it will have been the right choice in retrospect but it was effectively this blog post: http://corner.squareup.com/2012/04/building-analytics.html http://corner.squareup.com/2012/04/building-analytics.html that lead me to prototype using ember. I believe Square's analytics platform - not a "full" web app but a pretty substantial one - is still in production deployment based on ember. Of course, they're probably using whatever version of ember was around 18 months ago, and there have been radical changes since... It feels very likely to me that these javascript frameworks represent a substantial component of the future of this kind of development. People smarter than I am seem to feel that angular is 'better technology' than ember, or at least that in looking like extensible html it has more in common with the eventual future than ember does. I'm actually surprised, in this spate of MVC framework posts, that Meteor hasn't gotten more of a mention. In some ways it's younger than the others, and it has some idiosyncrasies (it doesn't actually require that the client and the serve both be written in javascript but you'd never know if from the web site). But the meteor team is incredibly smart and the company is well financed - and they're spending a lot of time and energy on one of the most interesting aspects of the problem, something ember and angular have not worked out: how to synchronize models and data between the client and the server. Meteor has a special protocol for handling this, such that when deployed properly if the data changes in a database the model in the client automatically updates to reflect this. As someone building a complicated analytical engine with computations done in a python / C++ back-end and structure results visualized in javascript, the idea of being able to reuse models in both places is appealing and the idea that I wouldn't have to spend as much time on data synchronization is almost enough to try to make the switch...

laughfactory 13y ago
I too am a little surprised at how little attention Meteor seems to get. I attribute this to the fact that it sells itself as a client + server technology, rather than a potential client-side only tech (being fed by whatever server you want). When you sell yourself as a client+server then you might have a difficult time attracting the attention of all those who have significant investment in a different back-end, be it Node, Rails, or whatever. But yes, I agree, Meteor looks awesome. It's also got a steep learning curve. And much like Ember or even--I would argue, Angular--it's difficult to see the "magic" right off the bat. And given how new Angular and Ember and Meteor are, there is still a dearth of tutorials, videos, and books to help new comers see the value and get started. So I'm definitely keeping my eye on Meteor. That said, correct me if I'm wrong, but doesn't Ember have something similar? If the data changes in the database then won't Ember update the client to reflect this? I'm not exactly clear on the distinction between Meteor's "Live HTML" and Ember's approach.
- rdtsc 13y ago
  I am probably wrong, but it would be interesting if Meteor allowed other back-ends. There would need to be a shim API (like a way to publish and listen for changes, a way to represent records for ex..) but it seems if MongoDB works other NoSQL dbs at least (and SQL too) could work.

by gline 13y ago

laughfactory 13y ago

I too am a little surprised at how little attention Meteor seems to get. I attribute this to the fact that it sells itself as a client + server technology, rather than a potential client-side only tech (being fed by whatever server you want). When you sell yourself as a client+server then you might have a difficult time attracting the attention of all those who have significant investment in a different back-end, be it Node, Rails, or whatever. But yes, I agree, Meteor looks awesome. It's also got a steep learning curve. And much like Ember or even--I would argue, Angular--it's difficult to see the "magic" right off the bat. And given how new Angular and Ember and Meteor are, there is still a dearth of tutorials, videos, and books to help new comers see the value and get started. So I'm definitely keeping my eye on Meteor. That said, correct me if I'm wrong, but doesn't Ember have something similar? If the data changes in the database then won't Ember update the client to reflect this? I'm not exactly clear on the distinction between Meteor's "Live HTML" and Ember's approach.

rdtsc 13y ago
I am probably wrong, but it would be interesting if Meteor allowed other back-ends. There would need to be a shim API (like a way to publish and listen for changes, a way to represent records for ex..) but it seems if MongoDB works other NoSQL dbs at least (and SQL too) could work.