[adriand]

I think this makes sense in a couple of situations. First, for stuff that is fairly simple and where not having page loads is highly desirable, such as a music playing app like his example. Second, for stuff that is complex but you have a team of engineers and computer scientists as well as a suite of tools that make dealing with that complexity much more manageable, as in Gmail.

In most other situations though, where you have applications that are not simple, do not have some requirement that really benefits from not reloading pages (e.g. are not playing audio), you are not Google, the additional complexity this approach carries with it is really not worth it.

[kls]

It is really not more complex and done right it is significantly simpler. If you roll your own toolkit it is a pain, but if you utilize a framework like Dojo, it is far easier than Java(JSP, Struts, JSF, et al.) or ASP.NET or even PHP. Without the contortions of pumping everything to the server and then getting a response and trying to figure out that context, you get a far less fragmented memory model.

For example lets take a shopping cart, in the page post model you would submit the page to the server, create a cart in the session (bad, bad, bad) and then respond to the client with a new UI, the client would select an item, you would form post that item and the server would update the cart with the item. Back comes the UI and we do it over again with another item, ad nauseum. Eventually the user selects check out, we form post and hit a routine that tallies everything up and spits back another UI. We do this until all the data is collected to complete the transaction.

With the new model, The UI is the sole domain of the client and we speak to the server in complete representative state when we have the whole communication. Not only that but data definitions have very ridged walls that define what that data is, therefore making the server side code far more reusable (more on that in a minute).

So for this example, done the new way, JavaScript creates an order object, it then displays the UI for products after making an asynchronous call to get the product information (given that this is a defined call to the /products URL we can set a cache expiration in the future and therefore any subsequent calls have very little cost associated with them).

So now the server is acting as a data and business logic layer, while the client is providing the work-flow and the screens.

Back to the example, on the client side we have an order object, loaded with products that we have not had to make transitions to the server to create and update, we can then push this object to the server via a POST to the /orders service.

As you can see your data and business logic are becoming very defined and resource-able. If you decide to provide a mobile interface you already have the services available to support it, your data is no longer intertwined with UI work-flow.

The benefits of this model are vast but at a high level here are the big ones:

The client side becomes responsible for the work flow. So different UI's can provide optimized work-flows for their format. Web, Mobile, voice, do not have to rely on the same work-flows to reuse existing code and not start over.

Front end developers work in pure HTML, CSS and JavaScript there is no reliance on back end technologies to be able to perform their tasks.

Back end developers work in pure platforms, a Java developer works in Java, a .NET developer works in C#.

The front end and back end are loosely coupled through service calls, either can be swapped out without ramifications to the opposing side.

You data and business logic becomes addressable, a natural byproduct is that you can expose your system to third party consumers and alternative UI's.

You are working with a non-fragmented object model, one party is responsible for state and that is the client.

The front end is far more responsive to user input. You have far more opportunity to pre-fetch data based on user patterns and expectations. You have fine grain control over performance.

UI's are best programmed via an event based model. It is impossible to achieve this within the old page post model. (See the Node.js talk on blocking vs no-blocking, this is a relative of that argument).

Session management is offloaded to the client, reducing large amounts of memory and resource requirements on the server side. No longer does the server have to approximate what is happening on the client side.

A byproduct of the client holding session is that any disruption in communication does not reflect a total failure of the transaction. The client holds state and therefore can submit to the server once it become available again, no matter the point in work flow.

The decoupling of the server side allows the UI teams to develop the front end in a far more agile and rapid fashion. They can hold closer to the stake holder and rapidly modify the application to meet user needs.

If a top down approach is used, the entire front end can be prototyped while creating stub service files, allowing the stakeholder the ability to touch and feel the application before back end development begins. This significantly reduces the costs associated with development to get to the point where end users touch and request rework to the application. Further, the stubbed services provide a clean definition of the services required to the back end team.

I could write a book on the pros of this development methodology but sufficient to say, with JavaScript frameworks and proper architecture, writing new style web apps is far less cumbersome and a lot less convoluted. I was one of the nay-sayers until I tried it and actually found that it was easier and produced a superior user experience. The benefits to building apps this way are numerous.

