Code Monkeyism

Programming is hard by Stephan Schmidt

The future: web development without web frameworks - my slides from the first Berlin Java conference

Together with one of the senior developers on my team I gave a speech at the the first Berlin Java conference called Berlin.JAR. The topic was about how to develop applications for the web without a (traditional serverside) web framework. There is a wave towards rich AJAX applications with GUI logic in Javascript. Two forays are SOFEA and SOUI. The speech covered examples of how to design web applications without a web framework with rendering in Javascript and a client side message bus, using REST, Jersey, OpenAJAX, PURE JS and jQuery. My slides in an English version can be found on SlideShare or here.

The really nice thing is that backends can be written - independently - with Ruby, Python, Javascript, Java, Clojure, Scala, Erlang, OCaml or any other language. As integration doesn’t happen on the server but in the browser (late and lazy integration), it’s faster (asynchronous) and easier than on a server.

Thanks for looking.

About the author: Stephan Schmidt is currently a team manager at ImmobilienScout24 in Berlin. Stephan has been working as a head of development and CTO. He has used a lot of different technologies in the last 20 years including Java, Rails and Python. Stephans main field of interest is maintainablity and productivity in software development. Want to know more? All views are only his own.

If you did like this article but you don't want to subscribe to new articles with your reader, you can follow me on Twitter or subscribe to new posts with your email:

Comments

André

Thank you for this great experience. Hopefully we can repeat it at another conference.

– André

stephan

“Yes we can” :-)

Very interesting, even (or especially) for a non-Java guy like me.
I like this article by Nolan Wright:
http://www.sdtimes.com/content/article.aspx?ArticleID=31916

For classic web development (=HTML based UI) I guess this boils down to if you want to enable a fallback for old-school browsing without JavaScript or not.
In the RIA space (Flash/Flex/Silverlight) it’s always been similar, but not so much aware of REST in the beginnings.

stephan

Yes, it boils down to that perhaps. And SEO.

Very nice presentation! I’m going to do a similar talk at AjaxWorld in a couple of weeks, as a matter of fact. I do think that you might be interested in Dojo’s data models, though;

http://www.sitepen.com/blog/2008/06/13/restful-json-dojo-data/

Dojo has a lot of different data stores which support a lot of different back-end data, from Google RSS feeds and Wikipedia searches to full REST services. Most data-consuming widgets use data stores, which simplifies changing widgets or conversely changing back-ends.

I call it Thin Server Architecture, though. Ganesh really want to hold on to XML as a data format, where I’m more agnostic (leaning towards JSOn and JSON-schema).

Cheers,
PS

stephan

Coincidently I’ve read a sitepan post today via Ajaxian about Reinhardt.

I’ve used Dojo in the past but wasn’t amused about the code quality

http://stephan.reposita.org/archives/2006/12/18/static-tools-for-js-please-dojo-please-use-them/

I’ll take a look at your link though which looks really interesting.

stephan

Concering a data format: See my other post about XML and JSON. As I currently try Scala and it has really nice XML format and I have a better feeling about storing XML than storing JSON in a database (file, Scalaris, RDMS, …) I tend to like XML on the server and as an exchange format but convert it to JSON after receiving it in the browser.

Yes, a lot has happened in the last two years. Dojo has come from 0.4 to 1.2 (which in itself is just numbers, of course).

One of the more pleasing things I’ve used the last year is the cross-browser 2D graphics support which is a canvas-API that uses canvas, vml, svg or silverlight depending on browser type. It works really well, and Dojo’s own JS-only charting library is built on top of it;

http://download.dojotoolkit.org/current-stable/dojo-release-1.2.0/dojox/charting/tests/test_event2d.html

(Slow at the moment, since it’s their dl server, but it’s a good unit test)

Cheers,
PS

I totally agree with you, but something is wondering me.

Imagine your user landing in a page that display a list of items.
Do you will load the page with empty table, and fill the table with PURE JS by requesting an ajax file ?
Or do you will load the page with the filled table made from the server side (php/asp/java/etc) ?

Because the first way need the user to load two pages from the server (the html “template” and the ajaxified content for PURE Js).

stephan

Currently the first one. But I have tested a version of the architecture which renders the REST results into the page and then fills the message queue onDomReady.

Yes he needs two pages (and JS libraries and images and CSS pages). The JSON content and the html content can be easily cached though (browser, server, in-between).

Right, SEO is an important point. On the other hand, I don’t think this is too limiting really. You can generate the (static) content and download the app on top of that I would think.

stephan

Yes, it’s common to generate static content for SEO and have an application on top of that.

Hey, “not smart” guy here. This is almost an exact dupe of my talk in Berlin more than a year ago.

http://www.railsconfeurope.com/cs/railseurope2007/view/e_sess/14454

stephan

@Tim: The presentation is based on ideas from my days as a CTO of a wiki-blog-semantic-search startup around 2000 - around 8 years ago - repackaged with SOFEA.

Leave a Reply