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

331–340 of 350 posts

Re: Show HN: Meteor, a realtime JavaScript framework

#331

Post by pbreit »

chc wrote: post #44
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.

I think Meteor actually has the opposite problem: Running a web app is not generally considered to be distribution, so as long as you aren't actually giving the source code to anybody else, the requirements of the GPL don't apply to you. (IANAL, but this is my understanding.)

Except that the nature of Meteor is that the source code is always being distributed out to the client. Meteor is quite a bit different from the usual web framework where all the code is run on the server.

Re: Show HN: Meteor, a realtime JavaScript framework

#333

Post by Produce »

janus wrote: post #36
geoffschmidt wrote: post #2

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!

Mind blowing. Feels very desktop-ey for a web application. The included deploy to cloud options are a huge plus!

Things seem to go in cycles in computing (and life in general). We had a solid model for developing single user applications, then we dropped that in favor of multi-user (web) applications. Now it's going full circle and we get the nice rapid development tools again. I wonder what the next cycle will look like.

Re: Show HN: Meteor, a realtime JavaScript framework

#334

Post by maigret »

10098 wrote: post #321
mmobile wrote: post #237

Earlier quoted context omitted.

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…

It's like the industrial revolution. Long ago, things (like furniture) used to be made by craftsmen. They had to choose the materials, they had to get a picture of what the final product should look like. They used to work by hand, using only simple tools. It was hard. To become a skilled craftsman you had to be an apprentice for several years and learn a lot from your master. Then came factories. Factories were supe…

You're only seeing a part of the development task. Yes, the knowledge requirements for doing a task X (let's say a given CRUD app) are declining. But:

- How do you guarantee that all those pieces you just glued together will work with high availability? That they'll feel easy to use and consistent if exposed to the end user, or easy to maintain (future developers) and operate? Quite some work is often needed to have all that.

- User expectations are getting higher. You could get away with a certain quality and usability of software in 2005 that you couldn't today. Had a desktop software in 2000? In 2006 it was a desktop software and a website, now it is a web app, an iphone app, an android app...

- What you are describing is putting together a solution. Might make sense in many end user scenarios, web apps, etc. For things like automotive and other, low level programming is still needed - though abstraction is also slowly making its way in there also.

Re: Show HN: Meteor, a realtime JavaScript framework

#335

Post by geoffschmidt »

moe wrote: post #87
mhansen wrote: post #83

Earlier quoted context omitted.

It would be more helpful for people reading this comment if you gave reasons beyond "It's taboo". I'm sure you have good reasons, I just can't see them here.

Portability, robustness, flexibility and security. There's little reason to spread out a package like meteor all over /usr/local. But many reasons against doing that. To illustrate, a few simple questions: What if I need multiple meteor versions on the same system (different versions for different users/projects)? How do I quickly switch between different meteor versions (often needed in fast-moving projects like thi…

I agree with all of this :) Meteor is self-contained and installing it in /usr/local is totally optional. The reason we install into /usr/local is that it is a way to get the 'meteor' command into the user's path without trying to edit their dotfiles for them, and without setting obscure system preferences that the user would have trouble unsetting. We went to a lot of trouble to make it easy to try Meteor, and we thought that "great, now go edit your dotfiles" would have lost a lot of people.

If you don't want it in /usr/local, you can check it out anywhere you like and just run the 'meteor' in the top directory of the checkout, and it'll work great. This is mentioned in the README/on Github, and it's how we have been developing Meteor. You can have as many copies of Meteor on your system as you like, and they can even coexist with a copy at /usr/local. So for me, I type '~/co/meteor' to run the meteor that I'm developing on, and 'meteor' by itself to run the latest official release.

You can either build the binary dependencies (node, etc) yourself by running an included script, or if you do not, the first time you run meteor it will automatically fetch a prebuilt binary kit for your convenience. All of the binary dependencies are kept in a directory in the checkout and managed by meteor, meaning that each meteor install on your system can have its own version of node.

Finally, to your last point, 'meteor bundle' does exactly that :P In fact, right now on our deploy servers, we have live apps running that were deployed with a variety of historical versions of meteor, all coexisting side by side.

I'm sure we'll have to revisit all of this as the Meteor ecosystem gets bigger and more complicated -- when all of the packages do not fit in a 'packages' directory, and when there are more binary dependencies than node and mongo. But I hope that this helps to persuade you that we're not totally nuts, despite how sleep deprived I was when we recorded that screencast.

If you thought this was a helpful answer, could you repost the question on Stack Overflow (with the 'meteor' tag), and drop me an email (address is in my HN profile?) That way I could repost this answer there in case it might be helpful to other people.

Re: Show HN: Meteor, a realtime JavaScript framework

#336

Post by troels »

Very impressive and an inevitable evolution, I guess. Although I must say that this is exactly what Stallman is warning us about.

Javascript applications are fine as long as they are used as intended by the programmer, but they do not have the interoperability of a html+http application. Fundamentally, this is reducing the browser to a thin client.

Re: Show HN: Meteor, a realtime JavaScript framework

#338

Post by tete »

tete wrote: post #210

Looks interesting, but.. $ curl install.meteor.com | sh Unable to install. Meteor supports RedHat and Debian. Installation failed. However the slow start description in their README works fine. Maybe this should be mentioned in the message above? https://github.com/meteor/meteor/blob/master/README.md Looks like an interesting approach. I always thought SocketStream would be the next big thing, but now I am uncertain.…

Nice, there is a reaction from SocketStream on this topic:

https://news.ycombinator.com/item?id=3833096

Re: Show HN: Meteor, a realtime JavaScript framework

#340

Post by [deleted] »

maratd wrote: post #326
neilk wrote: post #320

Earlier quoted context omitted.

But they aren't accessing the database. They are accessing a data structure on the client, and changes are propagated to the server. There are opportunities to reject that change at the server. 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. I…

All true, but then you're essentially lying to the client. You are saying something happened, when it didn't. I understand the argument that this type of lying is "ok" for the sake of responsiveness, since 99% of the time the data will be accepted. That argument isn't valid in my eyes. When I update the users screen to reflect the data they entered, to me, that's an indication that I accepted the data. If I were to f…

[deleted]
Post reply on HN