[hellweaver666]

In your post you say:

>> create a cart in the session (bad, bad, bad)

Sorry to be a total n00b, but why is it bad to keep the cart in a session? What do you suggest as an alternative?

[kls]

Server side session is a outcrop of the idea that the client is dumb philosophy, as such, the server has to "approximate" the client, this leads to many counter intuitive patterns like session. By far the worst evil is the fact that you have no guaranteed destructor because you have an approximation. So if the client wanders off, you have no way to clean up based on that event other than a brute force timeout. Further session by nature has no way of self governance. For example, I cannot wire an object in session to be cleaned by an observer once an action happen, so a natural byproduct of this is that you get "junk" in the session that all live processes that have reference to it have terminated thereby leaving a zombie.

[kls]

Sorry for replying to my own post but I did want to touch a little further on this subject. above I stated:

So if the client wanders off, you have no way to clean up based on that event other than a brute force timeout.

A common rebuttal to this is well just sprinkle in an AJAX call. Which in my opinion is the worst decision one can make. Now not only are you supporting a server model but you also have client mode sprinkled in which compounds the complexity of you application significantly, in essence doubling your technology stack. This is the choice a lot of developers make when trying to dabble in RIA and it is my held belief that this is a fatal mistake. It doubles the required skill set and creates convolution in the sequences of application communication.

[mhansen]

By 'an AJAX call', do you mean having the client periodically ping the server, and then cleaning up the session if the ping times out?

[kls]

No I mean wire an event to the unload of the page, that notifies the server that the client has abandoned the app.

[sqrt17]

