tag:blogger.com,1999:blog-7919361321436933137.post8172279761177464746..comments2023-10-24T06:57:30.947-07:00Comments on Script Uncle: The End of Web Server Frameworks - part IIScript Unclehttp://www.blogger.com/profile/16751089093335901438noreply@blogger.comBlogger21125tag:blogger.com,1999:blog-7919361321436933137.post-7252139167345536662014-02-15T12:41:10.982-08:002014-02-15T12:41:10.982-08:00 Data Visualization Software
SQIAR (htt... Data Visualization Software <br />SQIAR (http://www.sqiar.com/solutions/technology/tableau) is a leading Business intelligence Company.Using Tableau,SQIAR rapidly transform your sea of uncorrelated data into meaningful interactive and actionable visual insights.SQIAR Provide Services in United kingdom and USA.Anonymoushttps://www.blogger.com/profile/10260286164733637453noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-8698973757440772742011-12-22T09:54:15.564-08:002011-12-22T09:54:15.564-08:00Hi @Peter, yes you're correct. Or you were unt...Hi @Peter, yes you're correct. Or you were until recently. Google have finally begun indexing the logic of webapps; http://www.seroundtable.com/google-ajax-indexing-14241.html<br /><br />I see this as a rapidly expanding area, as more and more sites leave the 1995-era of click-and-wait.Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-42066251348290484782011-12-22T08:00:46.866-08:002011-12-22T08:00:46.866-08:00There is one problem with client-side generated HT...There is one problem with client-side generated HTML. It cannot be indexed by Google. And for public facing sites this is very important.<br /><br />Regards,<br />PeterPetar Dochevhttps://www.blogger.com/profile/12878691100856841782noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-24116843398328148412008-02-16T02:33:00.000-08:002008-02-16T02:33:00.000-08:00@valente: o_O Wow! I really like your reasoning....@valente: o_O Wow! I really like your reasoning. Especially this;<BR/><BR/>"The second problem (logic-to-presentation interface) actually mimics<BR/> the logic-to-data interface and it also has something to do with a later<BR/> issue (templating or view/controller). As in the logic-to-data interface<BR/> problem, where the logic level (ex: Perl or Python) currently embeds a<BR/> lot of data stuff (ie. SQL), the logic-to-presentation interface also<BR/> suffers from a lot of confusion, especially when you have templating systems<BR/> that allow you to mix code and presentation. PHP is a particularly bad<BR/> example of this problem.<BR/><BR/> This could be solved by explicitly denying the logic level to output<BR/> any kind of presentation code. Presentation level stuff (ie. templates<BR/> or view/controller) would be in charge of doing any presentation stuff,<BR/> getting all the data/logic from the applicatin server (through REST calls,<BR/> with data in JSON, XML, SOAP, whatever), with the application server being<BR/> explicitly prohibited from outputing any kind of HTML markup code (it just<BR/> wouldnt be taken into account or rendered)."<BR/><BR/>Taken from the <A HREF="http://mv.asterisco.pt/cat.cgi?A%20Future%20Web%20Development%20Framework%20-%20Application%20Logic" REL="nofollow">application logic</A> article. I must stress though that the muddling of logic and presentation is just as bad in RoR, JSP, ASP as in PHP.<BR/><BR/>And also, it is quite easily solvable as long as you don't have any presentation in your scripts at all.<BR/><BR/>For my smaller stuff, I just have a simple "$cmd = _POST['cmd'];". And then I switch on that command to call further resources. <BR/><BR/>Also, when it comes to templating, Dojo has a very strong templating system that works inside the client itself, so that even inside the browser there is a separation of presentation and logic.Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-77064839150373252812008-02-16T01:29:00.000-08:002008-02-16T01:29:00.000-08:00@gernot: I've some moderate experience with RoR, a...@gernot: I've some moderate experience with RoR, and I my opinion is that what makes it so easy to work with are only two things; 1) Ruby as a language, 2) The opinionated defaults in both framework and directory structure.<BR/><BR/>Apart from that RoR still has the same problematic \<\%=foo\%\> approach that mixes in the client metaphor on the server that both ASP and JSP (And PHP, yes) has as well.<BR/><BR/>RESTive RoR, on the other hand, is my game, since you then do not put the view on the server.<BR/><BR/>Also, the answer to the question of why to use the browser for something it was not designed for, is like the answer to why one would try to build a tree-house on a sapling.<BR/><BR/>The answer is that the sapling was not designed to support a tree-house, it would break immediately. However, since 2003, that sapling has grown into a fairly large tree, so if you look again at the browser which was not designed for 'something', you'll see that now it is. ^-^<BR/><BR/>You could check out the links in the blog post to TIBCO, WaveMaker and Dojo, for instance.Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-20538074100604914162008-02-16T01:16:00.000-08:002008-02-16T01:16:00.000-08:00I've been in the business of fat clients with lot...I've been in the business of fat clients with lot of client state; actually I wrote quite a few large business applications using Java/Swing and .net/WinForms.<BR/><BR/>Ruby On Rails opened my eyes and showed me another way to design applications. Using a clean MVC architecture with some moderate AJAX usage results in applications that are easy to understand, easy to use and expose themselves as a bunch of resources. Users can work with urls, save application state as links, mail them around, you get the picture.<BR/><BR/>If I really needed a rich UI I would go for flex, but a fat Javascript Client will get you nothing but trouble. Why would you want to use the browser for something it was never designed for?Gernothttps://www.blogger.com/profile/08836163611074377149noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-61605761252420123672008-02-16T01:11:00.000-08:002008-02-16T01:11:00.000-08:00@valente: I'll go check it out.@carl: Could you pl...@valente: I'll go check it out.<BR/><BR/>@carl: Could you please post another comment with the links to you articles, to simplify for future readers? Thanks!<BR/><BR/>Also, I think that it would be interesting to see if we could come up with some kind of minimal specifications on what a thin server should look like, a bit in the same way as REST, but centered on services, sessions, security, et.c.<BR/><BR/>The <A RHREF="http://www.theserverside.com/news/thread.tss?thread_id=47213" HREF="" REL="nofollow">SOFEA guys</A> have a fairly strict model, which gives a lot more proofs and examples, but which I feel is a little bit too strict and almost misses the point;Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-82574175879782520322008-02-15T15:11:00.000-08:002008-02-15T15:11:00.000-08:00@peter: totally agree with your posts. See my seri...@peter: totally agree with your posts. See my series of posts about a future web development framework at http://mv.asterisco.pt<BR/><BR/>-- MVMário Valentehttps://www.blogger.com/profile/07503054029744676257noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-46361815361917625502008-02-15T14:43:00.000-08:002008-02-15T14:43:00.000-08:00Sorry to double-comment, but I'm surprised the fun...Sorry to double-comment, but I'm surprised the functional programming nazis aren't drooling over this. I mean, it basically is a FP-centric webserver (No side effects! No state!)constance eustacehttps://www.blogger.com/profile/10766996152700797287noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-8435720243640627652008-02-15T14:40:00.000-08:002008-02-15T14:40:00.000-08:00I've been pimping this strategy for about a year o...I've been pimping this strategy for about a year on ServerSide.com, using my trademarked style of poor explanation.<BR/><BR/>I wrote the basics using a java servlet for cross-page sessions (anyone got a better mechanism?), and combinations of DWR, jquery, ext-js, trimpath, trimquery, and other toolkits for in-browser JS processing.<BR/><BR/>If you architect a web services layer well enough, and do the state tracking on the client, you have a stateless, completely scalable, low-overhead web tier.<BR/><BR/>The best part is that timeouts basically disappear. If state is on the client, then stale sessions don't pollute the expensive server memory.<BR/><BR/>The worst part is the code security. You need to be disciplined in service invocation. client credentials should probably be encrypted on the client and passed to the server on every request.constance eustacehttps://www.blogger.com/profile/10766996152700797287noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-19664984654989967062008-02-15T12:40:00.000-08:002008-02-15T12:40:00.000-08:00@jay: I agree that GWT solve the problem - sort of...@jay: I agree that GWT solve the problem - sort of. It is the exact opposite of TSA, and I would think (I am not experienced enough in it to be a reliable source) that it leads to small problems getting big for no reason, a times.<BR/><BR/>Also, you must have a server, ad PHP is great as a thin server, as long as you only handle incoming RESTive requests (POST, GET or what have you) from the JS client and return raw data.<BR/><BR/>This goes for all server-side frameworks. PHP happens to have a weak spot in my heart since when I managed to solve a four-class three day dynamic WSDL parsing conundrum I had tried to do in Java in just five lines PHP (it's built-in, no jar file versioning. it it just. there.).<BR/><BR/>I'm a big fan of quick development. :)Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-16881514266462377662008-02-15T12:04:00.000-08:002008-02-15T12:04:00.000-08:00I think you're spot on. I've used PHP, JSP, ASP, J...I think you're spot on. I've used PHP, JSP, ASP, JSF, XMLC, and a host of other server-side technologies. They all seem to be rather cumbersome to me.<BR/><BR/>That's not to say I love JavaScript programming. JavaScript is difficult to program on the client side due to browser compatibility issues. Experience among developers is also sparse when it comes to working in quirks mode. This is my only problem with the thin server concept.<BR/><BR/>However, this is the precise problem that GWT is designed to solve. You get to keep you server thin (only serving data), but you don't have to code in anything but Java. This allows you to reuse your client code, when necessary, on the server. It also makes it easier to hire developers since you're only looking for Java.<BR/><BR/>Good article!Unknownhttps://www.blogger.com/profile/14738549894786165288noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-14983411202657536962008-02-15T11:14:00.000-08:002008-02-15T11:14:00.000-08:00Ah, excellent, I enjoy using Google's apps, but I ...Ah, excellent, I enjoy using Google's apps, but I never knew they worked quite this way. Also, thanks for mentioning Tamarin, I recall hearing about it some time ago and forgot what it was called. I'll have to look into it now.Anonymoushttps://www.blogger.com/profile/15325624840584388150noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-23135777497581901772008-02-15T07:14:00.000-08:002008-02-15T07:14:00.000-08:00@michael: Well, I agree of course that browser-ba...@michael: Well, I agree of course that browser-based applications are slower than their compiled counterparts. <BR/><BR/>I'm not really arguing that they are, my argument is rather that - when building web-based applications it takes less resources and gives quick<B>er</B> user interaction - compared to applications which originate all content from the server.<BR/><BR/>But while on the subject of speed, the as/js engine Tamarin, which was donated to the Mozilla foundation from Adobe, is currently <A HREF="http://ajaxian.com/archives/adobe-tamarin-tracing-jit-for-javascript" REL="nofollow">doing JIT compilation</A> for JavaScript, and will be part of future version of Firefox, possibly also other browsers.Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-44098220727955557262008-02-15T06:59:00.000-08:002008-02-15T06:59:00.000-08:00Peter,The speed is sufficient, but not what it sho...Peter,<BR/>The speed is sufficient, but not what it should or could be. Gmail is fast enough, after all I use it. But there is still that java like UI delay when clicking around. I am not talking about latency. I still don't care for java apps for this same reason.<BR/><BR/>I have also used one of the javascript IDE's, I think is was for Rails, and there is no way I could use it as my everyday editor. Just too slow. <BR/><BR/>I do use Google Docs, which is acceptable in speed though.<BR/><BR/>My point is not to argue but to only point out that something additional is needed to propel js to the next level of adoption. For people to actually realize it can be used to program a client application. Perhaps compiled libraries and a standard windowing API would help in that regard.Michaelhttps://www.blogger.com/profile/09108721777783507215noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-2626751632287021302008-02-15T06:46:00.000-08:002008-02-15T06:46:00.000-08:00@cius: Well, the first thing I would recommend is ...@cius: Well, the first thing I would recommend is to read <A HREF="http://mans.thejonassons.com/wordpress/2008/02/11/efficient-dual-caching-of-dynamic-web-content/" REL="nofollow">my friend Måns' blog</A>, where he describes what happened to his web app (a web-based forum with some special features) after moving some of the caching from the server to the JavaScript client.<BR/><BR/>Then there's some customer examples at TIBCO's site, most notably <A HREF="http://www.informationweek.com/news/showArticle.jhtml?articleID=200900875&subSection=News" REL="nofollow">Bear Stearns</A>.<BR/><BR/>Also, Gmail, Google Calendar, and documents, et.c. all work in this manner. You load the app, which is in JavaScript, and then the rest of the communication with the Google servers are data only.Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-25584044112995811982008-02-15T06:37:00.000-08:002008-02-15T06:37:00.000-08:00@michael: Actually, Dion Almaer wrote about this i...@michael: Actually, <A HREF="http://almaer.com/blog/the-connection-between-hope-and-web-innovation" REL="nofollow">Dion Almaer</A> wrote about this ina recent Gears blog, that Google Gears could be used as a automatically updated repo for common js libraries.<BR/><BR/>And when it comes to execution speed, it really is sufficient already. TIBCO GI has a browser-based IDE for creating web-based apps that lives in the browser and consumes WSDL services in the browser. In JavaScript. Also, most View and styling actions are not in need of that much speed either. What is needed is to get away from the latency that bogs things down by freezing everything while involving the server.Script Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-10300247978934560372008-02-15T06:22:00.000-08:002008-02-15T06:22:00.000-08:00Okay, after reading your first post I'm interested...Okay, after reading your first post I'm interested in how well this will work. I'll check out the study you link to, but do you have any example applications using this technique? I'd really like to see the effect it has on the user experience (if any).Anonymoushttps://www.blogger.com/profile/15325624840584388150noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-63286778138361089542008-02-15T06:19:00.000-08:002008-02-15T06:19:00.000-08:00I think you are on to something. I think the bigg...I think you are on to something. I think the biggest hurdle to js frameworks on the client is speed. Javascript still seems to run slow in most browsers, perhaps Opera being a slight exception.<BR/><BR/>If there was a JIT compiler or some other way to speed up code execution, I think most people would come to the same conclusion you have.<BR/><BR/>Another idea that would speed up adoption is to have standard js libraries pre-compiled with firefox. Windows has an api to create a form, etc. Why not have an API to create a form in javascript. If the library was not installed, it could download automatically (but lose the precompiled benefits).<BR/><BR/>While windows bored everyone with similar looking forms for every application, it did help to speed development on the platform.<BR/><BR/>This would truly move firefox/IE/Safari to a development platform that could actually challenge windows.Michaelhttps://www.blogger.com/profile/09108721777783507215noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-65630599255054176592008-02-15T06:16:00.000-08:002008-02-15T06:16:00.000-08:00Your right! Thanks!Cheers,PSYour right! Thanks!<BR/><BR/>Cheers,<BR/>PSScript Unclehttps://www.blogger.com/profile/16751089093335901438noreply@blogger.comtag:blogger.com,1999:blog-7919361321436933137.post-78812303851565773512008-02-15T06:13:00.000-08:002008-02-15T06:13:00.000-08:00This is just a friendly suggestion. For the sake ...This is just a friendly suggestion. For the sake of context, you should put a link to part 1 at the beginning of your article. Anyone with half a brain can find it without problem, but it might help those with just 2/5 of one. :)Anonymoushttps://www.blogger.com/profile/15325624840584388150noreply@blogger.com