What Is the Best Technology to Write a Web App With Today?
December 06, 2011Web technology, of all programming areas, has always been the most dynamic speciality of all. The shear number of ways you can write a web application or website is almost beyond comprehension.
So what is the best technology to use for the web?
I have no clue. Really. I have a fair amount of experience with writing for the web over the past 13 years, but I still have no way to be sure that anything I've used, or anything I've read about, it really a best way. Given the vastness of the topic, probably no one really knows for sure.
My first experience with writing for web started in 1998 using WebObjects. I worked for a consulting firm and that's what they specialized in. For those who have no idea what that was, it came from NeXT, Steve Job's company in between his stints at Apple. WebObjects and its companion database technology EnterpriseObjects, were written in Objective-C and generally hosted on various flavors of Unix. At the time Objective-C was relatively obscure and only really existed for NeXT based development. Most people had no idea what it even was.
At a time when most web application were still written with CGI and Perl and even PHP was relatively new, WO/EO was incredibly powerful stuff, despite the oddness of the language (though one could argue that Perl is still pretty off the wall). We were able to build complex applications with few people so it was pretty cool to use. Once NeXT merged with Apple it actually became harder to convince people to let us build web applications with it; people assumed any web technology from Apple had to be pretty crappy.
So I did a major in-house presentation on a new technology that I though we should focus on, Java and the first release of J2EE (as it was known then). I called it Alien Technology. People were skeptical as the language seemed unlikely and J2EE, especially EJB, seemed way less powerful than what we were used to. So I was "volunteered" to do the first job that came along where it was required.
It turned into a year long project and was probably one of the most fun large scale projects I've ever worked on, automating a huge manual operation at SABRE (the reservations company) with both a travel agency customer facing website and internal workflow system for about 120 people. Most of it was written by me and one other guy. We skipped the still useless EJB and built everything on top of JSP and JDBC. The customers loved it and it saved SABRE millions of dollars in airline penalties due to the extensive audit functionality.
We never did another WebObjects project.
Of course couple years or so later the dotcom world collapsed and eventually took the consulting firm with it.
In the following few years I did a number of different kinds of Java/J2EE projects. I really started to hate them. JSPs were an abomination, EJB's never really worked well enough. I experimented with different frameworks which began to appear in droves for the view layer, each one promising better productivity. Eventually when AJAX appeared I built some applications using a thin Java layer on the backend (first by hand and then with one of the early frameworks, DWR) and did most of the work in Javascript. I found it far more productive to not have to compile and restart an app server and could work most of the time in a simple "reload page" procedure. I even wrote several web frameworks of my own trying to find a better way.
During this time I wrote an infamous post in this blog where I poured hate on PHP and got thoroughly reamed by the community. Later I actually tried PHP and immediately appreciated it as being so much more productive than anything I had done before (although the pure AJAX apps were great too). I think being able to immediately see changes to an application without waiting was what impressed me the most. But I could only use this at home and on my own projects.
One place I worked used BEA Weblogic Portal (I think it was called). Despite them using it to build regular web applications (and not a portal) bouncing the local installation to see your changes took at least 20 minutes and often longer due to the excessive launch time of the app server and the portal server. At a previous job a J2EE project took 2.5 hours to restart the app server due to mismatched component versions (IBM Websphere and Commerce server and a JD Edwards connection) so testing was horrible slow.
For small projects and for the AJAX apps I wrote I used Jetty to speed up development. But the two big organizations I worked for had heavy application server stacks and productivity in development was never important.
Throughout all that Java work I did find I often missed WO/EO and amazed that something so great was now so dead. But I think today in hindsight that WO/EO should be dead as it doesn't really fit the AJAXified world of today. Even Apple rarely uses it any more (except in the execrable iTunes Connect).
So yes I like PHP but I think I would equally like Python or anything that was interpretable. What I find far less appealing is using Java/J2E or Java/Spring or any of the hundreds of Java frameworks for anything web related. One could argue Java and for that matter .Net are now obsolete technologies, less productive and despite a lot of advancements still too heavy for anything but large scale applications. Even there one could argue that technologies like PHP and Python are used for giant projects like Facebook and Reddit. Today projects of scale are far more likely to be a combination of technologies, from various types of caching technologies, to NoSQL databases, to horizontally scaled collections of specialized applications, even many bits running on cloud environments and services like Amazon or Azure. I find it hard to consider a single integrated technology really makes any sense any more except for small projects, and there you generally want something lightweight.
Like COBOL, the big heavyweight technologies like Java/J2E/Spring/etc and .Net are likely to never vanish no matter what is available. Even there I can't really argue effectively that they are obsolete or even not suitable for projects. They feel old to me but that may be simply be one of my distance today. But it's also hard to say that productivity and performance shouldn't be considered together.
So what is best? I have no answer as there is unlikely to be a good one that works for everyone and every kind of project. I do know that if I had a choice I would always push for anything that gets the job done fast, runs fast, and remains easy to work with in an ever changing world.