Popular @
Forum Controls
Spotlight Features
The Rich Engineering Heritage Behind Dependency Injection
Andrew McVeigh takes us on a tour of the rich heritage behind dependency injection, what it represents, and tells us why its here to stay.
NetBeans 6: Matisse Updates
NetBeans 6 delivers great updates to the Matisse GUI builder. Spend a few minutes with Roman Strobl and get an expert briefing on what's new and what has changed. (sponsored)
Introduction to Groovy Part 3
In this, the third and final installation of Andres' Introduction to Groovy series, you learn about how Groovy handles variable numbers of arguments, named parameters, currying, and more about Groovy operators. Including, some new operators.
Easier Custom Components with Swing Fuse
Swing Fuse (actually just Fuse), is a framework designed to make it easier to create your own custom desktop components. In this article, Daniel Spiewak shows you how to get started and provides sample source code you can download.
Benchmark Analysis: Guice vs Spring
Willam Louth shows how he uses JXInsight Probes to investigate probable performance issues with code bases that he is not familiar with. He also highlights possible pitfalls in creating a benchmark, as well as in the analysis of results.
Web frameworks peaking toward obsolescence
At 12:20 AM on Nov 10, 2007, Roger Voss wrote:
Fresh Jobs for Developers Post a job opportunity
Struts
Struts2
Spring MVC
Echo2
Tapestry
Wicket
Seam
JSF
ADF
WebObjects
Groovy/Grails
JRuby/Rails
Of course I've barely scratched the surface.
Well, when making the transition to RIA web app development, it rather quickly becomes apparent that all these frameworks are now an unnecessary encumbrance. The likes of Tomcat and Spring along are sufficient.
When just implementing simple, streamlined services for a RIA client to interact with, the web framework is an unwelcome complexity and overhead. Plus, the developers find it's a breadth of fresh air to be rid of it. MVC is much better when it's entirely implemented in the RIA client. Once developers go RIA + SOA, they don't want to go back to the muddle of the server-side web framework approach - of any stripe.
Consequently as RIA web development is taking off and retransforming the Internet experience, web frameworks will hit their peak and then decline toward obsolescence.
Even for content heavy sites (the current soft spot of the RIA approach) there will eventually emerge a content management architecture that is well suited to RIA + SOA.
In short, implementing MVC on the server-side will become regarded as retrograde.
50 replies so far (
Post your own)
Re: Web frameworks peaking toward obsolescence
No, I don't think so. RIA is nothing new. It's just something old and creepy coming to life once again as Flex/Air and Silverlight.Big deal: this is Yet-Another-Client-Side-Sandbox a la Flash itself that exists since forever, Java applets, ActiveX, etc.
Face it: it make nice demos, but they are utterly unmaintainable and a hassle to develop in a team with several developers. Big apps just are not confortable. HTML 5 is the way to go, period.
Re: Web frameworks peaking toward obsolescence
And then how do you solve the problems that web frameworks solve? ie. how do you do server-side input validation and databinding? How do you serialize your model objects to document form?Answer: you need a "SOA framework" that provides the functionality that todays "web frameworks" provide already: validation, databinding and templating.
There's no magic bullets, sorry.
Re: Web frameworks peaking toward obsolescence
The stock browser as a platform has alway sucked.Re: Web frameworks peaking toward obsolescence
Gavin,I agree with you partly: applications, all applications, require functionality as persistence, validations, etc. This functionality can either be programmed from scratch in desktop applications or obtained packaged and debugged in many frameworks.
Web applications need access to such functionality on the server. It can't be implemented on the client, if only for security reasons.
However, it can't be denied that the concept of Rich Clients is very attractive: good response times, really sexy User Interfaces, interactive graphics... On top of that, you load the client CPU and not the server's and, if you're cunning enough, you can reduce bandwidth enormously.
The question really is: how do you marry the server framework with the Rich Client in a meaningful way.
Applets, Flash, Javascript? Or something else?
Basically the answer is that you can count on JavaScript being available. But, if your application is large, you can count on it making the package so slow as to be unattractive to intensive users.
Using Applets is much easier and more secure and faster and... but some people don't like Applets or plugins of any sort. Not the least, some large corporations.
So how can we create a solution that is easy to develop and maintain and works on browsers that accepts plugins such as Java and those that do not?
When we work that one out, we'll have made an enormous stride forwards. And we'll have answers to the questions asked in this thread.
My own feeling is that we need a distributable model where modules can either run on the client (if they're welcome) or on the server piloting a generic AJAX interface if they're not.
That way, the software will run on all systems, but it'll run better on systems that are allow Applets. This will suit the suspicious, occasional user and the demanding frequent one.
Ian
Re: Web frameworks peaking toward obsolescence
> No, I don't think so. RIA is nothing new. It's just> something old and creepy coming to life once again as
> Flex/Air and Silverlight.
You are right that the concept is not new. But having a ubiquitous platform and a programming model that supports the concept is something new. With Flash Player 9 now at over 94% adoption and with the Flex SDK being free - RIA is now a reality.
> Face it: it make nice demos, but they are utterly
> unmaintainable and a hassle to develop in a team with
> several developers. Big apps just are not
> confortable. HTML 5 is the way to go, period.
RIA technologies like Flex are well beyond the "nice demo" phase. There are now many Global 100 companies with massive applications built on Flex. These application are maintainable by large teams. While many of these applications are behind the firewall you can see about 130 real live public facing Flex application at http://flex.org/showcase
RIA is the future of software and currently Flex is the de facto standard for building RIAs. Of course this statement could be argued depending on what your definition of RIA is. Here is mine .
-James (Adobe)
Disclaimer: I work for Adobe, yet my thoughts are my own
Re: Web frameworks peaking toward obsolescence
I still don't think so. Being installed in every browser makes it ubiquitous alright but far from being useful. With luck every browser will bundle ad-blockers that also disable Flash based content.HTML is ubiquitous AND useful from a web content stand point. Of course I wouldn't expect an Adobe employee to say otherwise, but saying 100 companies are using is salesman rhetoric. Every single machine has Solitaire installed, and it hardly makes it any useful.
The are some edge situations where a RIA interface can be helpful, like manipulating visual objects on screen, a white board kind of app. And even then Google Maps proved that we don't need Flex-based RIAs.
As I said before what we do need is a better HTML 5 that is 100% compatible with HTML 4. Follow web semantics and you're ready to go. Flex, Silverlight and JavaFX are mostly hype right now. I can see no ROI here.
Opinions about the JUIBrowser-Framework?
Hi there,Yes I know its project advertising but somewhere I have to introduce it
Because I also had horrible experiences developing complex webapplications I started to develop a small framework.
The goal is to combine the good features of webapplications and RIA
* logic on server-side
* download as you need (don't download everything at once, like Webstart)
* fast, rich guis
* not trying to emulate a userinterface using a scripted text-viewer
It lets you write Swing-Like Code on the Server-Side, and a Swing-Gui is created on the client-side which behaves as specified on the server.
Is still very much proof-of-concept and the worst of the whole framework is its demo and its project-page.
But I would be interested in hearing your comments about it. It can be found on http://juibrowser.sf.net
lg Clemens
Re: Opinions about the JUIBrowser-Framework?
Hi Clemens,We went down a similar route to that a few years ago but it wasn't very successful. Although it worked very well technically, it caused more problems than it solved from a practical point of view.
The main obstacles we encountered when trying to convince customers to use it were non-technical based on a severe case of FUD:
- Applets don't work/aren't secure/belong to the past/etc.
- Users will have to load the JRE and that takes hours.
- Users in large companies can't load Java even if they want to.
- Many users don't accept plugins
- etc.
In practice, the first two arguments are completely fallacious, the third one can be true, particularly in multinational companies where IT is managed elsewhere and the fourth one is only valid while people are unsure whether they want to use a product or not.
We finally developed a model that is based on server-side Swing-like components. When the user connects, we check to see whether this browser accepts Java. If so, we download an Applet. If not, we download the equivalent functionality written in AJAX.
This works very well: people who are afraid of Java will work in the AJAX version for some time and then decide to download the JRE. I would say that globally 80% of people end up working with the Applet.
One problem we did get with the Applet though, is that some people were unhappy that the look & feel of the components was not the same as in the normal HTML pages. It made them feel that perhaps the site was not to be trusted. For these we wrote an interface from the Applet to the Ajax code so that the components themselves are generated by the browser. That way in Firefox, you get Firefox components, etc.
This system has been working for a few years now quite successfully. But as usual in these cases, when customers taste something good, they want more! We are getting more and more requests which would require functionality to be uploaded into the browser.
We have been working on this for the last few months. What we have produced (still experimental) is a client framework that is a subset of the server one. The client framework can run the came application components as the server framework with some limitations: all the UI functionality is identical and very efficient but things like persistence is done through proxies that go back to the server and are, thus not very fast.
The interest of this architecture is that if the browser refuses Java, we can run the components on the server. If it accepts it we forward the components to the Applet.
The system is showing a lot of promise and we will be able to create a demo by the end of the year.
Our server framework is documented in http://jet.inveo.be/JSPWiki/ and there are a few demo programs in the Tutorial http://jet.inveo.be/JSPWiki/Wiki.jsp?page=Jet.v5Tutorial
I haven't got down to documenting the client framework yet (it's still a work in progress).
Ian
Re: Web frameworks peaking toward obsolescence
I've moved away from web apps (I used JSF, mostly), and have started developing Swing clients that communicate with our Java EE back-end. My users (which includes both company employees and company customers) prefer the Swing clients (which are delivered with Java Web Start) over the web application, by a huge margin.For my part, I prefer coding Swing clients over web apps. No contest, there. I suppose I could improve the web apps with heavy use of Ajax, et cetera, but I'm glad I don't have to deal with it.
FWIW, we've had zero resistance to requiring the JVM (we need Java 5) installed. That was a surprise, to me, but a pleasant one.
Re: Web frameworks peaking toward obsolescence
> HTML is ubiquitous AND usefulAND open, unlike Flash/Flex
Re: Opinions about the JUIBrowser-Framework?
Hi Ian,Thanks a lot for your feedback and the information about your framework. I am quite interested in your "old" framework - how did it work, and which kind of APIs did it provide to the programmer?
To be honest I am - for myself - not really interested in browser-based frameworks. I worked with such a frameworks some time ago and the only conclusion I can draw is that no matter how you do it - most likely it will always be more or less some kind of quirk. I simply think its the wrong way to try everything (complex UIs), with nothing (browser).
Of course it depends on the point-of-view and the type of project - I started JUIBrowser because I was not happy with RIA clients I wrote before (chatty client-server communication, keeping client/server in sync, ...), not to replace browser-based-frameworks.
For projects which I would have done with traditional clients, JUIBrowser provides me a Swing-like API,and soon it will be scriptable with Beanshell. Even Netbean's GUI designer can be used to create UserInterfaces - and I don't even have to fear bloat, because it will run on the server anyway
For companies without a JVM installed, its still possible to redistribute a JET compiled executable.
lg Clemens
Why Flex?
> RIA is the future of software and currently Flex is> the de facto standard for building RIAs. Of course
> this statement could be argued depending on what your
Well exactly that makes me a bit sad - it seems Flex takes places as the next generation's technology when it comes to web technologies thanks to Adobe's excellent marketing - and it may be really great to develop those standard-apps with it but from a technology point-of-view it really doesn't do anything exciting nore outstanding.
In fact when I look at Flash9 I get more or less the taste that Flash wants to be like Java - not just a tool to play videos and software-rendered animations. So we have a Jit-compiler, another javscript-like language, and a class library. How boring - everything existed already for years (Java) and was at leats since java-1.2 much more powerful and far not as mind-limited.
Yes, I am a fan of Java because its development is (was?) not focused on buzzwords or technologies-must-have - Adobe as just another company trying to sell a product, which means fullfilling developer needs. Have a look at C# and see what it means to fullfill developer-"needs" - it seems like we get yet another C++, on another leven of course.
Conclusion: I want the best technology to win, not that one with the best marketing behind it!
lg Clemens
Re: Web frameworks peaking toward obsolescence
> > HTML is ubiquitous AND useful>
> AND open, unlike Flash/Flex
With things like open sourcing the Flash Player VM (Mozilla Tamarin), open sourcing Flex, and more open source on the way - Adobe is becoming significantly more open with their platform. One thing that is always a struggle is to define what people mean when they say they want Flash Player and Flex to be open. For instance even though HTML is "open" 70% of web users are using a browser that is not "open". So I don't think "open" just means specs that anyone can implement. So what do you think? What does "open" mean to you? And how does that definition work with technology that is massively adopted by non-geeks who don't know or care whether it's "open"?
-James
Disclaimer: I work for Adobe, yet my thoughts are my own
Re: Web frameworks peaking toward obsolescence
> My own feeling is that we need a distributable model> where modules can either run on the client (if
> they're welcome) or on the server piloting a generic
> AJAX interface if they're not.
>
> That way, the software will run on all systems, but
> it'll run better on systems that are allow Applets.
> This will suit the suspicious, occasional user and
> the demanding frequent one.
But then again, all the burden to make such software run and work is on the developers, it even increases at developers will have to test both User-Interfaces.
Furthermore it tastes like a common-divisor problem - the functionality of the whole framework (if you really want to use both interface backends) is limited to the worst one - in this case clearly AJAX.
Maybe its really time to snub customers and tell them to use Java - it will start fast its download will be ~5mb when the consumer-vm will be released.
I hope Sun gets it working well, I guess it would be _really_ important for applets.
lg Clemens