Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Meteor, a realtime JavaScript framework

meteor.com

Post reply on HN
Print view View original

221–230 of 350 posts

Re: Show HN: Meteor, a realtime JavaScript framework

#221

Post by [deleted] »

ig1 wrote: post #213
kragen wrote: post #114

Earlier quoted context omitted.

It kills its usefulness for proprietary software , unless you're willing to pay the Meteor guys whatever they ask for a license. But I'd like to point out that there's actually a lot of software out there that isn't proprietary, and Meteor looks like a dramatically better way to write it.

Let's assume you have Meteor on your website: Want to use google analytics ? - nope you can't. Want to offer third-party oauth login ? - nope you can't. Want to use like/tweet/+1 buttons ? - nope you can't. GPL essentially means your website can't have anything on the client-side which is not GPL compatible. And from reading the Meteor guys website that's not what they intend, their choice of GPL was to ensure and ch…

[deleted]

Re: Show HN: Meteor, a realtime JavaScript framework

#222

Post by dangoor »

equark wrote: post #34

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 what they really want, I'm not particularly interested at this stage.

Re: Show HN: Meteor, a realtime JavaScript framework

#223

Post by XLcommerce »

micheljansen wrote: post #208

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…

Such a great question. I spent a lot of time working with ExtJS having been lured in by all those great, straight out of the box components which had their own healthy dose of added magic. Fast forward a year or two and suddenly when I need to do anything that is non standard then reality kicks in.

I now need to buy-in to the entire (framework) mindset to progress which slows things down (because it doesn't necessarily match my own way of doing things).

Had the same experience with cakephp. All those freebies which eventually caught up with me.

Ties in well with the whole libraries vs frameworks debate. I'm now in the libraries camp.

I wonder if Meteor packages are decoupled from each other so that I can pick and choose which ones I'd like to use in my project.

Turns out there really is no such thing as a free lunch.

Re: Show HN: Meteor, a realtime JavaScript framework

#224

Post by mattbriggs »

entropy_ wrote: post #220
micheljansen wrote: post #208

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…

Joel Spolsky coined a term for this type of problem. The "leaky abstraction". See here: http://www.joelonsoftware.com/articles/LeakyAbstractions.htm...

It doesn't nessicarily need to be a leaky abstraction, in the case of rails (1) there was just a few miles between the path a beginner took and a pro took, which makes it real hard to stop being a beginner

Re: Show HN: Meteor, a realtime JavaScript framework

#225

Post by some1else »

pooriaazimi wrote: post #178
iamgopal wrote: post #104

Earlier quoted context omitted.

Can you relax server side requirement a little bit ? Lots of people, including me, want to run such app on google app enigne which do not support node.js yet.

It's been built using Node.js. How on earth are they supposed to 'relax' their dependance on it?

I think he was hopeful that the same benefits could be achieved with a different server-side runtime. It's a long-shot, but with good socket-sync and something like the client-side MongoDB adapter, Rails could come pretty close.

We got pretty comfortable with the commodities the Rails environment provides, so it's understandable some people would rather just add another layer (Backbone/Spine) and avoid the paradigm shift.

The advantages of attacking new problems with a new toolkit can sometimes appear less beneficial, because swapping out the current mega-stack for something slimmer inevitably leads to reduction in features (ie.: You end up making another `view` in place of a collection partial. Mailer, gems/middle-wares, etc..)

That said, despite getting pretty comfortable with Rails/Backbone|Spine, I'm in the pragmatic camp, looking forward to tackling a few side-projects with Meteor.

Re: Show HN: Meteor, a realtime JavaScript framework

#226

Post by grannyg00se »

micheljansen wrote: post #208

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.

Re: Show HN: Meteor, a realtime JavaScript framework

#227

Post by DougBTX »

XLcommerce wrote: post #223
micheljansen wrote: post #208

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…

Such a great question. I spent a lot of time working with ExtJS having been lured in by all those great, straight out of the box components which had their own healthy dose of added magic. Fast forward a year or two and suddenly when I need to do anything that is non standard then reality kicks in. I now need to buy-in to the entire (framework) mindset to progress which slows things down (because it doesn't necessari…

> I now need to buy-in to the entire (framework) mindset to progress which slows things down

That's interesting, that idea could be folded into the technical debt metaphor.

So, by taking on a library or framework, I get a head start by just using it, but take on the knowledge-debt of not really knowing how it works. And when you get to the edge of what it can do, you either pay off the knowledge debt by learning how it works, or you throw the whole thing out and use a different library.

Re: Show HN: Meteor, a realtime JavaScript framework

#228

Post by Lambent_Cactus »

csomar wrote: post #218
micheljansen wrote: post #208

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 can't upvote this enough. When I saw the screencast, I said "Good,we are looking for that". But I want to know how this work, and how I can hack the core. At some point of building my app, I'll need finer degree of control.

The code is on GitHub: https://github.com/meteor/meteor

Re: Show HN: Meteor, a realtime JavaScript framework

#229

Post by skore »

equark wrote: post #51
skore wrote: post #41

Earlier quoted context omitted.

[[citation needed]]. From what I remember, the FSF is pretty consistent in saying that deriving from GPL code is derived work. If your linking constitutes a derivation (a common example would be a database handler that you adapt to your application after you've loaded it) then it is a derivation. If you just loosely call it, it is not.

Meteor packages all the JS together and minifies it. That's clearly linking.

No, that's packing and minification.

https://en.wikipedia.org/wiki/GNU_General_Public_License#Com...

Post reply on HN