The Future of Web Apps - Single Page Applications
happyworm.com
happyworm.com
2007: I "single-paged" subsections of my application, with different PHP scripts on the backend.
2008: Consolidated the backend into a single API.
2009: Switched the backend to Rails for ORM functionality, and finished upgrading the client interface to a single page application.
2009: Switched the backend to Javascript (Rhino) to enable sharing of model validations and other code (even native object extensions) with the client.
2009: Got my application working completely offline using a local SQL database and replication manager, together with ApplicationCache. At first I used LocalStorage but soon hit storage and performance limits.
2009: Switched from Rhino to NodeJS. Much faster, cleaner APIs. Huge performance gains from V8 and non-blocking IO.
2010: Results of the above up at: https://szpil.com
Along the way I built up a framework for managing concatenation, client-side navigation, sessions, views, controllers, email etc. One significant advantage of building client-side only apps that replicate with the server is that they work offline by definition. Managing state on the client opens up incredible opportunities.
Indeed, we originally had this idea back in 2004 (pre-AJAX craze), which led to the creation of NOLOH (http://www.noloh.com), available to the public since 2009 (commercial since 2005, public beta in 2008).
NOLOH allows you to create your website/WebApp in a single tier and then NOLOH will output your application in a "single page". Furthermore, it takes care of bookmarking, back button, and rendering to search engines transparently to the developer. No additional pages necessary. It also handles all the client-server communication allowing your application to be consistently lightweight and on-demand.
It was very interesting reading this, as the beginning matches closely with certain portions of our original business plan. Ahh, nostalgia.
Disclaimer: I'm a co-founder of NOLOH
If you would be so kind, could you please tell us what sort of resources were you looking for, and where you were expecting to find them? Thanks.
The first point is "Develop in a single, object-oriented language." That's just buzz.
Line 2: "Stop worrying about HTML, JavaScript, AJAX, and Comet." More buzz. Everybody says I can stop worrying about these things, but I still don't believe you. Is it web based?
Line 3: "Deploy seamlessly across all browsers and operating systems." Great, so it is web based and does exactly what every other web page does. Still not sold.
Line 4: "Create lightweight, on-demand websites and WebApps" More buzz, I don't care yet.
Line 5: "Boost your productivity. Develop faster, with fewer resources." Everybody says this, still not sold, ready to leave the site.
Line 6: "Enjoy many other exciting features." Great. I'm all the way through the bullet list and I still don't have any real idea what this project does.
Finally, as I scan the small print, I see that it is PHP based and is optimized for web apps.
This seems like a good idea, but the site is not great for discovering that.
One of my favorite new project sites is for vows (http://vowsjs.org/). It has one sentence declaring the goal, two sentences with output showing typical usage, and a brief paragraph explaining the purpose. All of it looks good too, and the rest of the documentation is very complete. I'd take a page out of their book if I were you.
Line 3 in particular is meant to emphasize that you can deploy across all browsers and operating systems, this is in fact not what every web page does, as most web pages would normally require tinkering to work in various different browsers versions.
However, I do see your point. We're in the process of adding a functional code sample to an area of the home, however, it's very difficult to strike the balance to appeal to those that make the software decisions and hardcore developers. Something like vows is clearly targeted towards the hardcore, whereas we're attempting to target a broader range, which includes the hardcore developers.
It is difficult and definitely something we're trying to improve. We appreciate your honest feedback and will definitely take your advice into consideration for our next update. Thank You.
You should be able to answer this simple question: where do you want my eyes to go first? Right now, there's a few different headlines and buttons competing for my attention. When that happens, I often don't bother figuring out where I should look and give up.
I think you have the attitude that someone is already interested in what you've done. If that's true, then more information is better. You need to come at this from the perspective that most people won't care what you've done. You need to convince them you did something cool. Make sure that after five seconds of being on your site, they know what you think is most important.
Clearly, what's happening here is that the skeptical reader is dismissing them, and certainly not clicking to get more information when more information is available.
We'll definitely try to strike a fair balance in the updates ahead.
Imagine you came into a restaurant and asked, "What's today's special?" And the waiter replied, "It's the best meal you'll ever have. You will be sated. You'll experience savory tastes, with a hint of sweet and salt. This meal will solve all of your hunger problems."
"Yeah, but what is it?"
"Oh, it's steak."
Give us the meat, then sell us on it. Don't try to sell it before you tell us what it is.
That said, it is very possible, but it requires that you bend your design to fit the model.
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.
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.
>> 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?
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.
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).
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.
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...
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.
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.
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.
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.
The best way to determine if something lives up to its claims is to try it. You can't look at sites done in NOLOH and then expect them to have implemented or turned on every feature.
Furthermore, it's amazing that when our competitors 280north, or Sproutcore, or whatever else is "cool" posts something nobody complains that you HAVE to have js. No degradation options, no text-based browsers. Nobody complains that their sites aren't in their tool, or that they have significantly less resources than we do.
As soon as we post something there's usually somebody that steers the conversation to a different topic and then criticizes us for one reason or another. In this case you successfully diverted the conversation from "single page" websites into a conversation on js degradation, which in the case of NOLOH is really irrelevant to most users.
Search engines get a different version from the js, non-js versions, thus the non-js version is only for humans that specifically decide to turn off their js. Could it be better, yes, will it be better, yes, can we mandate it, no.
I thought it was fairly obvious that someone on a technical forum complaining about anchors not leading anywhere and hidden divs appearing on the page is using NoScript, or otherwise has javascript disabled.
>Rather, you just started to list things that seems like they weren't working.
Well, they weren't, were they?
> As soon as we post something there's usually somebody that steers the conversation to a different topic and then criticizes us for one reason or another.
Mm, kinda like how you complain about your competitors instead of addressing issues about your javascript degredation?
If you bring up your product as a solution, it seems reasonable to expect us to describe why it isn't.
We have this fantastic thing called threaded discussion. There is not a direction for a conversation, but many, as is evidenced by the deeply-threaded messages on most technical boards (think Slashdot, not Digg).
It's a fantastic little library that gives you the ability to add what I can only describe as 'rails-style' routes to your client side .js apps. It makes your single page apps much easier to write and has a good event-handling model too.
You end up with more responsive user interface but my feeling at this point is there is still a real cost of additional code complexity -- especially for larger apps.
https://developer.mozilla.org/en/DOM/Manipulating_the_browse...
I agree that GWT is not friendly to UI people who are used to writing their own markup. But I would argue that a good UX person should be concerned with how the user interacts with the application (not necessarily by writing HTML and CSS by hand, but by sketching out the design on paper or Illustrator), and a framework like GWT often makes it simple to build complex UIs that would be difficult/labor-intensive to create and maintain with a traditional web dev stack. A decent developer should be capable of taking mockups from a designer and building out the rounded corners and other pretty bits himself in CSS.
Everyone has their preferred toolsets and frameworks and of course they should use what they feel is most effective. Case in point: my shop uses very little GWT - my coworkers prefer different tools (and often so do I; GWT is overkill IMHO unless you're building something big).
But this is all not really relevant to my point:
I was talking more about how the linked-to blog post was kind of web-development-101 stuff that everyone already knows and somehow, sadly, still received many upvotes/comments. I only brought GWT into the mix because some guy wrote a blog post about listening for URL hash changes and is presenting it as the future of web development, while (using GWT as an example) people with PhDs have written an optimizing Java to Javascript compiler and engineered very good solutions to difficult client-side web development problems that completely trivialize something as basic as hash change history tokens.
Right now, I still tend to favor page based web applications with some client side code (Ajax, probably jQuery).
Sorry to punt to someone else's words here, but I think DHH summed it up pretty well, so I'll just give a link and a quote:
http://bigthink.com/ideas/21596
<excerpt>
Question: The trend now is towards client-side applications, but Rails deals primarily with server code. Does Rails need to evolve to keep up?
David Hansson: So Rails have actually been interested in the client side for a long time. When AJAX sort of first got its initial push, when it got its acronym, back in, I think, 2006, Rails was one of the first server-side frameworks that said, "This is going to be huge and we're going to do something about that." So we put a Java script library straight in the Rails distribution prototype and we built a bunch of helpers around that to make it easier to create AJAX applications with Rails. And today it's almost inconceivable that you'll build a new, modern web application that doesn't have some aspect of AJAX in it.
Now, some people go a lot further than just having some aspects of AJAX in it. Some people have their entire application in Java script and just use the back end as a data store for that. I don't find that development experience that pleasurable. I have come to tolerate Java script now that there are great libraries and frameworks like Prototype around it to sort of make it a little more pleasurable, but it's still no Ruby. Ruby is still my first love in terms of programming languages. And however much you paint up Java script, it's not going to beat that. Which is fine.
So, from the development side of things, I don't enjoy Java script programming nearly as much or in the same league as I enjoy Ruby programming. Okay, fine. On the client side of things, like is this better for the user? I think there's something special and appealing to me about the mix, the mix of how the web is discreet pages and you use hyperlinks to jump from place to place and AJAX is sort of sprinkled across to make certain common operations a little faster. I tend not to like very heavy, single-screen-based web applications. They can be fine for some things, but I think the Web has this unique category of applications that fit into that sort of middle ground between one screen, or mainly one-screen applications and static web pages. And that's an awesome sweet spot and I think it works incredibly well for a wide array of applications. And I wouldn't want them to be any different. There are certainly some people developing for the web who long for the days of the desktop application and finally see that now AJAX is bringing that back. Well, we've heard that story a lot of times. First it was Java that was going to do this, applets were going to bring back the desktop experience and we could get rid of this nasty HTML. Then it was Flash that would bring this forward. And now AJAX or anything else like that. There's been so many attempts to bring the desktop to the web, and none of them have succeeded in becoming the dominant approach to building web applications, and I think there's a good reason for that, because that's not what users want. Like that sweet spot in the middle is great and it's actually desirable on its own terms.
</excerpt>
For now, I'm pretty happy in that middle ground as well... though it will be interesting to see where this goes next.
i just love it when competitors hide their web sites behind 'romulan cloaking devices' that make their content invisible to search engines!
more traffic for me!
bwa ha ha ha ha ha!
That being said, if you follow google's rules as specified here - http://code.google.com/web/ajaxcrawling/docs/getting-started... , it will crawl your ajax pages, no problem.
Finally, please be a little civil. Thanks.
http://code.google.com/web/ajaxcrawling/docs/faq.html
All of the apps I am currently working on do not have a SEO or old browser requirement, but I have used this technique in the past.
As with AJAX, the typical philosophy is to design for elegant degradation -- plan the site, then build it to work without JS, then add in the "fancy" stuff.