9 ms·

This is what I tell potential customers that are evaluating our product that creates single-page web applications where the JS dynamically creates all content:

This is what I tell potential customers that are evaluating our product that creates single-page web applications where the JS dynamically creates all content: if you want search engines to crawl the content, then you're not using the right product. It's a surprisingly easy decision when viewed in those terms. Most SAAS products that likely would be implemented as SPAs do not care about public search engine access, and are only used by B2B customers where you can dictate a certain minimum standard in terms of browser versions (IE). Everything else should be a traditional static web site with "decorative" JS, or "progressive enhancement".

todd3834 11y ago
Universal applications get the best of both worlds. That is why we created GlueStick https://github.com/TrueCar/gluestick/ https://github.com/TrueCar/gluestick/
bphogan 11y ago
Can't upvote hard enough. Applications on the web are amazing, and developers must embrace JavaScript heavily. That said, the apps do need to remain accessible to those with screen readers, vision issues, motor impairments, and cognitive issues. They need to be accessible to those with slow or spotty connections. But search engine optimization is about content sites, not necessarily apps. Static pages are perfect for those cases, and I am thrilled to see more people coming around to that.
- pikzen 11y ago
  >Can't upvote hard enough. Applications on the web are amazing, and developers must embrace JavaScript heavily. So how's it going in JS land, are you guys still reimplementing Windows 3.1's message passing loop and hailing it as a revolution ? :^) Or maybe you're still busy pulling in literally 10+MBs of code on top of a 100+MB browser to fix the shortcomings of what is a terrible language ? Or maybe you're busy trying to get performances that matches what a 68060 could do thirty years ago. Oh right, browser vendors had to agree on WASM to get OK performance. So basically, not Javascript. But hey, I guess it's crossplatform. Kind of. But promised, once transpilers are good enough, once I can use a good, strongly staticly typed language, once the APIs are stable and the tooling becomes tolerable, I'll join the SPA side.
  - Dr_tldr 11y ago
    So what you're saying is you don't know very much about JavaScript but you're willing to learn some once it becomes obsolete like Java?
    - pikzen 11y ago
      Stable and field tested, with a majority of the marketshare, as opposed to using the flavour of the day because that's what's hip? Where do I sign up ? I mean, I do C# day to day, so boring is perfect :) Also, much to my dismay, I do try things outs, maybe not extensively, but enough, before criticizing them. I've used Angular, React, Ember, JQuery (yes, working on a 100% jquery SPA. It's as fun as you can imagine), then other things like Vue.js, Knockout, and quite a few more. Even Vanilla JS. So, while I will not pretend to be an expert, or even having advanced knowledge of Javascript, I'd like to think I kind of know what I'm talking about.
      - Dr_tldr 11y ago
        That's good to know, and I promise I wasn't (just) being snarky! The problem is that unless you're working with something low-level like C, by the time it's stable and field tested, the language has also gotten kind of brittle, there's a mountain of bad code, and new features don't undo the damage done by the bad patterns of the past. Javascript also has mountains of bad code and bad practices, but a lot of it's being accumulated in frameworks which are getting created, tested, found wanting, then dropped, with the good parts surviving on, either in new frameworks or as part of the standard. I won't lie though, I'm as framework exhausted as everyone else right now and it can't go on like this for much longer. Using something like C# (which I see as "good Java") would be a nice change of pace. Definitely check out Ampersand and Webpack with React, they're kind of coalescing to provide a saner, "use only what you need" approach.
  - bphogan 11y ago
    I agree with all of those points. But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. So what are ya gonna do? See, I hate JS. I think it's terrible. If there were any other choices out there, I don't even think it would still be a thing if there were any other options. But it's a requirement of a modern web developer to know how to do it well. And I'm a web developer. So I'm going to be good at it. At least as good as I can be given the tools I use and constraints I have.
enraged_camel 11y ago
Why does it have to be one or the other, though? You can have static, pre-rendered landing pages for search engines to crawl and index, and your actual application can be an SPA. Right?
- Klathmon 11y ago
  I had always assumed this was just the norm. The vast majority of applications don't need to be searchable, the website that shows off the app does.
- TimJYoung 11y ago
  Absolutely. In our case, it's a non-fit because of the client-side content generation via JS (our apps are more akin to desktop/mobile apps with a monolithic JS app). But, if you already generate most of the HTML/CSS from the back-end and just sprinkle in some JS here and there, then you can certainly do a hybrid approach, like you suggest.
