Software Development optimize

It is time for better Web frameworks


There is currently a huge disconnect between the needs of Web applications and the frameworks that support them. Admittedly, we have come a long, long way from the days of CGI, but we still have a long way to go. I am not quite ready to say that we need a new language aimed at Web development.

I think that the problems are not any more language specific than any other programming difficulty. But I do think that the current frameworks inadequately address the needs of a developer writing an actual application that has all of the same power and functionality as a client/server application, a mainframe application, or even a basic, disconnected desktop application. For the sake of discussion, I am going to stick with mainstream frameworks -- J2EE, ASP.NET, and PHP. (I would love to include Ruby on Rails in this discussion, and maybe some of the readers can help with that, but my knowledge of it is just not high enough to write about it competently, and it definitely is not "mainstream" yet.)

Thread safety within the framework's shared objects

Point number one is the automatic parallelization of Web code. Whether most Web developers realize it or not, their code always runs the risk of simultaneous execution, even at the individual user level. In other words, imagine if you were writing a desktop application, and every button click, drag/drop action, and so on immediately executed the event handler in a separate thread. It would certainly change how you handle issues like data concurrency, the private variable access within classes, and so on, wouldn't it? This is exactly what you are facing while writing a Web based application. I am not necessarily saying that Web servers or Web frameworks should serialize all requests (although it would be nice if that was a configurable option, particularly at the user session level). Current Web frameworks pretend to handle this differently, but they rarely do in optimal or configurable ways. For example, the Microsoft ASP.NET documentation has this small blurb on the issue of session states and concurrency:

Access to ASP.NET session state is exclusive per session, which means that if two different users make concurrent requests, access to each separate session is granted concurrently. However, if two concurrent requests are made for the same session (that is, using the same SessionID value), then the first request received gains exclusive access to the session information and the second request will execute once the first request completes, or until the exclusive lock on the information is freed due to the first request exceeding the lock timeout. If the EnableSessionState page directive is set to ReadOnly, then a request for the read-only session information does not result in an exclusive lock on the session data. Read-only requests for session data may still have to wait for a lock gained by a read-write request for session data to clear.

In other words, the session data locks, but it is essentially an exclusive lock at the call level. The session object in ASP.NET does not support a mode or methods to grant locks for an entire page or section of code. It is up to the developer to do something like wrapping any code that calls the Session object in a critical section to keep that data safe.

PHP takes an entirely different tack. While the documentation does not formally mention the data concurrency challenge (another stellar example of what I mean when I say, "PHP's documentation is lousy"), a friendly visitor was nice enough to post some revealing information about the issue (see the comments in that documentation). If this user is correct, the use of sessions will lock on a call to the session object, which automatically forces the serial processing of pages; this is not exactly optimal, but at least it is guaranteed safe. The developer is forced to jump through some hoops to do anything else, according to that post.

And finally, the J2EE documentation for the HttpSession object does not mention the topic at all. Way to go, Sun! On a side note, it is interesting that Microsoft, who is traditionally slammed on documentation, discusses the issue better than anyone else does.

The page model

In general, the idea of "pages" in a Web application makes sense, particularly for historic reasons. Sadly, the page model is also rather broken for the purposes of writing an "application." Users do not call "pages" when using an application -- they click buttons, drag items, and so forth. In other words, they are performing data manipulation. AJAX was born out of the need to think about an "application" as an event-driven model in which each user action triggers a discrete piece of code. While I think AJAX is a bad idea as it stands (because of JavaScript issues, exception handling, debugging difficulties, too many HTTP requests, and so on), at least it has the right idea. Without using AJAX, it is nearly impossible to have a Web "application" that acts anywhere near an "application" while still using HTML. Let's face it, folks, HTML is designed expressly for read-only operations, with only marginal support for data manipulation.

This is where the difficulty with the page model lies. Technologies like ASP.NET's Web Parts and J2EE's Faces is a great start. Let the "page" act as a container for these small chunks of functionality. It certainly comes much closer to the component writing and reuse that revolutionized desktop development ages ago. While the current frameworks are addressing this issue, there is still too much of the page model that needs to go, right down to the way the IDEs like Eclipse and Visual Studio conceptualize an "application." They are still geared for the page model that has proven itself to be poor for "applications." PHP, with its root so closely intertwined with CGI, lacks these kinds of tools. Instead, a PHP developer who wishes to do something similar fills their code with a lot of includes and such, which creates a complete mess as far as code is concerned.

Client/server interactions

The current "state of the art" is to throw data and a bit of client-side code over the HTTP server's fence and see what comes back. While this is technically accurate and has the force of historical precedence behind it, it is counterintuitive to an application developer. It is very difficult to seamlessly debug the client-side code and its interaction with server-side code, for example. I have not used Eclipse enough to judge or touched Visual Studio "Orcas," but I know that I have yet to see a tool that lets me set a breakpoint in JavaScript, step through the code, and land at the beginning of the request for data from the server. The current frameworks simply have not yet institutionalized the client-side code or started to consider it an equal partner. In a desktop application, it is very easy to discover, for example, what user action triggered the event that is being handled. In a Web application, it is impossible. If a search engine follows a form's destination or if a user follows it, there is no difference. This can cause problems for the user and security risks. I can think of no application in which a user can arbitrarily trigger methods and functions that the visible windows have access to (without some quality developer-type tools and a build that includes debugging symbols, of course), yet this is the exact nature of a Web application. Without much care in the coding, a malicious user can fuzz the application much more easily than they can with a desktop application. This is a direct result of the way current Web development frameworks approach the client/server interaction.

