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

Please review my weekend project. 100% client side webapp. Scales infinitely

tvdinnr.com

Post reply on HN
Print view View original

31–40 of 48 posts

Re: Please review my weekend project. 100% client side webapp. Scales infinitely

#32

Post by Animus7 »

arturadib wrote: post #15
Animus7 wrote: post #11

The title is misleading. It's not 100% client-side if it queries facebook's servers. And it will only scale as well as S3 and facebook allow. That's a far cry from infinite.

Isn't that splitting hairs, Sir? The developer didn't code anything on the backend. I think it's pretty clear what he means. Also, any reasonable human being understands that there's only a finite number of hard drives in the world. S3 is 'infinite' for all practical purposes, IMHO.

I don't think it's splitting hairs at all. When you have a centralized point of failure (e.g. datacenter) backend that runs the show, you're not 100% client-side. You're probably not even 10% client-side.

And as Amazon has shown us, you're not infinitely scalable either when a routing misconfiguration wipes your service off the face of the internet.

That said, I wouldn't be so passionate about the topic if I weren't working on a true serverless client-side app framework :).

Re: Please review my weekend project. 100% client side webapp. Scales infinitely

#33

Post by ljlolel »

noduerme wrote: post #30

At a glance -- and it was a glance 'cause I barely go on YouTube and I refuse to get on FB -- I love it as a conceptual data structure. Firstly, tying two APIs together with a smart client is a freaking great idea, although if this were a for-profit project, you should probably worry about either one locking you out, and how long it would take to notice oddities and rewrite if one or the other changes its API overnig…

I agree completely.

API's today are more powerful and more open than ever. I combined just 2 or 3, but I want to integrate a dozen more, see what can be done with no server effort on my part.

The main obstacle to frontend p2p apps are security. Browsers can't create servers. The closest thing is Adobe's P2P technology (used in ChatRoulette), but that also requires a central server to coordinate peer connection.

I also didn't use Facebook, but just joined for this project. They've improved privacy significantly from years ago. You can turn off access to photos and the wall. You can basically use it as a linkedin or twitter.

Re: Please review my weekend project. 100% client side webapp. Scales infinitely

#35

Post by ljlolel »

Animus7 wrote: post #32
arturadib wrote: post #15

Earlier quoted context omitted.

Isn't that splitting hairs, Sir? The developer didn't code anything on the backend. I think it's pretty clear what he means. Also, any reasonable human being understands that there's only a finite number of hard drives in the world. S3 is 'infinite' for all practical purposes, IMHO.

I don't think it's splitting hairs at all. When you have a centralized point of failure (e.g. datacenter) backend that runs the show, you're not 100% client-side. You're probably not even 10% client-side. And as Amazon has shown us, you're not infinitely scalable either when a routing misconfiguration wipes your service off the face of the internet. That said, I wouldn't be so passionate about the topic if I weren't…

Any website could fail because of router misconfiguration, BGP errors (see Youtube), or DNS issues outside of your control.

The point is that it won't fail because of me. I don't have to optimize SQL queries or launch new instances or rewrite my backend in C. It just works, for 1 user or 1 billion.

Re: Please review my weekend project. 100% client side webapp. Scales infinitely

#36

Post by [deleted] »

ljlolel wrote: post #25
mbesto wrote: post #19

Earlier quoted context omitted.

> We need a full client-side JS app framework, with an URL Router, Templates, Controllers, Models, and plugins. It should be able to wrap json api interfaces easily, and it should handle all the page changes that need to happen when it's all just js changes. http://www.sproutcore.com/ http://cappuccino.org/ http://code.google.com/webtoolkit/ http://developer.yahoo.com/yui/ http://www.sencha.com/ EDIT: Took vaadin.com…

I mentioned cappuccino and sproutcore in other replies here. Sproutcore looks interesting, and there's a great team behind it! I mentioned GWT. As you know, it's Java that compiles to JS. I don't see how YUI is different from jQuery and plugins. I don't see a router or templates in the yui docs. Sencha targets mobile. You asked what's missing. Well, none of them are based around jQuery, arguably the reigning king of…

[deleted]

Re: Please review my weekend project. 100% client side webapp. Scales infinitely

#37

Post by ndbabb »

ljlolel wrote: post #35
Animus7 wrote: post #32

Earlier quoted context omitted.

I don't think it's splitting hairs at all. When you have a centralized point of failure (e.g. datacenter) backend that runs the show, you're not 100% client-side. You're probably not even 10% client-side. And as Amazon has shown us, you're not infinitely scalable either when a routing misconfiguration wipes your service off the face of the internet. That said, I wouldn't be so passionate about the topic if I weren't…

Any website could fail because of router misconfiguration, BGP errors (see Youtube), or DNS issues outside of your control. The point is that it won't fail because of me. I don't have to optimize SQL queries or launch new instances or rewrite my backend in C. It just works, for 1 user or 1 billion.

You still need to serve a static HTML page, even if most of the body content loads from elsewhere. Serving a small static HTML file certainly scales well, but not infinitely.

Re: Please review my weekend project. 100% client side webapp. Scales infinitely

#40

Post by noduerme »

ljlolel wrote: post #33
noduerme wrote: post #30

At a glance -- and it was a glance 'cause I barely go on YouTube and I refuse to get on FB -- I love it as a conceptual data structure. Firstly, tying two APIs together with a smart client is a freaking great idea, although if this were a for-profit project, you should probably worry about either one locking you out, and how long it would take to notice oddities and rewrite if one or the other changes its API overnig…

I agree completely. API's today are more powerful and more open than ever. I combined just 2 or 3, but I want to integrate a dozen more, see what can be done with no server effort on my part. The main obstacle to frontend p2p apps are security. Browsers can't create servers. The closest thing is Adobe's P2P technology (used in ChatRoulette), but that also requires a central server to coordinate peer connection. I als…

Flash would be a good basis for the kind of thing I'm thinking of. Adobe's already solved a lot of the sandbox issues that would arise, and the language runs faster than JS. In theory, you get each flash player to open 4 or 5 netconnections to other players, get a running pool propagating and distribute the connection list so no one central server is taking the strain of hooking up the peers, you can have filesharing or even distributed processing in the browser. Processing is more interesting to me because it hasn't really been cracked yet. The security overhead to date has been too high. But that, or a java program, or even something written in Unity, could do some amazing stuff with virtually no back-end overhead.

Keep the good work going. I'm interested to see how this will evolve.

Post reply on HN