5 ms·
You don't need to involve the server in generating the UI at all. You can have a static index.html, that bootstraps a javascript environment from static js file
by Joeri 15y ago
You don't need to involve the server in generating the UI at all. You can have a static index.html, that bootstraps a javascript environment from static js files, whose first order of business is to contact a web service to fetch the initial content and configuration as JSON data. This makes all content static except that which is truly dynamic, which offers amazing CDN and caching possibilities. The JSON data can be cached in local storage, for easy offline support without constantly revving manifest files.
Once you get at that point, the dev experience starts to look a lot like traditional desktop client-server app development. Except desktop apps are built using components instead of templates, components that combine rendering and behavior into one encapsulated entity that you can treat like a black box. There's nothing preventing a web app from using that same architecture. In fact, ExtJS does just this.
But I don't think it stops there. I think we're going to get meta-configuration languages like mxml to send the layout of these components to the javascript environment, which will, essentially, mean that we're building another browser inside the browser. And so all software evolves until it can render a web page, including web apps.
- ntoshev 15y agoIf you do this, crawlers can't index your pages. Also your users see the page loaded blank and being gradually populated with content, which is not a good UX.
- maccman 15y agoYour first point is not correct. Crawlers can crawl JavaScript only websites using the Ajax crawling API: http://code.google.com/web/ajaxcrawling/docs/specification.html http://code.google.com/web/ajaxcrawling/docs/specification.h... Your second point has merit. However I'd counter it thus: * You can load a HTML page first, containing a representation of the end content, so you can avoid the flash * You can show some sort of loading indicator on page load. Users are usually fine with waiting for the initial page load - it's only subsequent interactions that need be fast. In other words, there's no reason why the page need be blank.
- sirn 15y agoHowever by using hashbang URLs, you have to keep that little snippet of JavaScript forever to maintain permalink even after the web has moved on to another solution. It's not a future-proof solution.
- mattmanser 15y agoI'm not sure what you mean by little snippets of javascript, a link is a link. If you change why couldn't you just 301 them to your new format? It's a trivial redirect that you're keeping for the g-juice.
- icebraining 15y agoThe part after an hashbang is not sent to the server, so you need client side code to load the content. This is because the # in an URL is supposed to be an identifier of a element in the page, not an actual resource.
- fooandbarify 15y agoHashbangs are only a stop-gap at this point - modern browsers ship with the HTML5 History API.
- csomar 15y agoNot true. If you are building such application: 1. You need to have a non-JavaScript version. That is your main page index.html is a full functioning page without JavaScript. When JavaScript is enabled, it turns the page into a Web App. 2. A simple loader will solve the problem. You might not be able to show the progress for the moment.
- tomjen3 15y agoWhy does he need to have a non-javascript version? There is (thankfully) no law which say that your service must be usable for people who turn javascript of.
- anjc 15y agoYeah, there's no law which says your website must be accessible...
- intranation 15y agoWorking with Javascript off != accessibility. Most screenreaders (the common face of accessibility technology) run on top of regular browsers, so your JS experience needs to be accessible too if you are legally mandated to (or even better if you care).
- anjc 15y agoIf javascript being off makes your site not work, or not viewable at least, then that's the very definition of not being accessible (i'm not limiting 'accessible' to only mean 'available to people with disabilities' like you appear to be) Edit: Graceful degradation should be a tenet of web development. Having no provision for a person who doesn't have javascript enabled seems bizarre to me, and being bullish about the requirement seems even more bizarre...maybe i'm just getting cranky with age or something.
- scarmig 15y ago
- BerislavLopac 15y agoIf it's a true application, with user interaction and everything (and not just a set of glorified Web pages), then the former is not an issue; you don't really want your "pages" to be indexed. And the latter is easily solved with a "loading" bar or any other of UI tools previously invented for the exact same purpose on the desktop.
- robmcm 15y agoRember this is an application, would a search engine want to crawl the innerds of photoshop or outlook, or a web page promoting them? Just because it's on the web doesn't mean it's a web site that wants to be searchable.
- hello_moto 15y agoIn most community-based, social-networking, the companies behind them do want more exposure. The more people who join, the more vibrant the community is. FYI.
- BerislavLopac 15y agoFunny thing is that we were building precisely that nearly ten years ago: https://bitbucket.org/BerislavLopac/waexplorer https://bitbucket.org/BerislavLopac/waexplorer :)
- robmcm 15y agoAnd what Flex and Flash developers have been building for 5 years ;)
- arethuza 15y ago"the dev experience starts to look a lot like traditional desktop client-server app development" I have been wondering if we might see the rise of a general purpose JSON/RESTful API that plays the same role for these kind of apps as general purpose database engines did for the old thick client model.
- sedev 15y agoOnce you get at that point, the dev experience starts to look a lot like traditional desktop client-server app development. ... with all the security/privacy problems that go with that, and then some.
- anjc 15y agoCan somebody tell me what the point is? How much of a saving are you getting by transferring json data+metadata versus what would normally be sent. I'm ignoring the extra time that would be required to implement and test it. And like you say, it starts to look like a traditional native app, so why not just create a native app, if you're working in a domain that requires...whatever benefit you're getting here. It seems like you're just trying to approach a similar appearance to the user, while simultaneously wrestling with lots of technologies that don't suit the idea (CSS for example).