Conclusion

This is really not about desktop apps vs. Web apps, but it also is in a way. Users and product managers are expecting more and more from Web applications. After all, most of us have the idea that Web applications are going to replace all of our client/server and mainframe applications (personally, I don't buy it). The problem is, the applications that Web apps try to replace have had seamless development models for quite some time now. The functionality capabilities of Web apps are still well below 1990 (if not 1985) levels in the desktop world. If Web apps are going to replace desktop apps, developers need the tools to build them just as good. And I really do not think that any of the current, mainstream frameworks come close.

J.Ja

About

Justin James is the Lead Architect for Conigent.

48 comments
anirbank2000
anirbank2000

Not sure why the author is so much against web applications. Has he considered that for rich client applications, each user has to get the client component installed on his system. What if field users want to use the app on their palmtops. Web applications are much more convenient way of reaching out to a whole lot of users with a central server.

stuart.fraser
stuart.fraser

I don't believe Justin has anything against web apps it is just the development environment which has some real issues. Delivering an app via the web is a great idea and has many benefits as you rightly say. However when you are delivering an app to a client that integrates with a database containing personal, financial or otherwise confidential information then you absolutely need to know that it is robust, secure and that transactions are handled correctly. Look at the debacle with the recent NHS junior doctor website where a lot or personal information became available to all users of the system. Nobody is saying don't do web apps, that would be a backward step. However, web development currently needs to be done very, very carefully to avoid these kinds of situation. There doesn't appear to be either the framework or the tools that make this job easy and a casual approach to web app development can lead to, at best a crappy application which dissapoints users, but at worst a serious impact on a business's reputation and financial performance. Stuart.

a0041050
a0041050

Regarding "..set a breakpoint in JavaScript, step through the code, and land at the beginning of the request for data from the server.." I use the script debugger coming with WinWord in my classic ASP development. I can do exactly what the author seems to be missing. I can even debug COM+ code (written in VB6) used by my server side code. Just set a breakpoint in the VB6 IDE and the debugger will stop there. Kind regards Sascha K (a0041050@addcom.de)

Justin James
Justin James

... for anything more recent than VB6? J.Ja

phfeenikz
phfeenikz

Having a good framework is nice for developers, but what about the clients? Required plugins, cross-browser incompatibilities, and poor adoption of web standards; these are all issues that need to be addressed before a discussion about a better framework for web development even begins to make sense.

Justin James
Justin James

... is that developers do not use anything requiring a plug-in, including Java. None of the technologies I referenced (ASP.Net, J2EE, PHP) or their associated frameworks require any front-end items, other than JavaScript for some of them, and even then, it is optional. JavaScript is a fairly reasonable requirement. But yes, your point that all of the Web-delivered, HTML alternatives all require plugins, which you can't count on being there and alienate your users! J.Ja

simon
simon

This article indirectly highlights all the reasons I am so excited about Adobe AIR (Adobe Integrated Runtime - formely Apollo) http://labs.adobe.com/technologies/air/

Justin James
Justin James

... it requires plugins and such, which have always been a non-starter 99% of the time. Indeed, Flash is the only plug-in that is common enough to know is installed. Unfortunately, Adobe is not as developer friendly as a lot of other vendors, the server software costs a bundle, the development tools are pricey, and Adobe does not have anything near as useful as the MSDN or many of the other communities around technologies like J2EE and PHP. :( J.Ja

Mad_Scientist17
Mad_Scientist17

Adobe Flex is the killer app! Adobe have an application development environment called Flex which answers ALL of these issues. It's a thoroughly modern object oriented language, with all the gui widgets you've ever wanted (and several you didn't know you wanted till you see them), brilliant development environment and debugging, compiles to an ultra-light flash file, and knows how to talk to backend servers. There's even full offline capability if you need it. It's a paradigm shift.

Justin James
Justin James

You've hit the nail on the head. Things like Silverlight and Flex (also some dead ideas, like Java applets and ActiveX) all were designed with the sole purpose of using HTML and HTTP as bootstraps to get a *better* system on the screen. Is Flex (and the like) "Web development"? No. But that is OK. I would not mind seeing something like Flex replace "Web development", not at all. J.Ja

dogknees
dogknees

Absolutely! This is something that annoys me enormously. We need a web framework that provides ALL the standard interface look and feel that Windows or OS X provide. Drag and drop (both within and between applications), resizable windows, MDI, proper menus and toolbars with user customisation, keyboard shortcuts, clipboard integration, standard dialogs for file and print functions... Most of the responses so far don't seem to see the fundamental problem you've identified. Applications aren't made up of pages and fixed workflows. They are built out of windows, menus, toolbars, controls, dialog boxes,... This should be the case online the same as it is offline. Finally, the tools we use to build applications need to be as mature as modern IDEs. You should never need to see HTML in the same way you don't code against the graphics cards API in Windows. All that should be wrapped up in the object model and API of the platform. Sadly, what seems to be happening is that rather than build these tools and platforms to bring web-apps into the mainstream, MS and others are trying to turn existing apps into web-apps with all their limitations. In other words rather than fix the net, they're breaking the desktop. Regards

Justin James
Justin James

I was afraid that maybe my point was not coming across too clear initially. You "get" what I meant spot on... if Web apps want to replace desktop apps, they need to have the same functional capabilities, and the amount of work and troubleshooting that goes into emulating even something as standard as an MDI interface is insane. Until the frameworks and tools deliver the ability to write the same functionality with the same ease and reliability, Web apps are headaches. J.Ja

bluemoonsailor
bluemoonsailor

Hmm... Let's file this one under "Duh." Things are getting better. RoR et al. are prodding MS and Java providers out of their comfy boxes and actually helping move the overall technology base forward, but there's a long long way to go.

Justin James
Justin James

I agree that there has been a lot of improvement, much much of it is improvements along what I consider to be bad paths to begin with. I may also note, particularly with .Net, much of the improvement has been to the languages and framework, but not too ASP itself, other than some new objects within a mostly mediocre system. J.Ja

bluemoonsailor
bluemoonsailor

Really, I'm hoping that some of the changes and new ideas that are coming out of some of the more radical technology ideas (like RoR) help promote architectural innovations by MS and the Java camps. You're right that adding spiffy controls just isn't the same thing as addressing fundamental problems.

Mark Miller
Mark Miller

As you implied, programmer skill has something to do with this. If you're totally dependent on the tool, it will lead you down the path of creating a page-based application. I agree that for anything beyond a simple app. the page-based model absolutely sucks. I realized that on one of my first web projects where I was dealing with a page that had 5 different sections on it, each with their own submit button. I was doing this 2 years ago in ASP.Net 1.1. The code was a horror, I finally realized. When I was brought back to the same project several months later, and I was asked to create some more functional pages that were laid out and configured similarly, I got smarter. I created my own data access/business objects that were accessed by the event handlers. I data-bound my data access objects to my controls using a technique I read about: I defined a getter property on my objects for each field, and for tables (in the UI) I put these objects into arrays, and data bound to them. What a difference it made! It still wasn't ideal, but it was a lot better than the hellacious tool-driven code I thought I had to deal with before to get this same task done. The key was I stopped depending on the tool (VS.Net) so much. I still used the IDE for code organization and builds, plus the code editor and debugger. I still created the pages in a single page layout, but I componentized the business logic, so I wasn't using what had essentially become global variables on the page. But I stopped using the other tool features that would only steer me towards coding oblivion. I don't know what to tell you about parallelization. To the best of my knowledge I never ran into a situation where two requests would use the same session ID. Actually, how DOES that happen? Web Parts, JSF are better solutions. What's nice in VS 2005 is you can create your web components and then see them laid out in the design view. You could create the same things in VS.Net 2002/2003 (they were called "User Controls"), but the designer would not render them. You had to run the app. to see what the aggregated page would look like. RoR allows you to use a page-based model if you want, but it also has a feature called "partials" that's essentially the same thing as Web Parts, JSF, etc. You can create a template for a piece of a page, with a corresponding class for it (like a code-behind), and you can aggregate them into pages that the user will see.

Justin James
Justin James

Mark - I have had the same experience with Visual Studio. Every time I start using its drag/drop tools, I always hit some brick wall eventually, and end up hand coding a lot of it. It is like, the only way I can win is to write my own stuff, *then* use Visual Studio to work with it. Le sigh. J.Ja

Mark Miller
Mark Miller

When I was first learning web development I really liked VS.Net's approach. Everything was integrated so I didn't have to figure out how it all worked while I was trying to master HTML, Javascript, and learning the round-trip model. My "initiation by fire" came fairly quick though, as I've already discussed. Two difficulties I ran into were creating my own ORM (it was more laborious than mentally challenging), and then filtering the object collections. VS.Net offered no support for either of these strategies when I was working on this 2 years ago. I tried to find a collection that would help me do the filtering. No matter what I tried I couldn't get any collection to help me with that. I ended up writing my own routines. As I was creating my ORM, I began to realize "Oh, this is what people are talking about with using code generation, and using CodeSmith." It was to get around VS.Net's limitations, but if you wanted a ready-made solution you pretty much had to use CodeSmith. I don't remember if NHibernate existed then. Last year I saw a CTP demo of the Linq Project, and I was salivating over it! I saw that and said to myself, "That's just what I need!" In fact I knew I could've used it on the project I worked on a year earlier. But it was test code and not good enough for production. Talk about disappointing. It was like being shown a delicious dish that smelled wonderful, but no, you can't eat it. One of the things I learned during the demo is Linq accomplishes what it does by using some "dynamic language magic" under the covers. Anytime the guy did an inline query it got translated into Lambda expressions. The presenter revealed how they worked. Also, it used "duck typing", because the type of the object you'd get back from a query was unknown until the query was executed. The efficiency in code that was gained by this was incredible. I wanted it SO bad! But I couldn't have it, not then. What I discovered once I got into studying Lisp and Smalltalk is that it was either easier to do some of this stuff in them than it was in C# at the time (like code generation), or it was already there (filtering object collections). I studied up on RoR for a bit. I liked what the Rails framework could apparently do, and I liked the Ruby language. It had the ability to generate code. That's how Rails does its stuff. I later found out about Seaside for Smalltalk, and learned about the component model for building web pages. It doesn't use the page-based model at all. The point is I discovered I didn't have to wait to get these capabilities. They're already out there, just in different technologies. Looking over the app. development landscape as it is now, I don't find it that inspirational. We have weak languages that we try to make up for via. powerful tools. That seems to be the way most organizations prefer to go. We're getting into tool-oriented programming. The language is almost incidental, except if you consider XML, which ironically is being used to get around the constraints of the statically typed, early-bound languages we're using--only it's just a different swamp. What the tools don't do we're trying to do via. XML-based code generation. I hate this trend that's being bought into of "we'll do everything in XML". I feel like the road to hell is being paved with this. On the one hand I can understand why people want to use these tools because they mean getting a good job so they can feed their families. There is the question of whether you actually like this stuff, or you use it because you need to, to make a living. Either way it doesn't matter. On the other, I so wish we as an industry would get our heads out of our arses and realize what we're doing is actually holding us back. We're not doing the best we can do, or being "all we can be". We're settling for mediocrity (and by this I don't necessarily mean developers) because it seems it's the best that can be done for reasons I can only guess at. Sorry for the rant, but I think your post touched a nerve (a good one).

Mundo209
Mundo209

I almost *never* use drag-and-drop with Visual Studio. I tend to position my cursor in the code where I want the control to land and double click it in the toolbox. That way I'm in control of the code and layout, and can quickly dive in and add the right attributes, etc. I can't even remember the last time I clicked on the "Design" tab. Mind you, I have never found so-called GUI tools that useful. You *always* have to tweak the code they create, so what's the point in letting them do it in the first place.

Mark Miller
Mark Miller

I had some prejudice against HTML at first. I said to myself, "Give me a break! This is a document format, not a UI language," and to a certain extent that's true. Maybe CSS helps with that. I haven't studied it enough to know. IMO GUI apps. were more straightforward. The event model needed abstraction, but otherwise it was good to go. You didn't have "script bits" in a GUI app. to add capabilities. The very idea would've been looked upon as weird. In VC++ there was something akin to HTML, called resource files. Anytime you formatted a dialog box screen or set up menus in VC++ you were manipulating the resource file, which would be compiled when you built the app., I guess into some sort of byte code. I know it wasn't executable object code, but it would be integrated into the .exe file. Windows has some sort of resource processor module built into it, I think, which makes bringing up these screens seamless. It was a rare occasion if I ever directly manipulated a resource file (which looked like a series of text commands). The reason being that if I needed to customize the appearance I had plenty of capabilities in the API to do that. VB 6 did GUI apps. by hiding most of the details. All you had to do was drag and drop stuff, position it just how you wanted, and then set some properties. You could manipulate them directly with application code. There was no "server side" and "client side". It was all one thing. I've said this before, but really what we've done is recapitulated the old mainframe system. It worked much the same way. If you walked up to a VT3270 terminal and started working with it, it would feel familiar. You fill in a form totally on the terminal (the client), hit some submit button on the keyboard, the form gets sent to the mainframe as "a stack of cards" (ie. a batch), and a response is sent back to you in another form. Along with this are screen formatting commands so that the form is laid out properly on the screen. There was no client-side scripting as far as I could tell. What you have is the basic round-trip cycle. The differences are there are no graphics. It's all text based. And there are no plugins where different media types can be integrated together. If you had asked me a year ago why web app. construction had to be so clunky I would've said it was because we're trying to graft an application model onto a stateless, disconnected medium ("disconnected" in the sense that you connect, send data up, get data back, and disconnect). Today, I say the reason it's clunky is the technology we're working with is not sophisticated enough to make it easier. It's possible to make it more straightforward, but it takes more powerful concepts being integrated into our development systems. I know this would be a stretch for you, but if you were to ever take a look at Seaside, you'd see that the environment it sets up is a lot more like programming a desktop app. You don't drag and drop controls at all, nor are you working with an HTML or template file with its tags, but you can, like you could in a desktop app., directly control the interface through code. The HTML is generated dynamically, and you generate it using mneumonic calls. There's no separation between your UI mneumonic code and its event handlers. It can do this because Seaside is a continuation server (note: the article mentions "Continuity", a continuation server in Perl). State is saved between round trips automatically. When a postback happens it restores state and picks up where it left off. It detects events automatically and calls the event handling code. One way of looking at it is you are always directly manipulating the HTML file, but it's in the same language as the other code you're writing, for business logic, etc (it's all in Smalltalk). It does AJAX as well the same way. You don't have to get your hands dirty in the Javascript if you don't want to. I heard from a friend recently that JSF has similar capabilities as what I describe for Seaside. I haven't checked it out though. According to the article I link to there are a few frameworks for Java that either implement or emulate continuations. One of them has something to do with Spring. Another is called RIFE. JSF isn't mentioned. So maybe my friend is mistaken.

Justin James
Justin James

... the "why" of the project to see if they truly need a Web app in the first place. You would be surprised how many requests for a Web app really can be better met some other way. J.Ja

alaniane
alaniane

This article highlights two reasons why I try to avoid developing web apps. 1) Lack of good debugging tools 2) Lack of good UI tools

Justin James
Justin James

You are absolutely right about this, I use Visual Studio in much the same way. But it brings up the bigger picture problem: Web development frameworks are still so primitive, we still have to handwrite all of the underlying plumbing. I am a big beleiver in hand-written HTML, and so are most of the good Web dev folks I've met. Ever meet a desktop app developer who insisted on writing his own window handling controls? "Sorry Jim, I just think that the drag/drop system leaves too much Win32 API cruft, I prefer to do all of the window layout on my own." Nope, I can't recall it either. Even from VB 3 and Delphi 1, no one has gone back to hand design of windowed apps. So why are the frameworks and tools so shoddy that we need to still be doing it this way on the Web? J.Ja

Wayne M.
Wayne M.

The use of a sessionless model is probably the biggest contributer to poor web application frameworks. Second on the list is a poor web client. Most of the effort in a framework is to make sessionless operation work like session-based operation. Persistant data is handed off between servers. Heartbeats are intorduced to keep applications alive. Enterprise-wide or Application-wide access accounts instead of per user accounts are used. Performance is geared toward a near infinite amount of users as there is no mechanism to limit quantity of simultaneous users. There are an excessive amount of hurdles needed to try and impose a session oriented model on a sessionless design. The second issue is the low level of capabilities provided by the HTTP desktop. The primitives are far too low a level and do not support the most common data types. Almost all data entry relies on a customized text box - dates, numbers, telephone numbers, credit card numbers, addresses, names, etc. These are all commonly used data types, yet every web page must recreate these types of scratch. There is no inherent data validation at either the character nor field level. An appropriate desktop needs both because in a data entry application, the primary error prevention or error detection mechanism is at user entry. We need a stronger set of data entry primitives coupled with persistant customization at the client side. Web based applications are still in their infancy and a new approach is needed to address the sessionless issue and the weak desktop capabilities issue.

Justin James
Justin James

Wayne - You are absolutely right that an overwhlemingly large share of the pain of Web development stems from the stateless, sessionless nature of HTTP, and the fact that HTML and HTTP only "understand" string data. Until we move away from Web development and to a form of programming that shares the advantages (zero install, single server install, central storage, no maintenance for users, etc.) as we discussed last week (I really envision something like X Window), this is the world we sadly need to deal with. I think that the existing frameworks are doing a much better job of abstracting these issues away. For the large part, most Web developers no longer need to think about these things. But the vast majority of Web developers work on what I choose to call "dynamic Web sites", not "Web applications". "Dynamic Web sites" can still afford to think in terms of the page model, require little data *manipulation* or input beyond tyoing in a few text bixes and clicking submit, and so on. And for those developers, what is currently on the market is more than adequete. But for someone like you or me, who are tasked with building true *applications* that use HTML to hopefully acheive the functionality of a true GUI, and have to deal with trying to run this mess over HTTP, we're kicking and screaming for "better, now". J.Ja

Sebastian Zdrojewski
Sebastian Zdrojewski

IMO, as for the main topic of this article, what I do *NOT* like about most developers in my area is that they do not build a framework itself. I think the real difference between the old "CGI" style coding and good programming is exactly this: once you need to build a website (or an application) build it over a framework, not just building "pages". Frameworks have lots of advantages: they can be optimized to raise efficiency of an application, and this can be done by a higher level (call it senior) developer team, while the frontend is delegated to a team, even with lower skills, that also takes care of "cosmetic" aspects of the development (not to be forgiven this last element, since the usability of a website or a web application is really depending on it). I think frameworks should be built based on experience of the development team: there are some publicly available frameworks that are quite good enough, but in a Corporate contest this can change because of security concerns and functional needs. Once they start to be "alive" and usable, the development time needed for an application (or functional) delivery starts to be shorter and shorter, giving the development team a RAD tool that they can use for delivering business needs in (almost) no time, with a good eye on security needs of the business itself. I am not really a lover of IDE development environments, actually I use Eclipse because it has a great color highlighting features and once you get handy with comments you can also build an online reference for class methods and properties (well, here I work hard with PHP) of your own framework. As for PHP (lately, sorry for this long typing) as far as I remember, each variable defined in a connection to a browser is runtimely defined and accessible to that session (beware, I am talking of a connection session, not an application session). One user cannot access other user's variable space unless specified explicitly (as in using shared memory allocation). Sorry again for the long post :)) Cheers :: En3pY

Tony Hopkinson
Tony Hopkinson

We started with pull a file from a server into a client and render it. Since then we've twiddled with server side so the file conmtent could be changed, client side so the rendering could be changed. Arsed about with various methods of adding state, and attempted to break up the 'page' into bits. The framework is not designed for applications, it can never be morphed into one suitable for applications. Sure you can bend, stretch and glue bits on here and there but we are always fighting the original design fundamental. Either we change what we think of as application, or start a new design with what we want in mind.

Justin James
Justin James

Tony - No disagreement from me! HTTP and HTML were never intended and technically are just about the worst choices for running an "application." Ever wonder why no one has ever suggested FTP as the transport mechanism for an application? Because it is dumb. Yet HTTP is only slightly more aware in some areas than FTP, and definitely "dumber" in other areas that FTP. FTP natively groks authentication and sessions, HTTP does not. HTTP allows the backend to create and understand additional application layer meta data (in the form of HTTP headers) while FTP does not (as far as I know, I am not nearly as versed in the FTP spec as the HTTP spec). But until the oppressive regime of HTTP & HTML is overthrown, we have to make better use of what we have, and frameworks are the only way out. J.Ja

Justin James
Justin James

What do you think? Is it time for a new framework to emerge, unburdened from the old models? Or are things "good enough" now? J.Ja

Chief Alchemist
Chief Alchemist

I'm don't write much code anymore so go easy on me here :) These might also be seen as somewhat off topic. Again, forgive me. 1) What would iTunes be considered then? I obviously realize it's not browser based. Alhough at the same time I would consider it a web app since it largely depends on the internet to meet the user's needs. I'm no fan of Apple but it's hard to ignore the success of iTunes. Is this not the perfect example what you're hoping for? 2) Regardless of the graphic design and coding tools there seems to be far more bad web sites and apps than good ones. True, sometimes those tools compromise the ability to meet the user/biz needs but more often than not it's just a poor design implemented in a less than effective way. Maybe this is stating the obvious but to some extent isn't a framework only as good as those using it? Better and faster isn't a plus unless you know where you're going and why, no?

