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

Sammy.js, CouchDB, and the new web architecture

quirkey.com

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Sammy.js, CouchDB, and the new web architecture

#21

Post by mechanical_fish »

Periodic wrote: post #16
mcav wrote: post #3

Good, except that you still have to deal with authentication, authorization, and other security aspects of a server-side component. Server-side code won't go away no matter how fat the client gets.

In this case it will just move into the database. You'll have to start writing procedures and rules in the database instead of in your web framework and only expose those instead having only trusted code interact with the DB.

You'll have to start writing procedures and rules in the database instead of in your web framework

This will not fool anyone. You can't fold the business logic into the database and then pretend that you've eliminated the business-logic layer on the server. It's still there. You've just driven it into hiding.

Re: Sammy.js, CouchDB, and the new web architecture

#22

Post by flogic »

moe wrote: post #6

Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over. So, here we have the return of the fat client, episode 20. And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?

Well in this case the client side isn't the interesting part. The interesting part is the compaction of the server part into the database. The one language to rue them all is also interesting to a point but I assume you can do that with a Java app too.

Re: Sammy.js, CouchDB, and the new web architecture

#23

Post by Periodic »

mechanical_fish wrote: post #21
Periodic wrote: post #16

Earlier quoted context omitted.

In this case it will just move into the database. You'll have to start writing procedures and rules in the database instead of in your web framework and only expose those instead having only trusted code interact with the DB.

You'll have to start writing procedures and rules in the database instead of in your web framework This will not fool anyone. You can't fold the business logic into the database and then pretend that you've eliminated the business-logic layer on the server. It's still there. You've just driven it into hiding.

Exactly. I don't think there is an equivalence between server code and client code. There are some things you just can't trust the client to do, so there will always have to be server code to do it. Whether that code is in a web server, a framework, a database, it doesn't matter. Someone has to write it.

However, I could see some of the code, such as the code that actually builds the page the users sees, being pushed into the browser. But then, don't we already have that with XML and XSLT (or whatever?)

Re: Sammy.js, CouchDB, and the new web architecture

#24

Post by jherdman »

richcollins wrote: post #13

When all you have is a hammer ... jQuery is not a good architecture for a full client application. jQuery is meant for flipping some dom attributes here and there. It does a poor job of modeling the UI state. Sinatra is also a poor architecture choice for the client since the client has persistent state. We already have a well designed client architecture. It's called Cocoa and its implemented in the browser as Cappu…

Interesting point. I tend to agree with you. I find myself hesitant about putting my business logic essentially on the front-end. With the current model we can hide some of the "secret sauce" that makes our applications unique on the server end. With something like Cappuccino (or Sammy.js, etc), how do we keep our secret sauce secret?

Re: Sammy.js, CouchDB, and the new web architecture

#25

Post by shabda »

moe wrote: post #9
rcoder wrote: post #7

Earlier quoted context omitted.

The reasons to stick with DHTML/JS as a "thick client" development platform are simple: decent, free development tools, the ability to interpose proxies and application middleware between the client and server transparently, and a very, very large install base for the client runtime. That being said, I share much of your amusement at/disdain for the attitude of "OMG, look at this brand new thing I have made that is c…

I'm not sure about these reasons. decent, free development tools Well, you can have these for any mature platform. Be it QT, Flex or even Java. I'm not sure what's more decent about the HTML toolchain. The often cited FireBug is, to me, merely an emergency bandaid that makes development at least possible but still far from enjoyable. the ability to interpose proxies and application middleware between the client and s…

> and a very, very large install base for the client runtime.

You are underetimating this. For evrything else, (air, java, Qt, C#) I have to start a new app. My firefox is always on.

Re: Sammy.js, CouchDB, and the new web architecture

#26

Post by ahpeeyem »

moe wrote: post #6

Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over. So, here we have the return of the fat client, episode 20. And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?

Because the HTML/JS platform is only getting nicer. Almost everyone is already dumping fat clients for web clients, even in the enterprise, and it started way before AJAX was even heard of.

The advantages of a fat-client client/server app are low latency of the UI, maybe development speed given the right toolset, plus definitely flexibility of the UI for graphics and complicated interactions. Disadvantages though are difficulty of deployment, client platform restrictions, distributing updates/patches.

Whereas the traditional web thin client is easy deployment to your users across different platforms, via your single installation on the server. The disadvantage of traditional web clients is that you're restricted in UI complexity and latency is high. But this hasn't stopped so many enterprise and web apps being written (and rewritten) for the web, just to get deployment/update simplicity in place of a fat client.

So if you can build a complex UI fat client with low latency and the deployment ease of a web app, you're having your cake and eating it too. I think it really could be different, this time.

Re: Sammy.js, CouchDB, and the new web architecture

#27

Post by awt »

flogic wrote: post #22
moe wrote: post #6

Yes, history keeps repeating. It's hilarious to watch these kids reinvent, well, everything, over and over. So, here we have the return of the fat client, episode 20. And as with all the other episodes the standard question remains: If you're going fat-client then why on earth stick to a platform as horrible as HTML/JS?

Well in this case the client side isn't the interesting part. The interesting part is the compaction of the server part into the database. The one language to rue them all is also interesting to a point but I assume you can do that with a Java app too.

I can see productivity gains in that more can be done without messing with a server side web framework, so there could be less maintenance.

Re: Sammy.js, CouchDB, and the new web architecture

#28

Post by shykes »

jherdman wrote: post #24
richcollins wrote: post #13

When all you have is a hammer ... jQuery is not a good architecture for a full client application. jQuery is meant for flipping some dom attributes here and there. It does a poor job of modeling the UI state. Sinatra is also a poor architecture choice for the client since the client has persistent state. We already have a well designed client architecture. It's called Cocoa and its implemented in the browser as Cappu…

Interesting point. I tend to agree with you. I find myself hesitant about putting my business logic essentially on the front-end. With the current model we can hide some of the "secret sauce" that makes our applications unique on the server end. With something like Cappuccino (or Sammy.js, etc), how do we keep our secret sauce secret?

   > I find myself hesitant about putting
   > my business logic essentially on the front-end
Leave the business logic on the server where it belongs - but hide it behind a REST API, and leave the rendering to the browser.

I think that's the core argument, if you omit the "CouchDB as an app server" part (which is orthogonal).

Re: Sammy.js, CouchDB, and the new web architecture

#30

Post by voidfiles »

richcollins wrote: post #13

When all you have is a hammer ... jQuery is not a good architecture for a full client application. jQuery is meant for flipping some dom attributes here and there. It does a poor job of modeling the UI state. Sinatra is also a poor architecture choice for the client since the client has persistent state. We already have a well designed client architecture. It's called Cocoa and its implemented in the browser as Cappu…

I find the grafting of cocoa onto javascript a bit stomach turning. Its like watching a man read the news to you on TV. Different mediums require different methods. I don't think anyone has really gotten this right yet. I agree jQuery isn't the whole solution, I don't think Sammy.js is the whole thing either. But I do think there will be something built on top of this stack. I have started to try and create something like this http://github.com/voidfiles/BHive .
Post reply on HN