onion2k 11y ago
Google can and does crawl Javascript driven web apps. Last year they even deprecated the AJAX crawling scheme that they used to recommend on the basis that they can now crawl web apps: https://googlewebmastercentral.blogspot.co.uk/2015/10/deprecating-our-ajax-crawling-scheme.html https://googlewebmastercentral.blogspot.co.uk/2015/10/deprec...
- TimJYoung 11y ago
  Yes, but in the case of SAAS apps, what exactly are they crawling (if allowed) ? In our case, it would be a bunch of edit controls, grids, buttons, containers, etc. that don't really make a whole lot of sense in the context of a search engine. I think it's important to start recognizing that there's two distinct types of web "applications" starting to emerge: the more traditional kind of "application" that is actually more like a web site, and the newer kind of application that is more like an actual application (desktop/mobile). Edit: Just read the new guidelines, and they are now considering serving up different content for the crawler as being "against the rules". So that probably cements the idea that you shouldn't allow Google to crawl anything that's mostly content-free and just an "app".
  - onion2k 11y ago
    "Don't let Google crawl your site if it's not appropriate" is great advice, that's true, but it has nothing to do with whether you're serving up JS or HTML.
    - TimJYoung 11y ago
      Yeah, I'm conflating the two, based upon my personal experiences. But, are people really writing applications that generate all content completely on the client side via JS, but want the end result to be more like a traditional web site ? That seems weird, even to me. :-)
      - bphogan 11y ago
        Tons of news sites are doing exactly this. I can't tell you how many times I follow a link from Facebook or other social media, only to be brought to a page where a spinning gif spins for several seconds while JS loads the article.
Wintamute 11y ago
The "holy grail" architecture whereby the first request sends a fully formed HTML response which is then immediately hydrated with a JS frontend app that takes over routing and data gathering is now pretty technically feasible. It's the best of all worlds ... fast static content for the first load, and then fast frontend routing thereafter. If you ward your clients away from this path you're doing them a disservice. With this stack JS web apps no longer need to be app-like, they're well suited to content-heavy sites too. They even work with JS turned off :)
- madeofpalk 11y ago
  > pretty technically feasible Not only feasible, it's extremely easy to do these days with things like React (+Redux). We're about to launch a fairly large project for an Australian broadcaster using this approach and it's been incredibly simple to do. And there's nothing ~magic~ that React does to make this possible - it would be quite trivial to 'roll your own' framework for this. Best of all, you could start with doing it just server-side and then roll out the JS to 'the other side' later on.
  - sotojuan 11y ago
    Seems like Ember is working towards this: https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot
  - terda12 11y ago
    Yeah, the cool thing about React is that its fairly pluggable. So stuff like server side rendering is not "React" specific but more so Node specific.
- terda12 11y ago
  Seems like its what Redux/React is doing at the moment with server side rendering http://rackt.org/redux/docs/recipes/ServerRendering.html http://rackt.org/redux/docs/recipes/ServerRendering.html On server request, render the first snapshot of a React app into pure HTML and send it out, and then that HTML snapshot uses a script tag to get the actual JS file of the react app.

todd3834 11y ago

Universal applications get the best of both worlds. That is why we created GlueStick https://github.com/TrueCar/gluestick/ https://github.com/TrueCar/gluestick/

bphogan 11y ago

Can't upvote hard enough. Applications on the web are amazing, and developers must embrace JavaScript heavily. That said, the apps do need to remain accessible to those with screen readers, vision issues, motor impairments, and cognitive issues. They need to be accessible to those with slow or spotty connections. But search engine optimization is about content sites, not necessarily apps. Static pages are perfect for those cases, and I am thrilled to see more people coming around to that.

pikzen 11y ago
>Can't upvote hard enough. Applications on the web are amazing, and developers must embrace JavaScript heavily. So how's it going in JS land, are you guys still reimplementing Windows 3.1's message passing loop and hailing it as a revolution ? :^) Or maybe you're still busy pulling in literally 10+MBs of code on top of a 100+MB browser to fix the shortcomings of what is a terrible language ? Or maybe you're busy trying to get performances that matches what a 68060 could do thirty years ago. Oh right, browser vendors had to agree on WASM to get OK performance. So basically, not Javascript. But hey, I guess it's crossplatform. Kind of. But promised, once transpilers are good enough, once I can use a good, strongly staticly typed language, once the APIs are stable and the tooling becomes tolerable, I'll join the SPA side.
- Dr_tldr 11y ago
  So what you're saying is you don't know very much about JavaScript but you're willing to learn some once it becomes obsolete like Java?
  - pikzen 11y ago
    Stable and field tested, with a majority of the marketshare, as opposed to using the flavour of the day because that's what's hip? Where do I sign up ? I mean, I do C# day to day, so boring is perfect :) Also, much to my dismay, I do try things outs, maybe not extensively, but enough, before criticizing them. I've used Angular, React, Ember, JQuery (yes, working on a 100% jquery SPA. It's as fun as you can imagine), then other things like Vue.js, Knockout, and quite a few more. Even Vanilla JS. So, while I will not pretend to be an expert, or even having advanced knowledge of Javascript, I'd like to think I kind of know what I'm talking about.
    - Dr_tldr 11y ago
      That's good to know, and I promise I wasn't (just) being snarky! The problem is that unless you're working with something low-level like C, by the time it's stable and field tested, the language has also gotten kind of brittle, there's a mountain of bad code, and new features don't undo the damage done by the bad patterns of the past. Javascript also has mountains of bad code and bad practices, but a lot of it's being accumulated in frameworks which are getting created, tested, found wanting, then dropped, with the good parts surviving on, either in new frameworks or as part of the standard. I won't lie though, I'm as framework exhausted as everyone else right now and it can't go on like this for much longer. Using something like C# (which I see as "good Java") would be a nice change of pace. Definitely check out Ampersand and Webpack with React, they're kind of coalescing to provide a saner, "use only what you need" approach.