stuart.fraser
stuart.fraser

Agreed, iTunes is a good application and it does rely on the web for some of its functionality, however, it is still an executable on the desktop. Most corporates, very wisely, lock down their desktops and users are prevented from doing any kind if install on their PC's. My company sells a service which involves an application being deployed to clients PC's and for the reasons cited above this has to be done in the simplest, least intrusive way. That means using the browser and avoiding, insofar as is possible, any other plugins and/or downloads. All of the problems that Justin has highlighted on this page are the ones that I have issues with and they need to be addressed. My problem is finding a web development partner that recognises the limitations of the browser environment and takes steps to mitigate them, (we have already suffered from a ?double-click? issue which was only solved by our current developer with a very crude workaround). All too often web developers, in my experience, appear to have no experience of developing serious applications and therefore do not deal with the very real issues that arise when interacting with a database from a browser. (Java Guru, who is posting here definitely seems to be an exception). I am not a programmer, (well not a recent one anyway ? COBOL anyone?), but I understand the problems conceptually and it is refreshing to see that the views that I and my team have are not just the narrow-minded views of client-server Oracle developers but are recognised in other areas. The web is a fantastic environment to deliver services to users but it would be great to have the rigour and discipline of the 32-bit desktop development environment available as well.

Justin James
Justin James

