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

321–330 of 350 posts

Re: Show HN: Meteor, a realtime JavaScript framework

#321

Post by 10098 »

mmobile wrote: post #237
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…

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 super-effective, they produced a lot of things fast, and cheap too, and the level of skill required from a factory worker was in no way comparable to the skill of a proper craftsman.

I notice the same tendency in software development today - we, the software developers, are more similar to factory workers mindlessly sticking together parts than "ninjas" or "rockstars". Of course, the process of software development today is not entirely like a factory, but I sense it's moving towards there. And if it is, programmers will become something cheap and fungible. Imagine hiring illegal immigrants to write an iPhone app :)

Re: Show HN: Meteor, a realtime JavaScript framework

#322

Post by jmarinez »

infinite8s wrote: post #300
jmarinez wrote: post #246

Earlier quoted context omitted.

Fibers take care of the "callback pyramid of doom" and makes it easier to write thick logic layers. However, it still would have the fairness and starvation issues that Node has with callbacks. It's still single-threaded and non-preemptive like "stock" node. I wonder how dependent Meteor is on Node? In other words, why Node? Is it for Node module compatibility? If it isn't, I'd love to see Meteor running on something…

Lua's coroutines have the same issues that you mention for node's callback (single threaded and non-preemptive)

Coroutines and fibers in general, regardless of the language avoid the "pyramid callback" that can - depending on the developer - in spaghetti code.

Lua on its own right, is a bit special. Fast, small, easy syntax - almost similar to Javascript when you think about it. However, "Coroutines in Lua are not operating system threads or processes. Coroutines are blocks of Lua code which are created within Lua, and have their own flow of control like threads. Only one coroutine ever runs at a time, and it runs until it activates another coroutine, or yields (returns to the coroutine that invoked it). Coroutines are a way to express multiple cooperating threads of control in a convenient and natural way, but do not execute in parallel, and thus gain no performance benefit from multiple CPU's. However, since coroutines switch much faster than operating system threads and do not typically require complex and sometimes expensive locking mechanisms, using coroutines is typically faster than the equivalent program using full OS threads."

Re: Show HN: Meteor, a realtime JavaScript framework

#323

Post by wonnage »

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.

Interested to see how they'll handle file uploads, authentication, etc. Especially authentication, seeing as clients have full access to the database right now.

Re: Show HN: Meteor, a realtime JavaScript framework

#324

Post by ronreiter »

erikpukinskis wrote: post #287

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…

There's a really good reason why an API should be written (like REST API for example) between the client and the server, and that the client should not be exposed to the internal workings of the database for many reasons.

The API should be carefully programmed and kept abstract from the database, which might be one day changed completely. To keep the user interface agnostic, it should not be aware of how the database works.

Also, this is a recipe for mistakes, since giving the client direct access to the database (even if it is secured) raises questions about the data integrity and data protection. It is much more prone to abuse that way.

I'd love to see a CAPTCHA signup implementation with meteor.

Re: Show HN: Meteor, a realtime JavaScript framework

#325

Post by zmmmmm »

AdleyEskridge wrote: post #168
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!

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.

Ugh, I didn't even consider that a (partly) client side framework would have been GPL. Unless they come out with a very clear, simple and friendly commercial license it pretty much kills meteor for all practical purposes.

(To be clear, it's not that I begrudge the author's their right to license it how they want. I simply think frameworks like this are too central and important to have any uncertainty about licensing associated with them.)

Re: Show HN: Meteor, a realtime JavaScript framework

#326

Post by maratd »

neilk wrote: post #320
TazeTSchnitzel wrote: post #309

Earlier quoted context omitted.

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.

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 first show the data as accepted, and then show an error message if something went wrong, I am undermining the trust the user is placing in my software.

It's almost like the software is confused and inconsistent? Kind of like a person who says one thing and then says something entirely different within a few seconds?

With every software suite, there is an implicit promise that it won't try to mislead me. I don't use software that lies to me, I don't expect others will use it either.

Re: Show HN: Meteor, a realtime JavaScript framework

#327

Post by maratd »

neilk wrote: post #320
TazeTSchnitzel wrote: post #309

Earlier quoted context omitted.

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.

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 first show the data as accepted, and then show an error message if something went wrong, I am undermining the trust the user is placing in my software.

It's almost like the software is confused and inconsistent? Kind of like a person who says one thing and then says something entirely different within a few seconds?

With every software suite, there is an implicit promise that it won't try to mislead me. I don't use software that lies to me, I don't expect others will use it either.

Re: Show HN: Meteor, a realtime JavaScript framework

#328

Post by maratd »

neilk wrote: post #320
TazeTSchnitzel wrote: post #309

Earlier quoted context omitted.

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.

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 first show the data as accepted, and then show an error message if something went wrong, I am undermining the trust the user is placing in my software.

It's almost like the software is confused and inconsistent? Kind of like a person who says one thing and then says something entirely different within a few seconds?

With every software suite, there is an implicit promise that it won't try to mislead me. I don't use software that lies to me, I don't expect others will use it either.

Re: Show HN: Meteor, a realtime JavaScript framework

#330

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.
Post reply on HN