41–49 of 49 posts
http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hyperte...
Point being, if your AJAX app is built in the typical fashion, it is very unlikely to be at all RESTful itself. It is however enjoying the many benefits of being built on top of a RESTful protocol (HTML), like running in any standard web browser without any pre-deployed client software.
No, they are not becoming irrelevant. Frameworks add significant value on the front end as well -- the easiest example is templating, which is a) not natively supported in HTML b) hard to fake with CSS/Javascript and c) virtually required for productivity, consistency, and maintainability. I suppose one could theoretically fake this by using a script to spit out static HTML served by Apache, but then the combination…
There are tools for templating with Javascript, for example https://github.com/jquery/jquery-tmpl I can imagine that's not so good for search engines.
No, they are not becoming irrelevant. Frameworks add significant value on the front end as well -- the easiest example is templating, which is a) not natively supported in HTML b) hard to fake with CSS/Javascript and c) virtually required for productivity, consistency, and maintainability. I suppose one could theoretically fake this by using a script to spit out static HTML served by Apache, but then the combination…
There are tools for templating with Javascript, for example https://github.com/jquery/jquery-tmpl I can imagine that's not so good for search engines.
Earlier quoted context omitted.
It's about moving the generation of HTML to the client. The concept of rendering the UI (using HTML) on the server was a step backward right from the beginning of the WWW. Servers are simply not needed to construct HTML. I predict within a few years everyone will agree that all server-side HTML template languages (PHP, eRuby, JSP, Django etc) are obsolete. There will be a great normalization of server-side frameworks…
The point I was trying to make was that on mobile devices where computing power and battery power is a limited resource, not only will it be running significantly more Javascript, but it would also have to render the view - effectively doubling the number of client-side tasks. If all the device had to do was consume HTML and render it, it would impact performance and battery life less. Also, if you build your entire…
Also, try phonegap or jquerymobile. Tons of functionality that is immediate and battery friendly.
You _can_ do this stuff badly, but that's not what we're talking about here.
Earlier quoted context omitted.
There are tools for templating with Javascript, for example https://github.com/jquery/jquery-tmpl I can imagine that's not so good for search engines.
What if I turned off Javascript?
It might be very tempting to just use a REST API and a JS client for your web application. With the _escaped_fragment_ technique, you can even get indexed by Google (I'm not sure whether the other search engines already do this, but Google still is good for 90% of my search referrals, so it's ok for me). The architecture is very clean. And you get a full third-party API "for free" instead of having to bolt it on afte…
It's quite easy to get lost in one big heap of application that's very hard to maintain A lot of the issues that you outlines can be dealt with by proper toolkit selection. It sounds to me that you have outgrown the jQuery (and other small rapid to develop in toolkits) and need something more robust. As it sits there are really only two players in the top end game and they are Ext and Dojo. Of the two I prefer Dojo f…
Earlier quoted context omitted.
It's quite easy to get lost in one big heap of application that's very hard to maintain A lot of the issues that you outlines can be dealt with by proper toolkit selection. It sounds to me that you have outgrown the jQuery (and other small rapid to develop in toolkits) and need something more robust. As it sits there are really only two players in the top end game and they are Ext and Dojo. Of the two I prefer Dojo f…
jQuery alone doesn't give you the structure you need to build HTML + CSS + JS "Fat Clients" but, these do: - http://documentcloud.github.com/backbone/ - http://code.quirkey.com/sammy/
This will mean that many applications will be able to stuff their JS (which will have to codify page-rendering policy), CSS, and static files on S3, and use the server just for authentication, authorization, activation, and data. My coding experience with Rails, ASP.Net, and PHP tells me that the most frustrating and error-prone part of using web frameworks is the templating language where you have client-side code and server-side code mixed in in the same source code file in three or four different languages (e.g. Ruby, JS, ERB, CSS).
Authentication is the big issue here, but don't all of the cool kids use OAuth, FB Connect, JanRain Engage or something like that these days? If so, then once you authenticate yourself to your applications via your identity provider, only a session token between a client and server is needed to authenticate per request. (Or you could use an additional challenge-response token to one-up the man-in-the-middle attackers).
The SEO side of this has some interesting possibilities. Of course, this technology will hurt the search engines, because your content will be much harder for them to index. Most folks will find it hard (at least initially) to use Google's prescribed tricks to make your AJAX page bot-friendly. On the other hand, it also means that your application gains some information asymmetry (because your content cannot be easily found and compared with similar content on the web), and you could use that to your financial advantage. The key here is to give the search engine enough static content as index-bait to get your site's name "out there" and on page 1 of the search engine rankings, but not so much that all of your valuable content is indexed and commoditized to the advantage of Google/Yahoo/Bing.