How many Web sites have you seen, at the checkout page, warn you that clicking "Submit" twice will result in double billing? One really good reason to enforce the serialization of request processing at the user level! Barring that, you need to immediately set a flag at the session level that says, "Yo! I am performing operation XYZ, and block any other attempts to do XYZ until I'm done!" In other words, something similar to the singleton pattern, where singularity is enforced at the session level (or application level on occasson). As you say, I wonder if the Web is really ready for commerical release myself. Certainly not from the aspect of "application" development. We're still at a 1985 level of capability for things as basic as handling double clicks, and event handling is rudimentary at best, relying on all sort of tricks to determine what exactly caused the psotback and the conditions surrounding it; a trivial task in desktop app programming! J.Ja

Wayne M.
Wayne M.

Though I must admit I have spent time diagnosing and helping staff remove double click problems in client-server (and client only) environments, they seem ubiquitous in the web world. Almost every site I visit has double posts immediately followed by some profusely apologizing for "his" mistake. Coupled with the almost weekly panicked request from my wife concerning what "she did to break the computer" when she gets a 404 error, I still wonder whether this whole web thing is really ready for commercial release.

Justin James
Justin James

Sorry, I have never used iTunes, so I can't respond. Indeed, I do not think that I have ever even seen the application running or installed anywhere. I know, I am sheltered. Over 80% of my friends do not even own PCs. :) J.Ja

