tag:blogger.com,1999:blog-7919361321436933137.post4642210206385281474..comments2023-10-24T06:57:30.947-07:00Comments on Script Uncle: The Future of Web ApplicationsScript Unclehttp://www.blogger.com/profile/16751089093335901438noreply@blogger.comBlogger18125tag:blogger.com,1999:blog-7919361321436933137.post-63089782499247351582008-02-26T11:11:00.000-08:002008-02-26T11:11:00.000-08:00@stephan: I agree that we must continually strive ...@stephan: I agree that we must continually strive to make better systems, and be inspired by the good things we see, and try to inspire others to use the best tools available.<BR/><BR/>SOFEA can be implemented with a client-side js framework and WS backend services, as long as the client is downloaded separately (application download), and all communication from there on use XML, IIRC.Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-54966608748223572562008-02-26T10:18:00.000-08:002008-02-26T10:18:00.000-08:00I'm not sure if packing Dojo or ExtJs with a WS ba...I'm not sure if packing Dojo or ExtJs with a WS backend is SOFEA. But perhaps using such architectures will enable us to see real SOFEA. Just as struts has helped us to see web frameworks. Or as WebObjects has made me see the future of web development (when all I did was coding CGIs in C and Python back then). But we didn't stop at WebObjects. So we will not stop at SOFEA 1.0<BR/><BR/>Cheers<BR/>-stephanStephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-83321610129060142882008-02-26T07:33:00.000-08:002008-02-26T07:33:00.000-08:00@stephan. That's good to know. Of curse they have ...@stephan. That's good to know. Of curse they have to be pretty smart to be able to create something like Helma in the first place. And the development doesn't seem to have stopped either.<BR/><BR/>Continuations are pretty cool, but what got my attention recently was that they were starting to fiddle with making it really easy to access Java objects from inside the server-side scripts, copying some good things from Phobos.<BR/><BR/>Actually, there are two sort-of proprietary frameworks which are very much SOFEA; One is <A HREF="http://www.wavemaker.com/" REL="nofollow">WaveMaker</A> and another one is <A HREF="http://www.smartclient.com/" REL="nofollow"> SmartClient.</A><BR/><BR/>Both use Java-based (I think Tomcat in both cases) backends, both to power their studio parts, but also as service proxying for the generated clients / pages.<BR/><BR/>Both are GPL'ed but also available as commercial license a la MySQL, and both have SOAP web service consumption in the client (and a host of other stuff).<BR/><BR/>I'm leaning towards WaveMaker, since they're using pretty much standard Dojo for the client.<BR/><BR/>I'd like to generalize what these guys are doing between web-based IDE and server and between finished client and server, and see if there are common pragmatic ground enough to drive the creation of some kind of simple, yet usable standard.<BR/><BR/>Of course, the next step would be to implement such a standard for Jaxer and Helma :)<BR/><BR/>Cheers,<BR/>PSScript Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-71536441794865034952008-02-26T06:57:00.000-08:002008-02-26T06:57:00.000-08:00As I know some of the Helma developers in person, ...As I know some of the Helma developers in person, they are very clever and nice guys, I assume they see the SOFEA light and are open to improvements. The latest Helma has added server side continuations. And I had a discussion some time back with some of them about using the same code on the server and on the client (as I think I wrote in an Linux magazine article about Helma) [*]. I hope to do SOFEA with my own rendering lib with server side pre-filling of components through Rhino. Currently there is no "real" SOFEA framework around which combines client and server.<BR/><BR/>Peace<BR/>-stephan<BR/><BR/>[*] A problem which might occur is that server side JS currently is Rhino 1.7, the client side is some versions - and always will - be behind.Stephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-39543243703688064792008-02-26T06:37:00.000-08:002008-02-26T06:37:00.000-08:00@stephan: Well, I've actually been checking out He...@stephan: Well, I've actually been checking out Helma, from a distance for almost a year. It regularly comes up when I do searches, and I stop to read to docs now and then.<BR/><BR/>I think the reason I don't really like Helma is that they still have the old server-side generation metaphor, even though it is implemented in JavaScript, in pretty much the same way Phobos has. <BR/><BR/>They have macros and skins/templates which access server-side functions, et.c. Which means that they give a lot of functionality to that kind of programming, which I'm trying to move away from.<BR/><BR/>Which again, kind of leads back to my main point in the blog post, which is that I think there's a need for more standards of a practical nature, to help give structure to thin server architecture, or what we shall call it.<BR/><BR/>At the moment everyone is on his/her own, but with just a tiny bit more pragmatic structure I feel that the idea of creating SOFEA/TSA-style apps will be much more comfortable to developers.Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-67458978240839404972008-02-25T13:45:00.000-08:002008-02-25T13:45:00.000-08:00Take a look at Helma, a production ready JS server...Take a look at Helma, a production ready JS server written in Java and used for high traffic sites for years. <BR/><BR/>I'm working on a SOFEA application with JSON, their reliance on XML ist only accidental. They will discover that too ;-)<BR/><BR/>Peace<BR/>-stephanStephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-58052387746847078562008-02-25T13:35:00.000-08:002008-02-25T13:35:00.000-08:00@stephan: Actually, I've only also used NetBeans, ...@stephan: Actually, I've only also used NetBeans, which was very nice, especially when I did some j2ME work a couple of years back. I've heard much good of IDEA but never used it.<BR/><BR/>And, yes, I haven't had much experience with truly large codebases. I think my point is that at least for me, it takes much more lines of code to make something in Java, compared to PHP. Meaning: if I had created the same thing in Java, it _would_ have been a large codebase :) Maybe. <BR/><BR/>And I've never actually used SOAP services either (outside of work). Tuple spaces are cool, and it feels that the world is slowly converging in simplicity in that area as well (CouchDB, Amazons' thingamajig, et.c.).<BR/><BR/>I'm all for the SOFEA guys, but I think they're overshooting the target a bit, since I don't really think the main thing is that it necessarily has to be XML and WSDL consumption on the client. The main thing is putting the client on the client, but I suppose you knew I thought that already :)<BR/><BR/>Unified messaging is, of course a kind of rapidly approaching holy grail. What would be very cool IMO is if Jaxer gets comet, in which case you get one language for both client and server-side, and a groovy/JRuby(/RhinoRails) accessibility to all legacy Java APIs for free.<BR/><BR/>Cheers,<BR/>PSScript Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-3571123546600366032008-02-25T13:14:00.000-08:002008-02-25T13:14:00.000-08:00This comment has been removed by the author.Stephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-84249667219681406112008-02-25T13:12:00.000-08:002008-02-25T13:12:00.000-08:00"And I agree YMMV. Certainly there are edge-cases ..."And I agree YMMV. Certainly there are edge-cases where either (of ours) approaches bogs down, and edge-cases where they shine."<BR/><BR/>Yes we may differ.<BR/><BR/>Beside that I do not use Eclipse because it's the worst IDE I've every encountered. Instable, low usability, confusing. Netbeans and especially IDEA are much better. And as I said, I don't do SOAP, and never did, because it's the wrong way. For client/server communication REST is much better, when I can choose the form of communications I choose tuple spaces (think Linda) or ESBs. They do scale much better from my experience than bloated SOAP services. Not sure if REST does work in the long run though, especially if it can deliver all SOFEA use cases. Or if coupling an in-browser JS message bus with a comet driven server bus is a better idea (think TIBCO architecture). We'll see. The future is exciting.<BR/><BR/>Peace<BR/>-stephanStephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-30774457053011495252008-02-25T13:01:00.000-08:002008-02-25T13:01:00.000-08:00@stephan: Hi again! I've been using Eclipse since ...@stephan: Hi again! I've been using Eclipse since it was called Visual Age :) And otherwise mostly vi.<BR/><BR/>What I'm trying to say is that a lot of the features of Eclipse (et.al.) are damage management due to the lossyness of partly the verbose language being used, but mostly of the extreme lossyness of the framework being used.<BR/><BR/>And I am using IDE's, but not all of the time. When I'm working in a terminal window I can make do with vi. And the reason for that is I don't _need_ refactoring, automatic deployment or runtime monitoring. I'm just editing a textfile, which is the end product. When I've written a line of code, I save, and reload the page. I have the API docs for whatever I'm doing (if need be) on a web page.<BR/><BR/>And when I'm writing JS+PHP services, I really don't have much use for an IDE, since it's just text-files anyway, both on the client and server. Sure, it takes less time when I have a dozen classes or more to jump to the right spot, but really no killer.<BR/><BR/>When I'm writing a service of some kind in Java, working without an IDE is mind-bogglingly complex. here comes the boiler-plate code; You have to create and use a web service client.<BR/><BR/>Java: Either runs ant tasks which are fairly opaque to generate the scaffolding, or use an IDE wizard, et.c, then perhaps you only need to write a page or two with try/catch statements.<BR/><BR/>PHP: <BR/><BR/>$client = new SoapClient(urldecode($wsdl));<BR/>return $client->__soapCall($wsdl_func, $fa);<BR/><BR/>Where $wsdl is an url for the wsdl file, $wsdl_func is the name of the function you're going to call and $fa is an array with arguments.<BR/><BR/>PHP has support for this (normally) compiled in from the beginning, so you just use, and the wsdl file is cached automatically.<BR/><BR/>And this is not an isolated incident, but it is a very nice illustration of why I rarely is in need of an IDE.<BR/><BR/>My codebases are anywhere up to ~8KLoC, mostly smaller - because I write less lines of code for the same functionality.<BR/><BR/>And I agree YMMV. Certainly there are edge-cases where either (of ours) approaches bogs down, and edge-cases where they shine.<BR/><BR/>It's just that , being in a position to compare medium sized projects done in Java+horrible framework which creates the client out of the server at every action, and PHP+JS is like night and day when it comes to time between idea and execution.<BR/><BR/>Now, if you dispense with the horrible framework and use a RESTive approach you're better off, of course.<BR/><BR/>Still, I can do anything much quicker in PHP than in Java, and I have only two years part-time experience in PHP.<BR/><BR/>yes, I know. Maybe I just suck at Java and happen to be a PHP prodigy :) I somehow doubt it.. <BR/><BR/>Strange huh?Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-20828393599318682992008-02-25T12:22:00.000-08:002008-02-25T12:22:00.000-08:00@peter: You're welcome. The boiler code argument i...@peter: You're welcome. The boiler code argument is a myth, well there is no boiler code. The first IDE I have used extensively was Turbo Pascal. So much easier than the command line compiling and debugging before under CP/M. The first productive IDE I've used a lot was Delphi. <BR/><BR/>An IDE does much more than generating code. How about refactoring, dependency matrices, coupling metrics, automatic deployment, runtime monitoring, quality tips and event based debugging? Or the most basic tasks like displaying API documentation, checking the syntax and auto completion? Using an IDE makes me several times more productive than Textmate or VIM for Python, Ruby, Perl or PHP development, at least in my experience in the last 15 years. YMMV. As soon as Ruby/Python gets a run-time sniffing IDE (think Smalltalk) which does API, auto completion and correct refactoring, everyone will switch and praise their productivity with IDEs.<BR/><BR/>Boiler code? The last code I've written was a REST handler in Java.<BR/><BR/>@Path("/uuid") <BR/>public class UuidResource { <BR/> @Named("uuid") <BR/> UUIDService service; <BR/> <BR/> @GET <BR/> @ProduceMime("text/plain") <BR/> public String getUuuid() { <BR/> return service.getValue(); <BR/> } <BR/>}<BR/> <BR/>I cannot see any boiler code there. One could argue about static typing but every line is needed and would be hard to reduce. Could you show me some boilder code?<BR/><BR/>Peace<BR/>-stephanStephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-23755104624659918462008-02-25T09:45:00.000-08:002008-02-25T09:45:00.000-08:00@stephan: Thanks for your insightful comment. I wo...@stephan: Thanks for your insightful comment. I would indeed say that it very stupid not to use an IDE when you are otherwise forced to generate boilerplate code manually, create three different XML config files containing similar, if not the same, information, and creating complex build scripts by hand. <BR/><BR/>That's really stupid.<BR/><BR/>On the other hand, if you're using technologies which are in no need of those contrivances, not using and IDE might not be a killer, and sometimes doesn't matter.<BR/><BR/>However, I really use Aptana Studio quite a lot, mostly for the quick object and function list, but not for much else.<BR/><BR/>When I have to code in some verbose language again (I've been coding in Java since the late 90's, mostly CA or JSP-derived things.), I naturally have to become cybernetically entwined with Eclipse, anything else would be stupid.<BR/><BR/>. But maybe there is something else here that is even more stupid, if you're looking at things from a bit longer perspective (and can compare)?Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-71455533170201472612008-02-25T08:30:00.000-08:002008-02-25T08:30:00.000-08:00Whoever today is not using an IDE is plain stupid....Whoever today is not using an IDE is plain stupid.<BR/><BR/>Peace<BR/>-stephan<BR/><BR/>PS: Yes, I've used Emacs, EDT, Vim, Pico and ED for decades.Stephan.Schmidthttps://www.blogger.com/profile/03845125686370893937noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-89812189801339217992008-02-25T06:50:00.000-08:002008-02-25T06:50:00.000-08:00I agree that young developers need to start with t...I agree that young developers need to start with the basics, I'd prefer the cmd.exe link be replaced with % or some other Linux prompt.<BR/>but as a seasoned developer, I started in 86, I rarely see a QA or Analysts department, it is usually more like, we will forward you the e-mails, maybe you can write us a Project Plan, Design Specification, Detailed Project Schedule and a Implementation Plan. So have an idea when you will have something we can look at, we really need to get this completed quickly.<BR/><BR/>So guess what the junior developer will be doing..... He will need the Word.exe link as well.<BR/><BR/>DonDon Strawsburghttps://www.blogger.com/profile/17559754326581097335noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-35097286265930295512008-02-25T04:41:00.000-08:002008-02-25T04:41:00.000-08:00@alex: Thanks for the info, and check my further c...@alex: Thanks for the info, and check my further comments there as well :)Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-20532043398080168812008-02-25T04:15:00.000-08:002008-02-25T04:15:00.000-08:00Hi Peter, I answered in a blog post:Formal web app...Hi Peter, I answered in a blog post:<BR/><A HREF="http://weblogs.goshaky.com/weblogs/alexkli/entry/formal_web_application_description" REL="nofollow">Formal web application description</A>Unknownhttps://www.blogger.com/profile/06457966301189788337noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-32107462716362552022008-02-25T01:22:00.000-08:002008-02-25T01:22:00.000-08:00@tom: Yes, the power of eclipse is great, but when...@tom: Yes, the power of eclipse is great, but when you're used to taking short walks, it starts to feel silly to take the cars just ten meters down the road to the next house.<BR/><BR/>And that's what it seems to me, but once you're in the car it's hard to judge distances, so people don't want to get out and look around.<BR/><BR/>It's good to hear someone doing good out there. From all of us, thanks!<BR/><BR/>Cheers,<BR/>PSScript Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-22716116391133393702008-02-25T01:18:00.000-08:002008-02-25T01:18:00.000-08:00I agree with you that this new generation of "deve...I agree with you that this new generation of "developers" are really just "IDE-button-pushers" and most likely could not compile a class from the command line, nor find class information from an API document. I mentor/train many junior java programmers. I start them off with an HTML link on their desktop to the Java API index, a copy of Textpad, and a short cut to cmd.exe (with some mods for buffer size, color etc). After about 2 months or so operating in this type of bootcamp environment, I let them grab Eclipse, NetBeans etc and let them go crazy. At least they understand the under-pinnings of the technology they are trying to master. I also believe that every developer fresh out of school should spend about 4 months or so in the Analysts department, then about 4 months in the QA department, then moving permanently into Development. I got my start in QA/Analyst and it really gave me a huge boost to the start of my career as a software technologist.<BR/><BR/>Kind Regards,<BR/>Tom Pridham<BR/>Land O Lakes, FL USAThomas Michael Pridhamhttps://www.blogger.com/profile/09262311150892947998noreply@blogger.com