9 ms·

The Future of Web Apps - Single Page Applications

58 points by fr0ggerz 16y ago

asnyder 16y ago
Originally posted in blog comment: Indeed, we originally had this idea back in 2004 (pre-AJAX craze), which led to the creation of NOLOH (http://www.noloh.com 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
- thasmin 16y ago
  NOLOH's tutorials are hard to find on that web site.
  - asnyder 16y ago
    I'm sorry it was difficult for you to find the necessary resources. On the home there's a link to a series of around 20 YouTube videos, a developer zone with 30 extensive articles, a full and in-sync API reference, and a growing Demo section. You can also sign-up for a free hosted sandbox where you can get started right away, without the need to download or host anything yourself. 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.
    - jmtulloss 16y ago
      When I clicked on the link, I almost clicked off before seeing what language this was even targeted at. 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/ 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.
      - asnyder 16y ago
        Thanks for the feedback. We do have that huge header that says "Build for the Web Faster & Easier!", thus we would hope you immediately conclude it's web based. For most of those points above, the keywords are actually links to more information for each of those points. 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.
        csomar 16y ago
        Please read http://www.alistapart.com/articles/writingcontentthatworksforaliving/ http://www.alistapart.com/articles/writingcontentthatworksfo... and may be you'll change your opinion about how web copies should be.
        scott_s 16y ago
        It's way too much. Complete overload. And, unfortunately, as the parent poster mentioned, despite there being a wall o' text, there's not much actual information. 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.
        16y ago
    - thasmin 16y ago
      Even when I was looking around, I could see that there were a lot of resources. I'd like to see a very short app - 50 lines of code - that shows off the main feature of the framework. More importantly, I need this to be one of the links on the top of the page if it's not on the home page.
tjarratt 16y ago
I've been following a very similar approach, writing a web app for an upcoming launch. The hardest part is keeping everything in your head. When you have a cache on the client, a cache on the backend, several databases, throw in some ajax requests and command line scripts, it becomes very difficult to sanely architect a web app in one page. That said, it is very possible, but it requires that you bend your design to fit the model.
- warfangle 16y ago
  I believe there is a firm need now (and will become more urgent as time goes on) for a solid framework that can deliver single-page off-line-accessible apps. Somehow, I think Node.js would be the perfect platform for it.
terra_t 16y ago
love it love it love it love it love it 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!
- antichaos 16y ago
  Did you read the article? The single-page web app degrades to linked pages when JavaScript is disabled, and it's fully indexable by search engines.
  - kls 16y ago
    It's actually simpler than that now days, you simple set up a server with a headless web browser on it and route all old-browser and crawlers to that box. They get the same functionality but with-in a page post model. There are a few architectural adherence but for the most part it works pretty well.
    - simonw 16y ago
      That's simple? Do you know of any sites that actually do that?
      - kls 16y ago
        Here is the Google page on the subject: http://code.google.com/web/ajaxcrawling/docs/faq.html 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.
    - maushu 16y ago
      I always wondered about this, how does Google prevent this type of behavior? Like serving specific content to search engines and show other content to users... do they check using camouflaged bots?
chopsueyar 16y ago
http://npination.com http://npination.com
bandhunt 16y ago
You can see an example of this using the sweet happyworm player here: http://www.isound.com http://www.isound.com
ufomuffin 16y ago
Yes! i love where this is going
adriand 16y ago
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.
- asnyder 16y ago
  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 16y ago
    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).
dstein 16y ago
Combine this idea with the pushState() API and you've got your 100% ajax website. https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history https://developer.mozilla.org/en/DOM/Manipulating_the_browse...
kablamo 16y ago
I agree that this is probably the future of web apps. I think this approach is becoming more and more common and the trend will continue as tools and libraries and languages improve. 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.
revetkn 16y ago
GWT's been around for years now - I wish more people were aware of it and just how powerful it is :(
- kls 16y ago
  I think server frameworks like GWT and Echo take the wrong tack, they favor the developer to the detriment of the designer. I think the JavaScript toolkits have it right by separating the concern of the UI away from the back end and placing it squarely in the hands of the designer and UX developer. It is a different discipline and given the historic nature of web development, server toolkits either favored the developer (Java) or the designer (PHP) and made sacrifices to the opposing discipline. Removing the UI from the server all together provides the best of both worlds for all parties involved. Even if you are a lone gunman freelance.
  - lapusta 16y ago
    GWT is not a server framework.
    - kls 16y ago
      Last I checked you write Java, and it generates the UI and the services. It is a server framework because the same tool is responsible for the development server side and the client side, it is an evolution from stuts or JSF, but in the end you are developing the UI from a backend developers perspective. I know that it generates client side code and that it uses the familiar JS client model. But it is still designed for the comfort of the backend developer. Quit honestly GWT et. al. further alienate the designer in favor of the developer.
  - revetkn 16y ago
    I mentioned GWT because the linked blog post discusses some of the first baby steps toward the idea of building a real single-page client-side app, whereas GWT has been doing some real heavy lifting in that space for a long time...I'm a little disappointed that the post received so many upvotes, since it seems like using the URL hash to preserve state on-page should be common knowledge for any web developer. 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.
deleted 16y ago
[deleted]
jorangreef 16y ago
I have been working through these ideas since 2007, taking it one step at a time: 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 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.
jdee 16y ago
A conversation about single page apps would not be complete without mentioning Sammy.JS http://code.quirkey.com/sammy/ http://code.quirkey.com/sammy/ 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.
HNer 16y ago
Hmm SEO with a single title tag which does not change according to the page is hardly 'seo'
geebee 16y ago
This was an interesting article, and I'm still digesting it. 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 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.