Java Guru
Java Guru

Please keep your desktop paradigms on the desktop. That same kind of thinking brought JSF to the java world. There is a reason that JSF still has not taken off in the java world. Web development is not desktop development. You program differently because you have different aims and different constraints. Parallelization A desktop developer does not worry about scalability, hence the single threaded model. Web developers are are using a single server to server hundreds, if not thousands of users. When you are trying to serve thousands of simultaneous users, the developer must be concerned with memory usage and throughput. FYI, any competent java web developer is very aware that the entire servlet programming model is multi-threaded. Try reading the servlet api instead of the documentation for a single class. The Session class is a data container and is not concerned with data access. Page model I have not seen where this is a problem. With java web frameworks, the UI is disconnected from the business logic. I could care less how it is displayed and my life is better for it. It sounds like your argument is more a misunderstanding of javascript (e.g. the only thing that runs on the client). You mention how a user can arbitrarily trigger methods on a web page. I cannot even guess what you are talking about there. A web page is only going to have the triggers that I make available to it. Any other triggers are going to be ignored. Desktop apps vs web apps is about trade offs. Do you have control of the user desktop? Do you have the authority to install an application? Do you need to be notified of every change that a user makes? Do you have large servers or small servers to accept user requests? What developer skill set do you have available? With that said, web development is continually undergoing evolution. Java web development has changed tremendously in the last 4 years. ROR is a good influence. Developer skill sets have not grown to comprehend AJAX. As AJAX is embraced by the API developers, it will get easier and easier. Flash is also exerting a lot of influence. Flash is currently the best of a desktop presentation via a web front end.

