Sponsored Content

Bio

Stefan Tilkov is Co-founder and Principal Consultant at innoQ, where he spends his time alternating between advising customers on new technologies and taking the blame from his co-workers for doing so. He is a frequent speaker at conferences and author of numerous articles. Twitter: @stilkov

Software is changing the world; QCon aims to empower software development by facilitating the spread of knowledge and innovation in the enterprise software development community; to achieve this, QCon is organized as a practitioner-driven conference designed for people influencing innovation in their teams: team leads, architects, project managers, engineering directors.

Very interesting talk. However, I think it is clear to us that the tech stack of the 90s has been a struggle. The browsers don't support your model very well. HTML is based on the same assumptions as XML and is not good for humans to write or maintain. CSS is a complex language that is difficult to become good at (especially given browser inconsistencies over the years). And despite being forced to use it because of eventual universal implementation and acceptable speed, Javascript is a mess of a language that is extremely ill-suited to building applications of any depth or size. To be fair, your presentation hints at going back to using Javascript in a more narrow role. And this may be justification enough for following your suggested approach. But the worn-out argument for 'resources' and 'statelessness' just hasn't gotten traction over the years. We are being held back because of the lack of innovation in the Web. And we'll do whatever workarounds we have to until something better comes along.

Lastly, the tension between generic vs specific is interesting. Starting with an abstraction usually doesn't work. Problems are solved for specific cases, and then general cases are 'abstracted' for broader application. Any part of the tech stack that doesn't support this natural process will be a failure, or at least a struggle.

Not sure what you're really asking. Why stick with the "original" model? Because the web is a deployed infrastructure, not merely a programming paradigm. You wanna come up with a new model, go right ahead and deploy it, then we'll all use it if we like it. But it will probably take a good, long while for that kind of adoption.

The closest thing we have to a new globally-deployed infrastructure are the walled gardens of the various appstores. Personally, I think the jury's still out on those, since they are bound to specific vendor devices. What happens when people stop using iPhones? Unless the appstore is cross-device, it probably won't last.

I think we have to accept that things evolve and that we don't get attached to things like back/forward/refresh buttons to be used the same way when they were initially invented in the 90s. This is what I mean by the original model. Just because my application does not work with the back button it does not make it wrong.

I think we're in a transition phase between traditional websites and single-page web application and such disagreements are to be expected.

Too much of your argument is based on a narrow view of "web application"
by
Russell Leggett

Let's just stop labeling things as "Desktop Applications" and "Web Applications". The goal of HTML5 and all the rush towards bringing in new technology in the web stack, and the rise of frameworks that you would consider *doing it wrong*, is to make a "Web Application" be able to just be an Application. Do you think that only certain types of applications should be deployed through the web stack? Should the web steer clear of games, music players, video and photo editing, drawing, word processing, email, etc? Google doesn't need to crawl any of those. Forcing a full page refresh for any non-trivial interaction really is a step backwards for those types of applications. Almost your entire argument is based on making it work with Google. I'm sorry if that doesn't compel me when I'm not actually in that boat.

The problems with back/forward buttons, linking, multiple tabs, bookmarking, etc. can all be done without page refreshes. We've known how to handle it for a while, and its a pretty solved problem at this point for anyone who puts in the minimal effort.

Re: Too much of your argument is based on a narrow view of "web applic
by
Stefan Tilkov

The thing you're missing (or I'm not getting across) is that you can have the best of both worlds: A site that exposes addressable, individual resources, and still doesn't require page refreshes if you're using a modern browser with JS enabled. There is no need at all to sacrifice all the good things that come with the Web just to have a modern, interactive, "sexy" application. That's what unobtrusive JS, and indeed most of my presentation, is about.

Re: Too much of your argument is based on a narrow view of "web applic
by
Russell Leggett

I don't think that the approach is bad, but I think your phrasing of "you're doing it wrong" which is, probably purposefully, a little inflammatory :)

My point was simply that while it might be a good architecture for some applications, it is not necessarily a good architecture for all applications. As much as you would like to bang on the drum of google searchable, the other side of the coin is: "what about offline? what about slow data connections?"