- bphogan 11y ago
  I agree with all of those points. But meeting the needs of customers is what I get paid to do. And customers don't want server-side rendered stuff. They hate losing their place when they add a row of data. So what are ya gonna do? See, I hate JS. I think it's terrible. If there were any other choices out there, I don't even think it would still be a thing if there were any other options. But it's a requirement of a modern web developer to know how to do it well. And I'm a web developer. So I'm going to be good at it. At least as good as I can be given the tools I use and constraints I have.

enraged_camel 11y ago

Why does it have to be one or the other, though? You can have static, pre-rendered landing pages for search engines to crawl and index, and your actual application can be an SPA. Right?

Klathmon 11y ago
I had always assumed this was just the norm. The vast majority of applications don't need to be searchable, the website that shows off the app does.
TimJYoung 11y ago
Absolutely. In our case, it's a non-fit because of the client-side content generation via JS (our apps are more akin to desktop/mobile apps with a monolithic JS app). But, if you already generate most of the HTML/CSS from the back-end and just sprinkle in some JS here and there, then you can certainly do a hybrid approach, like you suggest.

onion2k 11y ago

Google can and does crawl Javascript driven web apps. Last year they even deprecated the AJAX crawling scheme that they used to recommend on the basis that they can now crawl web apps: https://googlewebmastercentral.blogspot.co.uk/2015/10/deprecating-our-ajax-crawling-scheme.html https://googlewebmastercentral.blogspot.co.uk/2015/10/deprec...

TimJYoung 11y ago
Yes, but in the case of SAAS apps, what exactly are they crawling (if allowed) ? In our case, it would be a bunch of edit controls, grids, buttons, containers, etc. that don't really make a whole lot of sense in the context of a search engine. I think it's important to start recognizing that there's two distinct types of web "applications" starting to emerge: the more traditional kind of "application" that is actually more like a web site, and the newer kind of application that is more like an actual application (desktop/mobile). Edit: Just read the new guidelines, and they are now considering serving up different content for the crawler as being "against the rules". So that probably cements the idea that you shouldn't allow Google to crawl anything that's mostly content-free and just an "app".
- onion2k 11y ago
  "Don't let Google crawl your site if it's not appropriate" is great advice, that's true, but it has nothing to do with whether you're serving up JS or HTML.
  - TimJYoung 11y ago
    Yeah, I'm conflating the two, based upon my personal experiences. But, are people really writing applications that generate all content completely on the client side via JS, but want the end result to be more like a traditional web site ? That seems weird, even to me. :-)
    - bphogan 11y ago
      Tons of news sites are doing exactly this. I can't tell you how many times I follow a link from Facebook or other social media, only to be brought to a page where a spinning gif spins for several seconds while JS loads the article.

Wintamute 11y ago

The "holy grail" architecture whereby the first request sends a fully formed HTML response which is then immediately hydrated with a JS frontend app that takes over routing and data gathering is now pretty technically feasible. It's the best of all worlds ... fast static content for the first load, and then fast frontend routing thereafter. If you ward your clients away from this path you're doing them a disservice. With this stack JS web apps no longer need to be app-like, they're well suited to content-heavy sites too. They even work with JS turned off :)

madeofpalk 11y ago
> pretty technically feasible Not only feasible, it's extremely easy to do these days with things like React (+Redux). We're about to launch a fairly large project for an Australian broadcaster using this approach and it's been incredibly simple to do. And there's nothing ~magic~ that React does to make this possible - it would be quite trivial to 'roll your own' framework for this. Best of all, you could start with doing it just server-side and then roll out the JS to 'the other side' later on.
- sotojuan 11y ago
  Seems like Ember is working towards this: https://github.com/tildeio/ember-cli-fastboot https://github.com/tildeio/ember-cli-fastboot
- terda12 11y ago
  Yeah, the cool thing about React is that its fairly pluggable. So stuff like server side rendering is not "React" specific but more so Node specific.
terda12 11y ago
Seems like its what Redux/React is doing at the moment with server side rendering http://rackt.org/redux/docs/recipes/ServerRendering.html http://rackt.org/redux/docs/recipes/ServerRendering.html On server request, render the first snapshot of a React app into pure HTML and send it out, and then that HTML snapshot uses a script tag to get the actual JS file of the react app.