-
Get a monthly update on best practices for delivering successful software.
It has been a good run, but Ajax the buzzword will dip below the radar in 2009. That's not to say that we'll all stop writing JavaScript and using XHR in the coming year -- quite the contrary. Full 100% of web applications will incorporate Ajax technologies, we just will use the "Ajax" buzzword less and less, much as "HTML" became just another acronymic noun in the early days of the web. So that's not really controversial.
What's really going to happen in 2009 that will impact all of us RIA developers? The first raft of Ajax-enable webapps will be undergoing maintenance. Supportability is the real test of frameworks, architectures and designs. How easy are they to support? How painful is the life of a maintenance programmer working on a Dojo codebase versus a JQuery codebase?
We've been emphasizing the use of application level MVC frameworks here of late.Why? Because we feel that the best and most sustainable metaphor for RIA's is that of the desktop component GUI, not of the souped up webapp -- client/server making its triumphant return. Without this guiding principle -- that we are writing applications that consume backend services rather than backend services that display interfaces -- we face escalating development and maintenance costs.
I hope then to see two front end web development trends for the coming year:
What are you predictions for the coming year?
Related posts:
Topics: Predictions, PureMVC, Trends
Sounds like you’re predicting a switch to something like Wicket, GWT, or Echo2. I’m all for it. We shouldn’t have to mix presentation _logic_ with HTML.
Comment by fsilber, Thursday, January 8, 2009 @ 9:05 am
I dunno. Having been around for a while, this sounds familiar. History is littered with failed projects that purported to build or use platform independent widget libraries.
The problem now is the same as then. Applications (including internet applications) built that way will always be slower, quirkier, less maintainable, and/or less functional than “native” ones.
In this case, “native” is html+css+javascript. Apps built using those tools will be better than ones built using “pureMVC” or any other utopian framework, I suspect.
Regardless; who the heck wants “pureMVC” anyway? I’ve never seen a plausible definition of “impure” MVC so cooking up a batch that is claimed to be pure is a stretch.
My $.02.
Comment by Bubba, Thursday, January 15, 2009 @ 4:07 pm