Wayne M.
Wayne M.

In a web application, much like in a desktop application, the key performance criteria is often response time rather than parallel load. Applications involving data entry often have simultaneous users number only in the 50 - 200 range. Transactions per second are typically quite low, but the key characteristic in making the application valuable is in the load time between pages. The user interface is key because it is more than just the display of information, it provides the validation for entered data. Data validity is provided in two ways; one, restrict the range of data to be entered, ala radio buttons, drop down lists, calendar controls, etc.; and two, by validation after data entry, ala character filters, range checkers, spell checkers, etc. In the latter, the lower the response time between typing and display of the error, the better. Users typically dislike entering a page of data, hitting "Okay" and then getting back a page of highlighted errors - they prefer to see the errors as they are entered. Another key characteristic of data entry applications is that users revisit the same pages time after time, though with different data. Everytime the user returns to a page, he must take the hit for loading client-side code and drop down lists need to be reloaded (is it any wonder many web based apps avoid drop down lists altogether?). Statefulness is another key characteristic of a web application. Users tend to log on for the day and take breaks without logging off. When sitting in front of a screen full of entered data, especially with no indication that some timeout has disconnected them, users expect the data to be accepted by the server. Developers are also in a constant battle to get users to not use the capabilities of the browser environment such as the Back and Forward buttons and Bookmarks/Favorites. In creating data entry applications, the user interface is critical. This determines user acceptance and whether the application meets its goal of increasing user productivity. I find this far more important than how much load is thrown at the middle tier server(s). Outside of a performance test lab, it is rare for more than one person to hit enter at any one time.

