231–240 of 350 posts
something I've been wondering: how can Meteor help prevent race conditions? For example, if there is a lengthy piece of text (say a blog post) being edited by > 1 person. Can Meteor simply lock a resource and prevent edits on client-side or is this something that needs further tweaking by the developer? Or will it somehow have Google Docs style collaborative editing?
Regards, daryl
I've been using node.js for a while and I think I've tried all of the different frameworks, none of them seemed quite right.. I eventually settled on using express and building on top of it with modules and my own code.
When I installed the leaderboard example I expected a big directory with a million files.. my jaw dropped when I saw the whole app was 3 files! And app.js was tiny!
This looks like the node framework we've all been waiting for.
I really can't wait until this is more polished so I can actually use it for live apps. Great job guys, bravo!
Is GPL really viable for a web framework? The Free Software Foundation has consistently held that linking to GPL code (not LGPL) is derived work.
This is a major point... If I use it in my project and after a while I want to charge for the service and I don't distribute all my code, am I in trouble? if yes, I forecast a slow and steady walk into the event horizon for this nice little thing.
Is GPL really viable for a web framework? The Free Software Foundation has consistently held that linking to GPL code (not LGPL) is derived work.
In their FAQ, they mention wanting to keep the changes people make open for now, which is why they chose the GPL. If that's the case and they're not pursuing a dual license business strategy, I'd suggest that the Mozilla Public License 2.0 is a better choice. It's very explicit that the files that come in the distribution are the ones for which derivative works need to be under the same license. If dual license is wh…
"The MPL has been approved as both a free software license (albeit one with a weak copyleft) by the Free Software Foundation and an open-source software license by the Open Source Initiative. The MPL allows covered source code to be mixed with other files under a different, even proprietary license. However, code files licensed under the MPL must remain under the MPL and freely available in source form. This makes the MPL a compromise between the MIT or BSD licenses, which permit all derived works to be relicensed as proprietary, and the GPL, which requires the whole of a derived work, even new components, to remain under the GPL. By allowing proprietary modules in derived projects while requiring core files to remain open source, the MPL is designed to motivate both businesses and the open-source community to help develop core software." - http://en.wikipedia.org/wiki/Mozilla_Public_License
Hey everyone! The four of us have been working very hard on this for the last six months, and we're excited to finally take the wraps off. Can't wait to hear what you think! We've got a lot more stuff coming over the next few months, and if there are particular things you'd like us to do/prioritize, I'd love to hear about them!
This looks fantastic. I genuinely got giddy watching the screencast! If I were to use Meteor for a partially closed source app earning around $1000 per month, how much could I expect to pay you? From the FAQ: > If the GPL doesn't work for your project, get in touch (contact@meteor.com) and we will write you a commercial license to your specifications.
This is no way to answer such an important question that most potential users will have - let's face it, there's a lot of people who will want to use this for open source, but a lot more who will want to use this for commercial apps. To ensure Meteor's wide-spread acceptance, you need to clearly answer this question on FAQ page, and not with "we need to have a conversation".
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…
I'd like to see some additional detail on this particular idea: "In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. " Seems one of Node's primary style advantages (async non-blocking style) has been eschewed.
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…
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 solved on Github. This magic feels sometimes so meta and boring because I am more into consuming specs, tutorials, screencasts just gluing things together instead of real programming.
Just diving into JS and Node.JS to get this "go-kart" feeling back. But I guess the more magic involved the faster the development and Meteor admittedly looks revolutionary.
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…
I'd like to see some additional detail on this particular idea: "In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. " Seems one of Node's primary style advantages (async non-blocking style) has been eschewed.
This is a very uncool way to install something: $ curl install.meteor.com | /bin/sh
Why is it uncool?
As someone else pointed out, it also makes versioning difficult.