58 points by fr0ggerz 16y ago

Originally posted in blog comment: Indeed, we originally had this idea back in 2004 (pre-AJAX craze), which led to the creation of NOLOH (http://www.noloh.com 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

thasmin 16y ago
NOLOH's tutorials are hard to find on that web site.
- asnyder 16y ago
  I'm sorry it was difficult for you to find the necessary resources. On the home there's a link to a series of around 20 YouTube videos, a developer zone with 30 extensive articles, a full and in-sync API reference, and a growing Demo section. You can also sign-up for a free hosted sandbox where you can get started right away, without the need to download or host anything yourself. 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.
  - jmtulloss 16y ago
    When I clicked on the link, I almost clicked off before seeing what language this was even targeted at. 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/ 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.
    - asnyder 16y ago
      Thanks for the feedback. We do have that huge header that says "Build for the Web Faster & Easier!", thus we would hope you immediately conclude it's web based. For most of those points above, the keywords are actually links to more information for each of those points. 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.
      - csomar 16y ago
        Please read http://www.alistapart.com/articles/writingcontentthatworksforaliving/ http://www.alistapart.com/articles/writingcontentthatworksfo... and may be you'll change your opinion about how web copies should be.
      - scott_s 16y ago
        It's way too much. Complete overload. And, unfortunately, as the parent poster mentioned, despite there being a wall o' text, there's not much actual information. 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.
        16y ago
  - thasmin 16y ago
    Even when I was looking around, I could see that there were a lot of resources. I'd like to see a very short app - 50 lines of code - that shows off the main feature of the framework. More importantly, I need this to be one of the links on the top of the page if it's not on the home page.

tjarratt 16y ago

I've been following a very similar approach, writing a web app for an upcoming launch. The hardest part is keeping everything in your head. When you have a cache on the client, a cache on the backend, several databases, throw in some ajax requests and command line scripts, it becomes very difficult to sanely architect a web app in one page. That said, it is very possible, but it requires that you bend your design to fit the model.

warfangle 16y ago
I believe there is a firm need now (and will become more urgent as time goes on) for a solid framework that can deliver single-page off-line-accessible apps. Somehow, I think Node.js would be the perfect platform for it.

terra_t 16y ago

love it love it love it love it love it 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!

antichaos 16y ago
Did you read the article? The single-page web app degrades to linked pages when JavaScript is disabled, and it's fully indexable by search engines.
- kls 16y ago
  It's actually simpler than that now days, you simple set up a server with a headless web browser on it and route all old-browser and crawlers to that box. They get the same functionality but with-in a page post model. There are a few architectural adherence but for the most part it works pretty well.
  - simonw 16y ago
    That's simple? Do you know of any sites that actually do that?
    - kls 16y ago
      Here is the Google page on the subject: http://code.google.com/web/ajaxcrawling/docs/faq.html 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.
  - maushu 16y ago
    I always wondered about this, how does Google prevent this type of behavior? Like serving specific content to search engines and show other content to users... do they check using camouflaged bots?

chopsueyar 16y ago

http://npination.com http://npination.com

bandhunt 16y ago

You can see an example of this using the sweet happyworm player here: http://www.isound.com http://www.isound.com

ufomuffin 16y ago

Yes! i love where this is going

adriand 16y ago

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.

asnyder 16y ago
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 16y ago
  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).

dstein 16y ago

Combine this idea with the pushState() API and you've got your 100% ajax website. https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history https://developer.mozilla.org/en/DOM/Manipulating_the_browse...

kablamo 16y ago

I agree that this is probably the future of web apps. I think this approach is becoming more and more common and the trend will continue as tools and libraries and languages improve. 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.

revetkn 16y ago

GWT's been around for years now - I wish more people were aware of it and just how powerful it is :(

kls 16y ago
I think server frameworks like GWT and Echo take the wrong tack, they favor the developer to the detriment of the designer. I think the JavaScript toolkits have it right by separating the concern of the UI away from the back end and placing it squarely in the hands of the designer and UX developer. It is a different discipline and given the historic nature of web development, server toolkits either favored the developer (Java) or the designer (PHP) and made sacrifices to the opposing discipline. Removing the UI from the server all together provides the best of both worlds for all parties involved. Even if you are a lone gunman freelance.
- lapusta 16y ago
  GWT is not a server framework.
  - kls 16y ago
    Last I checked you write Java, and it generates the UI and the services. It is a server framework because the same tool is responsible for the development server side and the client side, it is an evolution from stuts or JSF, but in the end you are developing the UI from a backend developers perspective. I know that it generates client side code and that it uses the familiar JS client model. But it is still designed for the comfort of the backend developer. Quit honestly GWT et. al. further alienate the designer in favor of the developer.
- revetkn 16y ago
  I mentioned GWT because the linked blog post discusses some of the first baby steps toward the idea of building a real single-page client-side app, whereas GWT has been doing some real heavy lifting in that space for a long time...I'm a little disappointed that the post received so many upvotes, since it seems like using the URL hash to preserve state on-page should be common knowledge for any web developer. 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.

deleted 16y ago

[deleted]

jorangreef 16y ago

I have been working through these ideas since 2007, taking it one step at a time: 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 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.

jdee 16y ago

A conversation about single page apps would not be complete without mentioning Sammy.JS http://code.quirkey.com/sammy/ http://code.quirkey.com/sammy/ 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.

HNer 16y ago

Hmm SEO with a single title tag which does not change according to the page is hardly 'seo'

geebee 16y ago

This was an interesting article, and I'm still digesting it. 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 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.