BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations Web Development: You're Doing It Wrong

Web Development: You're Doing It Wrong

Bookmarks
48:55

Summary

Stefan Tilkov challenges many commonly-held assumptions about how to best develop web applications, emphasizing the strengths and ideal roles for HTML, CSS, JavaScript, HTTP and URIs.

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

About the conference

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.

Recorded at:

May 16, 2013

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • but why?

    by Duraid Duraid,

  • Self-respecting programmer response

    by Eric Smith,

  • Food for much thought here

    by Justin Forder,

  • Please take a look at Flex4, all you are dreaming for are all there for years.

    by Gary Young,

  • In short ... (the last 5 minutes of the talk)

    by Dave Marney,

  • Too much of your argument is based on a narrow view of "web application"

    by Russell Leggett,

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

      by Stefan Tilkov,

      • but why?

        by Duraid Duraid,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        Why do we have to stick to the original model of the web which is resources and links? why can't we substitute that model with the 'Desktop Application' model which is a data + UI? why? why? why?

        Are we getting it wrong or you're trying to shove that old model down our throat?

        From the user's perspective, he does not care about REST or Roy Thomas Fielding's dissertation. He cares about useful and easy to use UI.

        From the developer's perspective, again the hell with Fielding's dissertation. He wants to build applications that are easy to build, maintain and extend.

        The rest is bla bla bla (no pun intended).

      • Self-respecting programmer response

        by Eric Smith,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        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.

      • Re: but why?

        by Faisal Waris,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        thank you

      • Food for much thought here

        by Justin Forder,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        Thank you for this clear, insightful presentation. I had a much more limited view of the scope of progressive enhancement/unobtrusive JavaScript before.

      • Please take a look at Flex4, all you are dreaming for are all there for years.

        by Gary Young,

        Your message is awaiting moderation. Thank you for participating in the discussion.

        Please take a look at Flex4, all you are dreaming for are all there for years.

      • In short ... (the last 5 minutes of the talk)

        by Dave Marney,

        Your message is awaiting moderation. Thank you for participating in the discussion.

      • Not everything new is good, nor is everything old, bad. Use what works.
      • The web is an infrastructure as well as a technology stack. Work with the web, don't work against it or re-invent it.
      • Make things easy, even if that's hard. That may mean you need to learn how the web works.
  • Re: but why?

    by Dave Marney,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • Re: but why?

    by Duraid Duraid,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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.

  • client side rendering rulz

    by bodrin bodrin,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    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..

    Use the Web for static pages :P

  • Re: In short ... (the last 5 minutes of the talk)

    by vahid zoghi,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    (Just to clarify) Make things simple even if it is hard to do so

  • Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

    BT