What's the answer to "Why do we want to use JavaScript for that?" ? Sure, you can make your web app look more like a desktop app. But is that desirable? I certainly don't want people to come to *expect* e.g. drag&drop on webpages.
rado
I do, and I'd bet many others do to. Web apps don't get the credit they deserve because they're thought of too much as web pages and too little as real applications. Why shouldn't a web app be more like Photoshop and let you doc stuff where you like? Why shouldn't web forms be laid out by the developer at run time with drag and drop while in design mode? It's trivial to use JavaScript and the DOM to generate the necessary CSS to store a pages layout, why should CSS be written by hand when it isn't necessary?
I hate the name Ajax, but the techniques have been used for years and still aren't used enough. Seaside isn't for making web pages... other frameworks do that much better, seaside is for web applications, and it does that better than the rest, IMHO, and "full" Ajax support should be built in as soon as possible.
On Wed, 29 Jun 2005, Ramon Leon wrote:
I do, and I'd bet many others do to. Web apps don't get the credit they deserve because they're thought of too much as web pages and too little as real applications. Why shouldn't a web app be more like Photoshop and let you doc stuff where you like? Why shouldn't web forms be laid out by the developer at run time with drag and drop while in design mode? It's trivial to use JavaScript and the DOM to generate the necessary CSS to store a pages layout, why should CSS be written by hand when it isn't necessary?
I hate the name Ajax, but the techniques have been used for years and still aren't used enough. Seaside isn't for making web pages... other frameworks do that much better, seaside is for web applications, and it does that better than the rest, IMHO, and "full" Ajax support should be built in as soon as possible.
Ok, first of all, I don't really have experience with developing "Ajax" (a stupid name indeed) kind of web applications, so don't take it as attack on this technology. Clearly, if/when it is available in Seaside nobody will force me to use it. I'm trying to get informed.
Issue #1 - Trust
I don't trust the browser. I won't ever use javascript to validate forms (not without a second check on the server, which makes the first check pointless), a http post is easy to fake. How many backdoors am I opening by using these new techniques, partially moving application logic from server to client?
Issue #2 - Development time
Debugging javascript in IE is a nightmare. It's somewhat better in mozillas. Generally, debugging outside of smalltalk takes longer than in smalltalk. I'm one of the few people who gets paid for seaside work. As cynical as it sounds, I'm not using smalltalk/seaside to provide my customers the best possible solution, I'm using it to provide my customers some set of features to make the app competitive, *with least possible effort on my side*. Will using these new techniques actually make my life as developer easier?
Looking forward to hear other opinions, rado
On Wed, 2005-06-29 at 21:01 +0200, radoslav hodnicak wrote:
Issue #2 - Development time
... Will using these new techniques actually make my life as developer easier?
No.
But if used correctly it will make the job of your user easier. For me seaside has not made the job of development any quicker/easier I just spend the time I save doing things like AJAX (I hate the name as well).
Seaside frees up my time so that I can create a richer user experience and I personally would love to see Seaside utilize more things like Script.aculo.us and expand LIveUpdate so that I would never have to write another line of JavaScript again not so that I can get things done quicker but so that I can get thing done better.
Looking forward to hear other opinions, rado _______________________________________________ Seaside mailing list Seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/listinfo/seaside
On 6/29/05, radoslav hodnicak rh@4096.sk wrote:
On Wed, 29 Jun 2005, Ramon Leon wrote:
I do, and I'd bet many others do to. Web apps don't get the credit they deserve because they're thought of too much as web pages and too little as real applications. Why shouldn't a web app be more like Photoshop and let you doc stuff where you like? Why shouldn't web forms be laid out by the developer at run time with drag and drop while in design mode? It's trivial to use JavaScript and the DOM to generate the necessary CSS to store a pages layout, why should CSS be written by hand when it isn't necessary?
I hate the name Ajax, but the techniques have been used for years and still aren't used enough. Seaside isn't for making web pages... other frameworks do that much better, seaside is for web applications, and it does that better than the rest, IMHO, and "full" Ajax support should be built in as soon as possible.
Ok, first of all, I don't really have experience with developing "Ajax" (a stupid name indeed) kind of web applications, so don't take it as attack on this technology. Clearly, if/when it is available in Seaside nobody will force me to use it. I'm trying to get informed.
I always feel slightly embarrassed when I use the term Ajax.
Issue #1 - Trust
I don't trust the browser. I won't ever use javascript to validate forms (not without a second check on the server, which makes the first check pointless), a http post is easy to fake. How many backdoors am I opening by using these new techniques, partially moving application logic from server to client?
Rather than coding up a bunch of Javascript and duplicating that logic on the server, which you have to do for validations, you just make a little post to the server that sends back XML, HTML, or even Javascript back to the client to be handled. Part of the idea is that you are removing the need to duplicate logic on the client and on the server to provide your user with a responsive interface. If done right, it is an appropriate separation of concerns. All the app logic resides on the server, and all the UI manipulation logic lives on the client. I think this is a good idea regardless of the technology.
Issue #2 - Development time
Debugging javascript in IE is a nightmare. It's somewhat better in mozillas. Generally, debugging outside of smalltalk takes longer than in smalltalk. I'm one of the few people who gets paid for seaside work. As cynical as it sounds, I'm not using smalltalk/seaside to provide my customers the best possible solution, I'm using it to provide my customers some set of features to make the app competitive, *with least possible effort on my side*. Will using these new techniques actually make my life as developer easier?
Yes and no. Yes, it will be much easier to give your users a much more interactive client if Ajax support is rolled into the web framework. No, you will be doing more work because you will be adding more features to your web app, ;)
As far as debugging, Prototype handles a lot of the cross browser issues and most of the javascript you will be writing will be manipulating the DOM. Developing with IE will still suck, but I think the amount of debugging you do will be a lot less than you have experienced with Javascript in the past.
The key to all of this is the integration with the framework. I can't think of a framework more suited to Ajax integration than Seaside.
BTW, I'm jealous you are getting paid to develop using Seaside.
- Wilkes
I've actually built a prototype of my application that used live updates extensively. No form buttons, every change was persisted immediately as it happened. It has no fancy visual improvements but the basic idea is there - the user doesn't have to execute actions in steps, saving progress manually. I thought it's great, mainly because I got rid of some nasty deep copy/transactions stuff that is required for normal form based app.
So I put it online and demoed it. At first people didn't notice much difference. But after a while I got questions like "I opened this order and started to edit it, but then I noticed it's the wrong one. How do I undo the changes?".
Needless to say, I'm back using copies and doing commits and rollbacks. Save/cancel buttons are back. When I look at the mentioned example site, backpackit.com - yes, it allows me to reorder list items with dragging, but it doesn't allow me to undo the changes. I've learned this feature is essential for the users (at least for the kind of app I'm developing).
As web apps get more interactive, how do we offer users not only dragging rectangles over each other and blinking divs, but also the comfort of making mistakes without penalty? While staying smalltalk developers of course.
rado
seaside@lists.squeakfoundation.org
-
radoslav hodnicak -
Ramon Leon -
Wilkes Joiner -
William E Harford