311–320 of 350 posts
I would love to use this framework if it was implemented as Google's NaCL, running 'native' code instead of Javascript.
Earlier quoted context omitted.
"this is nothing short of revolutionary." Oh FFS, this is not revolutionary. It is an attempt to wrap things in a friendlier package, while at the same time making something horribly insecure as a default install. Ruby on Rails did that a long time ago. Better examples of revolutionary: Manned Flight: http://en.wikipedia.org/wiki/Wright_Flyer http://en.wikipedia.org/wiki/Apollo_11 In computers: http://en.wikipedia.or…
I get your point, but just because you can name examples of other technological advances that are more revolutionary, does not mean that this (in its own small world) cannot be described using that term. Revolutionary (according to the Oxford English Dictionary) simply means "involving or causing a complete or dramatic change". A technology that dissolves the boundaries between client-side and server side development…
Edit: Looking a bit more, I noticed that ObjectFabric doesn't yet support JavaScript directly, only through GWT.
Earlier quoted context omitted.
It depends what the Meteor team has in mind. If they want this to be the next Django/Rails/Express/whatever, where a large and enthusiastic community both uses and develops the product then the answer is fairly clear: No, this is not a suitable license. If their idea is that it's an nominally open source project where all control and most development takes place inside the originating company, and the community mostl…
In the twenty-five or so years of the free-software movement, we've built the Internet and the World-Wide Web; made the Encyclopedia Britannica obsolete by producing something dramatically better; built history's most portable operating system, which now runs everything from most smartphones to most supercomputers, with contributions from hundreds of companies, including its biggest competitors, IBM and Microsoft. Bu…
But open source frameworks and languages that try and give developers the maximum freedom to make whatever they want see much higher adoption, uptake, mindshare, marketshare, engagement, developer excitement, community participation, user-submitted bug fixes, etc., etc., etc. than ones which don't.
Start listing popular frameworks - how many of those frameworks are GPL?
Off the top of my head, I would name: Sinatra, Rails, Django, Flask, Backbone, Batman, Knockout, Tir, CakePHP, Symfony, Spine, CherryPy, web.py, Pyramid, Zend, and Brubeck. Of those, every single one except Brubeck is licensed with BSD, MIT, or some variant - and Brubeckmight be too; I couldn't find license info.
There's nothing terrible about making web app that are free software...but the plain truth is, people don't make web apps that are free software with frameworks that require that. They go pick one of the popular frameworks, which all have permissive licenses. You can be horrified if you want. :)
Earlier quoted context omitted.
It depends what the Meteor team has in mind. If they want this to be the next Django/Rails/Express/whatever, where a large and enthusiastic community both uses and develops the product then the answer is fairly clear: No, this is not a suitable license. If their idea is that it's an nominally open source project where all control and most development takes place inside the originating company, and the community mostl…
In the twenty-five or so years of the free-software movement, we've built the Internet and the World-Wide Web; made the Encyclopedia Britannica obsolete by producing something dramatically better; built history's most portable operating system, which now runs everything from most smartphones to most supercomputers, with contributions from hundreds of companies, including its biggest competitors, IBM and Microsoft. Bu…
My first impression of this: wow. If Meteor is all it appears to be, this is nothing short of revolutionary. My second reaction: what happens when the magic ends? When I was new to Rails, I really loved how easy it was to get started with scaffolding, a nice DSL for specifying relations, nifty form helpers. However, the first time I veered a little off the golden path and wanted to do something a little more complica…
Like the reference to Rails—so easy and at the same time so inaccessible. In the earlier days without powerful frameworks I was really developing: figuring out which pattern/algorithm did the best job. Nowadays when working with frameworks I feel dumber and dumber—before thinking myself I just google API calls and put them together. I am not trying anymore because I don't know where to start and everything is already…
I love gluing things together that do the nitty-gritty stuff for me because it lets me focus on the big picture of making things happen, which is what I love about programming.
It definitely has a potential to bring huge changes. I love how packages are bundled. Other things as well. I will try it out with coffeescript.
Congratulations guys, this is pretty awesome.
Earlier quoted context omitted.
This is built with Node.js. From the docs: "A Meteor application is a mix of JavaScript that runs inside a client web browser, JavaScript that runs on the Meteor server inside a Node.js container..."
I think he's saying this could be the Rails of Node.js. Node.js is very low level and is more analogous to Ruby than Rails.
My first impression of this: wow. If Meteor is all it appears to be, this is nothing short of revolutionary. My second reaction: what happens when the magic ends? When I was new to Rails, I really loved how easy it was to get started with scaffolding, a nice DSL for specifying relations, nifty form helpers. However, the first time I veered a little off the golden path and wanted to do something a little more complica…
Like the reference to Rails—so easy and at the same time so inaccessible. In the earlier days without powerful frameworks I was really developing: figuring out which pattern/algorithm did the best job. Nowadays when working with frameworks I feel dumber and dumber—before thinking myself I just google API calls and put them together. I am not trying anymore because I don't know where to start and everything is already…
I'm surprised no one is talking about the glaring hole, which is security. It's apparently on the developers' short list of high priority features ( http://stackoverflow.com/questions/10100813/data-validation-... ) but it doesn't seem like a trivial addition. With client-side DB access, and eventual consistency baked into the platform as a core feature, you can't just throw "if current_user == object.owner" in your c…
I was shocked when I saw the client-side DB access in the video. It seems like absolute insanity to me. Even when I knew very little about web development, the principle of not accessing the database on the client side seemed obvious and very important.
This trick is already in use in a lot of places. If you click an upvote on Reddit, it doesn't do a complete round-trip, it just increments the count in place, and then issues a command to the server to do a "real" increment. If, in the meantime, someone disabled your account, then there is a disagreement. But it's obvious that the client's idea loses.
Eventual consistency is in mainstream use on the server, with frameworks like Cassandra et al. This is just a generalization of that to the web client.