Saurondor
Saurondor

When you work with JSF you can't submit data in a list or radio button that wasn't in the page model to begin with. For example if you send a list of states to a form and then change that list through AJAX (say by selecting another country) JSF will not validate the form. That is one of the main issues with working with AJAX and JSF. You need to change the client side and also the model of that view being held by the server. If you don't validation will fail.

Justin James
Justin James

You are spot on about the UI, it is why I am such a stickler on usability. client side code is great at helping with this... but any client side code (particularly validation and input restriction) needs to be replicated server side, as a safety precaution. Remember, even if you use a dropdown list or radio buttons, the hacker can POST or GET whatever values they want for those fields! That is part of what I mean by "arbitrary code triggering"; it is trivial for a hacker to bypass any and all input restrictions on the client side, a not so simple task with a desktop app. J.Ja

Mark Miller
Mark Miller

IMO the page model forces you to update the entire page every round-trip even if you only need to update 10% of it. People like AJAX because there's not even a postback, but frameworks that emphasize components are another answer. You still have the round trip, but individual components receive a "postback" when the user hits one of many submit buttons on a page, and the component is the only one that's responsible for updating its display. The rest of the page comes back as it was before, unless the postback ends up causing some changes in other components, due to some dependencies.

Saurondor
Saurondor

I think AJAX solves a great deal of problems at the expense of having to work with JavaScript and the issue of security with cross site scripting. That aside I believe AJAX reduces load (or at worst ends up being the same as page updates). You might get more hits, but wouldn't it be the same either way? After all if you submit data through a form by sending the whole page you still need to create the connection. AJAX creates the same connection load, but less data is transmitted (just the AJAX call vs the whole page), less dbase queries are done (only the required ones to return the call not the ones needed to regenerate the page), session and authorization load exists when sending the page too. Maybe you're looking at it from the autocomplete list or text field, but that aside AJAX is a great tool that allows for punctual updates on the pages and a better user experience.

Justin James
Justin James

... AJAX causes a zillion requests to the server, significantly increasing overhead (unless it is an anonymous connection, no session, state, or authentication needed). It also demolishes the UI of the browser itself. AJAX solves some problems, while causing new ones, and I think that the tradeoff is rarely worth it. J.Ja

Justin James
Justin James

He summed up pretty well what I probably would have said. I wanted to add to it though. Regarding what you say about parallelization, I could not disagree more. Desktop developers have to worry about it *even more* because they do not have the luxury of an enterprise server automatically multithreading requests. A desktop developer gets to do that on their own. Regarding the dig about reading the entire servlet API... ever wonder why there are so many decent coders out there making fundamental mistakes? Maybe it is because few of them read the entire API, but use the documentation as a reference? The other two pieces of documentation I link to both come from the documentation about an individual class. Sorry, but the Java docs have always been less than worthless, because they give zero context. They merely tell you the basic purpose of something and the syntax; examples are rare (I cannot remember seeing any) and knowledge of when or where to use one technique instead of another similar one is never addressed. When I talk about arbitrary triggering of functionality, I mean *just that*. Not that the user can force things to occur that are not exposed. But a user *can* completely bypass any safety mechanisms built into the client side cide, whether they be length limiters on form fields, JavaScript validation, and so on. This includes working around any enforced workflow, such as calling the third step in a process without calling the first two steps, simply by requesting the correct URL and maybe posting some data. That is "arbitrary triggering of functionality". It is pretty tough to force a desktop app to do this. I agree that desktop vs. Web apps is indeed a tradeoff. But it is a one-sided comparison from the viewpoint of the person writing the code; particularly since any functionality avaialable to a Web app is available to a desktop app writer. All of the pros and cons focus on business level or non-development technical matters... deployment, authority to deploy, central server storage, and so on. Ever hear someone say, "it is a lot easier to build a menu in HTML compared to using Windows forms?" Neither have I. I also agree that many of the new systems coming out are pretty interesting. I am still waiting to see if RoR gets major traction. AJAX is a royal mess, in my opinion, for a number of reasons, but it is the best choice out there right now. Flash is pretty good too (Apollo/Flex look great), but the plugin situation makes them unreliable as a development path. J.Ja

Saurondor
Saurondor