The unobtrusive javascript movement has a lot of valid points, but the problem with it is that it breeds a notion that all this "sexy ajax stuff" is just a little extra layer on top that makes it sparkle! Boring old web app from 2001? No worries! *waves jquery magic wand on top* It's about as inflammatory to me as when developers say things like: "The app is all written, now we should just hire a designer to make it look pretty."

For many cases, the unobtrusive approach will work really well, and indeed is often the *best* approach and not just a good approach. However, you still haven't answer my more direct questions - what do you do about a photo editing or word processing app, or a game? What is JavaScript "allowed to do"? Google docs doesn't do a page refresh every time someone makes a change or saves. What are the limits to what you would consider ROCA?

I will admit I have a personal bias because I have been doing SPAs since 2006 and I never want to go back to generating html on the server if I can help it, but I also don't think that my style of application development is appropriate for all cases.

Re: Too much of your argument is based on a narrow view of "web applic
by
Stefan Tilkov

I think we agree: No style is appropriate for everything, and yes, the session's title was of course inflammatory on purpose. I would not suggest building an offline app using a ROCA approach (wouldn't work), and I also happily concede that there are a lot of cases where a totally different kind of app makes sense (e.g. a game, a 3D graphics editor, etc.).

What I observe, though, is that many people needlessly, without knowing about the alternatives, build apps that are not even remotely in that category in a way that makes them suck for their users. Sadly, I include most uses of SPAs in that.

"What is JS allowed to do?" is an interesting discussion. In my preferred architecture, it's restricted to pure view logic. In the text-editing example, a JS control could turn a server-generated HTML textarea into a fancy input control, autosaving without page refreshes or calling the server for spellchecking. Paging through a large result set might be done on the client (if you decide that you want to call this view logic, and the set is not too large), or you might consider it business logic, in which case you'd implement it on the server.

Re: Too much of your argument is based on a narrow view of "web applic
by
Russell Leggett

Well, I think we agree then on the most obvious cases at least, though I'm sure we differ where the line is. Personally, I think the criteria for when a SPA starts to become OK is:

- Does not want or need Google indexing- Is not like to have a lot of link sharing- Is not intended for fast/short lived access

So, yes, I think we'd both agree a game should probably not be ROCA. And I think we'd agree that news sites, ecommerce, and blogs should probably not be SPA. However, what about the shopify admin (currently going through a change to be a fancy JS MVC app)? I think something like that *could* be ROCA for sure, but I think its just as valid to be a SPA if that makes sense for their development team.

What I observe, though, is that many people needlessly, without knowing about the alternatives, build apps that are not even remotely in that category in a way that makes them suck for their users. Sadly, I include most uses of SPAs in that.

I agree with that statement, although not necessarily your ultimate conclusion. People build SPAs that suck, and many of them don't know the alternatives, ROCA being a perfectly valid one in most cases. That said, I think there are many cases where you would recommend ROCA, while I would prefer to go SPA.

You spend a lot of time talking about Simple even if Simple is hard. I agree with that entirely, and I loved that talk by Rich Hickey. Some of the things you described as Simple were good examples that SPAs make more complicated - like validation. Validation on both the client and server does often require duplication. However you can still be a SPA without validation in the client. You should *always* validate on the server. Adding validation on the client is an optimization for faster feedback to the user. You can also be page based and validate on the client - that is one of the first big uses of unobtrusive JavaScript, so I don't really think that's a major win for ROCA.

On the other hand, the simplification of dealing with state is dramatically in favor of SPAs. I can truly make an application with uniform stateless RESTful JSON services and greatly simplify my server. The ROCA recommendations for using only stateless URLs to somehow carry context through seems extremely convoluted to me in comparison. A simple example being something like maintaining the state of a tree control in the sidebar while I operate on something independently. Do I carry the state of the tree control with me? Do I have to persist it in a database? Not to mention the waste of refetching and redrawing that tree and its state. There are many other advantages, but that one alone is enough for me.

I think that client side rendering is cool - this is the client's responsibility. WEB/rpc/REST... who cares.. Server should support commands and queries and can expose this as a ___single___ API appropriate for rich UI clients (browser,swing,whatever) or other machines or whatever..