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

121–130 of 350 posts

Re: Show HN: Meteor, a realtime JavaScript framework

#121

Post by tlrobinson »

zinkem wrote: post #118
luigi wrote: post #28

This feels to me a lot like how Rails felt back in 2005. A fundamental leap forward and an understanding of where web technology is going. I haven't felt that way about Node.js or even its higher-level frameworks like Express or Batman. This feels like "The One", even though I've been absorbing the docs and screencasts only for the last 20 minutes.

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.

Re: Show HN: Meteor, a realtime JavaScript framework

#122

Post by ollerac »

AdleyEskridge wrote: post #92
luigi wrote: post #28

This feels to me a lot like how Rails felt back in 2005. A fundamental leap forward and an understanding of where web technology is going. I haven't felt that way about Node.js or even its higher-level frameworks like Express or Batman. This feels like "The One", even though I've been absorbing the docs and screencasts only for the last 20 minutes.

I somewhat disagree. I want to preface my post by saying I'm smiling ear to ear—I loved the screencast, and I look forward to using this tomorrow on a project I've been thinking about for a while. Here's my concern: If I use Meteor as it is intended, and I also want a my application to have API, I'll have to re-implement all of my logic server-side[1]. This seems like a step back, unless I'm misreading things. I'd lo…

I'm not sure about Meteor, but you may want to look into SocketStream. Last time I checked they were very interested in making web APIs easier to develop.

Re: Show HN: Meteor, a realtime JavaScript framework

#124

Post by wavephorm »

Their docs server isn't up, but I'm wondering about all the low-level stuff that I have to deal with every day. Where do I put my files, how can I compress them, does it generate ETAGs correctly, how do I create cookies, and sessions....?

Having a way to inject changes into the client solves only a slice of what you do while creating a modern app. Will this framework be just that slice?

Re: Show HN: Meteor, a realtime JavaScript framework

#125

Post by davej »

amirhhz wrote: post #117
sleight42 wrote: post #95

I had two knee jerk reactions. The first has been discussed already (client side DB access). The second has not. Does Meteor have any opinions on testing? I didn't see anything from a quick glance at the docs. I love the idea of tighter development cycles. But as a Meteor app grow in size and complexity, won't it still need a test suite to prevent regressions? Eager to hear thoughts on this from the Meteor devs.

That puzzled me, too, I started browsing the code and noticed there's not a lot of testing of the project code itself: https://github.com/meteor/meteor/tree/master/tests So I agree, it would be good to hear from the devs about their opinions and thoughts on testing. (Is there a chance that they think the "realtime-by-default" approach lessens the need for testing?) I'm no testing zealot, but I've found writing tests…

http://www.meteor.com/faq/meteor-is-a-early-preview

Re: Show HN: Meteor, a realtime JavaScript framework

#126

Post by haberman »

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…

Couldn't agree more. It's like using a library that insist on putting everything in global variables.

Re: Show HN: Meteor, a realtime JavaScript framework

#128

Post by debergalis »

amirhhz wrote: post #117
sleight42 wrote: post #95

I had two knee jerk reactions. The first has been discussed already (client side DB access). The second has not. Does Meteor have any opinions on testing? I didn't see anything from a quick glance at the docs. I love the idea of tighter development cycles. But as a Meteor app grow in size and complexity, won't it still need a test suite to prevent regressions? Eager to hear thoughts on this from the Meteor devs.

That puzzled me, too, I started browsing the code and noticed there's not a lot of testing of the project code itself: https://github.com/meteor/meteor/tree/master/tests So I agree, it would be good to hear from the devs about their opinions and thoughts on testing. (Is there a chance that they think the "realtime-by-default" approach lessens the need for testing?) I'm no testing zealot, but I've found writing tests…

We've actually written a lot of testing for the core framework packages -- those tests are in each package directory. Look for *_test.js files.

https://github.com/meteor/meteor/tree/master/packages/

You're 100% right though. We don't have a fully baked story yet for application level testing. It's something we're trying to push forward as soon as we can.

Post reply on HN