At the end of the day they both boil down to the same thing: interacting with a user through a glass panel with lots of little buttons under his fingertips and a oval shaped device with a laser underneath. You will eventually want to have a state, a set of input values and action and an output of said action. Hence Justin's comment on the page model. Even though the application can be doing a lot of things the user will only be doing one thing and clicking on one button at any one given time. Although the order and timing of said clicking can be arbitrary and I believe that is what Justing refers to. I'd like to comment that the "desktop" developer has to worry about thread safety as much as any other developer. Clear examples of this is the web browser itself. With various tabs I can be typing this and have my gmail updated in the background. Another example is a graphics program like PhotoShop. A filter or some process can be applied to a picture and kept running while I work on others. It is also worth commenting that there are various "levels" or "stages" to web application development. You can start with your simple applet which is web delivered, but self contained. Move to an applet which is also web delivered, but contains a dbase connections still containing all its business logic in itself. The applet could move to having RPC to a central server and be only a fachade. You could replace the GUI (Swing) fachade with an HTML fachade and enjoy the benefits of running it on any browser wihtout worry of virtual machine instalations. Unfortunetly you have to worry about reconstructing the GUI on every request (session management included), management of the user posted data, security etc. All over HTTP. Yet the end user is still doing the same thing. Entering data and clicking buttons. It is great for him to open up his browser and enter an application others can be working on at the same time and colaborate together. It is great for us to have a web app because maintenance is centralized and upgrades occur in one spot only. The server. Yet a great deal of todays web apps are glorified remote terminal desktop apps. Untreal Tournament or Doom III are more a web application when in multiplayer than Hotmail. Simply because I?m getting more feedback from the web in a tournament than I?m getting from my Hotmail window. Only difference is the mails are stored in a server while I get a little window into the inbox. Yet functionally it isn?t much different from Outlook Express or Thunderbird. Here lays the strength of tools like Flex and ideas like Google?s documents. Flex allows me to develop anything from the simple panel with buttons to the self contained application in flash. Which is a very commonly installed plugin if not the most commonly installed one. One user tool, the browser. One developer tool, Flex. Google?s documents offer an advantage in cooperation. They?re the Doom III of document editing. Nobody cares for a simplified MS Office version that runs on the web. If I wanted a view port to a document editor that was free I?d install Open Office in my laptop instead. Google offers the benefit of easy cooperation and concurrent editing (Google gears is also aimed at that as well as off line operation). In the end it is all about button clicking and data entry so desktop and web development are very similar. I believe the real move has been and will continue to be from pure desktop to webified desktop apps to actual gridded applications. Over the years different sectors have moved between these attractors. Keeping state on the client or server or processes in the client or server or state and processes across various clients and servers.

Saurondor
Saurondor

Justin, I think you're right on the mark regarding some frameworks and yes HTTP is way to over rated for application development. Despite this it doesn't seem to be going away anytime soon and with web 2.0 in looks to become even more entrenched. In my experience (Java) I've been through Struts (just marginally), JSF and Spring. In short they're the intrusive, the bloated and the good respectively. Struts is way to intrusive on your code. I like to have clear distinctions between what is presentation (html/swing) and business logic. JSF goes a good way to achieve that, but fails to provide a proper Swing equivalent. It is also very very heavy. Spring is a good balance. It is simple and allows you to glue your code to an html or swing presentation layer pretty easily. Since it does all the validation and encapsulates your "form" data in a simple bean you really don't care if you're getting it from an html form, an ajax request or a swing panel. This leads to very easy testing of your code. JSF also provides this, but is way heavier and doesn't provide a glue mechanism outside a container (at least not that I know of). To sum things up I'd say my checklist for a good framework is: -Do what needs to be done. Not what would be nice to get done. Thus reducing bloat and server overhead. -Allow me to map an action and a set of data in a form (be it html or swing) to a method call easily. Including validation. -Allow me to map a response to a view and result presented to the user. (JSF did these two last points nicely with it's concept of views and managed beans, but is way to heavy compared to Spring) -Allow easy testing of individual parts. I find Spring to be excellent at this. Not only can you use Spring to glue your application together. It also includes a subset in the framework explicitly for testing. Plus the whole concept of xml configurable beans can be recycled to configure the test cases themselves. Finally Justin, I'd like to add that I use MyEclipse (myeclipseide dot com). It has a Web 2.0 debug module which allows you to view XML calls from Ajax as well as breakpoint your Javascript code. Take a look at the site and check the Ajax demo out.

Saurondor
Saurondor

Well now, getting a double post when talking about web apps and concurrent session access. Mhhhhh couldn't have been at a more appropriate moment.

Java Guru
Java Guru

There are lots of solutions for double clicks, but not very well understood or known. Struts has had this for years, but most java developers are not aware of how easy it is to prevent.

Saurondor
Saurondor

Justin, I think you're right on the mark regarding some frameworks and yes HTTP is way to over rated for application development. Despite this it doesn't seem to be going away anytime soon and with web 2.0 in looks to become even more entrenched. In my experience (Java) I've been through Struts (just marginally), JSF and Spring. In short they're the intrusive, the bloated and the good respectively. Struts is way to intrusive on your code. I like to have clear distinctions between what is presentation (html/swing) and business logic. JSF goes a good way to achieve that, but fails to provide a proper Swing equivalent. It is also very very heavy. Spring is a good balance. It is simple and allows you to glue your code to an html or swing presentation layer pretty easily. Since it does all the validation and encapsulates your "form" data in a simple bean you really don't care if you're getting it from an html form, an ajax request or a swing panel. This leads to very easy testing of your code. JSF also provides this, but is way heavier and doesn't provide a glue mechanism outside a container (at least not that I know of). To sum things up I'd say my checklist for a good framework is: -Do what needs to be done. Not what would be nice to get done. Thus reducing bloat and server overhead. -Allow me to map an action and a set of data in a form (be it html or swing) to a method call easily. Including validation. -Allow me to map a response to a view and result presented to the user. (JSF did these two last points nicely with it's concept of views and managed beans, but is way to heavy compared to Spring) -Allow easy testing of individual parts. I find Spring to be excellent at this. Not only can you use Spring to glue your application together. It also includes a subset in the framework explicitly for testing. Plus the whole concept of xml configurable beans can be recycled to configure the test cases themselves. Finally Justin, I'd like to add that I use MyEclipse (myeclipseide dot com). It has a Web 2.0 debug module which allows you to view XML calls from Ajax as well as breakpoint your Javascript code. Take a look at the site and check the Ajax demo out.