4 ms·

Another con: Unless you want to build three applications, going the JS-only route also means that your site is now only accessible for people with JS enabled.

by pilif 15y ago

Another con: Unless you want to build three applications, going the JS-only route also means that your site is now only accessible for people with JS enabled. We've seen how well such sites are received when HN was dominated by blogs ranting about the new Gawker design. So to fix this, you'd have to do three applications: 1) the API that you use in the JS GUI 2) The JS GUI 3) The dynamically generated HTML for JS-less browsers Or you change the JS GUI so it requests page fragments and work with history.pushState (PJAX) allowing you to skip the API again, though, of course, then you don't have an API. I've reasoned about this last april: http://pilif.github.com/2011/04/ajax-architecture-frameworks-and-hacks/ http://pilif.github.com/2011/04/ajax-architecture-frameworks...

prateekdayal 15y ago
Valid point. I should have noted in the article that in our case, we assume our clients to have javascript enabled. As a startup, you have to be willing to let go of some customers to provide a compelling experience to others.
- keeperofdakeys 15y ago
  Personally I think it depends on the scale. As soon as you have actions that can't easily be implemented in server side code or have a large divergence in possible behaviour for clients, you can say "you need javascript to view this" (pretty much, when it can be called an application). I find the 'javascript to enhance' guideline helpful to. Then sites are more likely to be functional (but not pretty) in older browsers. A good example is javascript to make menus slide, but which use CSS to make them come up.
- pilif 15y ago
  I totally agree with you. Even as a not-so-startup any more (we've been around for 11 years now). It really depends on the type of your customers: If you are selling a specific app to them, you might more easily get away with JS only than if you are producing a page for general consumption. But, of course, if you go the JS only route (which I have done for my tempalias.com fun project last year), then you also have to keep in mind that you will be duplicating model code and dealing with two separate ORM layers: One on the server for the API itself and one on the client which gets used by the GUI controllers. Backbone can be of help there, but if you want to, say, do some validation logic already on the client without the roundtrip, then you begin duplicating logic on both server and client. So how ever you put it, going JS only is probably more work in the end, but it's also less work than going the traditional way and then bolting on a fully-fledged API because the lack of dogfooding it will cause you trouble once you get real users for it. Overall it's a really difficult decision to make and it's also quite final as changing the direction, again, means a lot of work.
- deleted 15y ago
  [deleted]
locci 15y ago
This is one of the reasons javascript should be used both on the server and the client. The server would offload as many procedures to the client as possible (that is none if js is disabled, some if you don't want to expose your guts). The server html renderers would be the exact same code in the client, the api would be a simple thin wrapper around your "protected" procedures. You could event support ecmascript5 features on IE6, executing the js in the server.

by pilif 15y ago

prateekdayal 15y ago

Valid point. I should have noted in the article that in our case, we assume our clients to have javascript enabled. As a startup, you have to be willing to let go of some customers to provide a compelling experience to others.

keeperofdakeys 15y ago
Personally I think it depends on the scale. As soon as you have actions that can't easily be implemented in server side code or have a large divergence in possible behaviour for clients, you can say "you need javascript to view this" (pretty much, when it can be called an application). I find the 'javascript to enhance' guideline helpful to. Then sites are more likely to be functional (but not pretty) in older browsers. A good example is javascript to make menus slide, but which use CSS to make them come up.
pilif 15y ago
I totally agree with you. Even as a not-so-startup any more (we've been around for 11 years now). It really depends on the type of your customers: If you are selling a specific app to them, you might more easily get away with JS only than if you are producing a page for general consumption. But, of course, if you go the JS only route (which I have done for my tempalias.com fun project last year), then you also have to keep in mind that you will be duplicating model code and dealing with two separate ORM layers: One on the server for the API itself and one on the client which gets used by the GUI controllers. Backbone can be of help there, but if you want to, say, do some validation logic already on the client without the roundtrip, then you begin duplicating logic on both server and client. So how ever you put it, going JS only is probably more work in the end, but it's also less work than going the traditional way and then bolting on a fully-fledged API because the lack of dogfooding it will cause you trouble once you get real users for it. Overall it's a really difficult decision to make and it's also quite final as changing the direction, again, means a lot of work.
deleted 15y ago
[deleted]

locci 15y ago

This is one of the reasons javascript should be used both on the server and the client. The server would offload as many procedures to the client as possible (that is none if js is disabled, some if you don't want to expose your guts). The server html renderers would be the exact same code in the client, the api would be a simple thin wrapper around your "protected" procedures. You could event support ecmascript5 features on IE6, executing the js in the server.