Well, nowadays you can encrypt and sign sessions and store the signed/encrypted data on your client side (or non-encrypted cookies if you want them to be modifiable from the client side). As long as it's more difficult to fake session data than to buy working credit card numbers, you're fine (at least once you've taken care of XSS attacks, which I take to be no less of a problem in a single-page site).

Wow. Did I just point out that cookies have legitimate and valid uses? My self from 10 years ago would run after me with a shovel and yell that cookies are evil. (Incidentally, the opinion of my self from 10 years ago about Javascript would be exactly the same).

[mhansen]

He suggests keeping the cart clientside in (e.g.) a javascript array.

[DTrejo]

Can you link to some examples of this? Do you use only dojo on the client side or is there something more?

[kls]

For large applications I use Dojo, for quick small apps and web pages I use jQuery. I focus my time on these two because I feel that they represent the best in their respective classes. But yes, I use Dojo, CSS and HTML that is pretty much it. For the back end I use Java, mainly because there is a wealth of middle-ware technology available for Java. I use JAX-RS to provide all of my services as RESTFull services.

http://www.ibm.com/social/impact/

[mattmanser]

The techniques you're describing aren't benefits of your system. They're just modern web programming techniques and certainly don't need to be used in a single page programming model.

For example the majority of what you're describing as benefits has been known to anyone using MVC for a while, MVC is available in any of the languages you mentioned as your system being easier than.

[kls]

MVC was conceived to account for the limitations of a view oriented development philosophy. MVC is far from modern as it is not an evented model. Modern are platforms like Node.js and the RIA toolkits who eschew MVC in favor of an evented and message oriented architecture.

http://www.appcelerant.com/mvc_is_dead.html

http://apsblog.burtongroup.com/2007/11/mvc-matrix-and-.html

http://broadcast.oreilly.com/2008/10/mvc-as-anti-pattern.htm...

http://www.sitepoint.com/blogs/2005/12/22/mvc-and-web-apps-o...

[asnyder]

There doesn't need to be any additional complexity, if anything it can be simpler. I hate to constantly push NOLOH, but we've been doing this since 2005, and it works. It's been used by companies, and sites large and small, and no extra complexity necessary. If anything, it's significantly simpler than the normal web multi-tiered paradigm.

Sure, if you try to do this manually, it's complex, but if you use a tool like NOLOH, there are others, it becomes very simple, and even more natural than conventional web development.

It's so frustrating reading these comments as if the tools don't exist today. They do, and they have. Every year or so I'll read another post that re-hashes a small part of something that an existing framework, like NOLOH, does, and it'll be touted as the way forward.

We should be able use the tools that are available, there's no need to re-create the wheel every few months, or start over. If the cool kids in SV aren't using a tool, that doesn't mean that it doesn't exist. It simply means that the cool kids aren't using it. Likely because those cool kids like to re-create the wheel, over and over and over again.

Sorry for the rant. This sort of stuff gets very frustrating.

[prodigal_erik]

It doesn't appear that they simply reinvented what you did. Their approach works well without js, meanwhile NOLOH and the four "powered by" sites are mazes of mostly dead links and missing alt text (one site has nothing more than a blurb blaming the visitor for the author's neglect, which I wouldn't showcase).

[asnyder]

It's clear you didn't actually click on the sites in the powered by, but rather went completely on ShrinkTheWeb's out of date thumbnails. There is not a single dead link, and the image with the text is a reference to a server error, but clicking on the site goes to the live site.

There are 3 pages, with 9 live sites. There are many more, but not everybody decides to post their sites to the powered by section. We'll be starting a push to get NOLOH authors to post their sites there in the near future.

Furthermore, if you would've actually taken the time to read through our site, you would see that NOLOH does in fact render content without JS, if the developer chooses, which we're constantly improving. You can read our blog for more information.

It's somewhat shocking that this is what HN has come down to. Writing a reply without actually verifying your comment. I'm starting to think I don't belong here anymore, it's starting to feel like high school all over again.

[prodigal_erik]

I don't mean thumbnails. http://www.noloh.com/?poweredby/ shows me four sites and no way to navigate to more. If I follow the link to the last, http://www.diffpaste.com/, I see "Paste", "Diff", and "Latest Pastes" across the top and categories ranging from "PHP (67)" to "C++ (1)" down the right, none of which do anything at all. Likewise, http://www.noloh.com/ has several highlighted phrases and "Read More" divs which look like they were supposed to be links but don't go anywhere. Many other links all lead to http://dev.noloh.com/ rather than whichever page was intended, because the server can't see the path after the # sign. If you thought this stuff all worked without js, I'm sorry but I assure you much of it does not, so the happyworm.com crew seem to be onto something good.

[asnyder]

You're basing your assumptions on a broken premise. You're clearly not browsing normally, but rather are crippling your browser in some way, after which you decide to bash whatever you can, without clearly identifying your methods.

As I mentioned earlier it's at the developer's discretion as to whether they want to enable JS degradation or not. Sometimes when an application is sufficiently complex a developer may choose not to, or not have certain actions map to links.

You shouldn't base your assumptions on one implementation, but rather, read what the technology claims to do and then try it so you can actually see, rather than just slash and burn.

It's people like you that really make me wonder whether we should even continue down the standards based route, or continue to support text-based browsers, as mentioned in our latest blog posts http://dev.noloh.com/#/blog/, or http://dev.noloh.com/?/blog/ for you. Not a single client or user has ever asked for such features, but we always get complaints from the die-hards. So we work and implement it, to what effect? Next you'll complain that some app that uses NOLOH doesn't do XYZ. There's nothing we can do about that, we can't force users to upgrade, or implement a feature, we can only offer it.

Clearly it doesn't matter what we do, or how compatible we try to be, you won't care, won't listen, and won't actually try it.

[prodigal_erik]

Firefox 3.6.8 on Vista Home Premium x64 without js on. That's all.

If I were in the market for a web framework, I would not take it on faith that I could rely upon interoperability features the site claims but does not demonstrate. And I wouldn't write the demo myself unless I had already ruled out your competitors.

If you decide to drop it, I have no doubt you can still find a large potential market of developers either indifferent or ignorant about the ongoing disintegration of the open HTML web. It comes down to what kind of effect you're comfortable with having on the industry.