Modern Web Applications are Here
lucumr.pocoo.org
lucumr.pocoo.org
This is what web applications are now and will be. The user experience can not be compared to the old style of application. If you are still building applications today that are GET, fetch, pause, render, etc. then you are years behind. It is awesome being able to click on a link to a 10-page forum thread or blog comment page and have it render in ~100ms.
I think all of the web server frameworks will have to adapt - from RoR to Django etc. since a lot of what they do is being moved to the client (and it becomes even cheaper to run large-scale web services because of this). There are also tons of gaps on the client side - from more capable and cachable templating engine through to a full-stack framework (something like RoR for Javascript but less confusing and hard to use than the current)
The server now is just db+REST, auth and pubsub - soon enough somebody will release a generic PaaS that does all this based on a schema. Almost no more, or very little, server-side code (unless you insist on supporting old HTML clients).
You might be doing that already, but the article mentions (if I got that right) that if you GET an arbitrary URL, the server will still serve the whole rendered page - asynchronous loading only happen on any subsequent requests.
This way, you don't "break" URLs, pleasing search engine crawlers and allowing copy/paste of the links, and still delivering a great experience for the user.
I truly believe there is a big demand for a Node.js framework to facilitate this. There are already a few that allows this kind of architecture (to some degree), but none are quite "there" yet.
the decision to be made there is do you want to load all the objects (models, views etc.) or have an init where it is all either loaded async or from the localstore cache. I went with the later so that the html page can be static cached.
this has taken me a while because there was a lot of js to write - for eg. a sync replacement that uses localCache and the server smartly, that responds in async with 'ok' so the view can be updated rather than waiting on the server, and then triggering server updates every x seconds or when the user closes the window (this all has to be cross-browser, which is the hardest part)
a node.js framework that does all this would be great, while I am using Python atm I think these types of apps are very well suited to run on node.
https://github.com/Morriz/backbone-everywhere https://github.com/developmentseed/bones
https://github.com/jordow/FaxJs
The gist is that you just write standard declarative ui structures in pure javascript and the system disassembles the markup on the server, and reassembles it on the client with all the events still in tact. You wouldn't know all that is happening just by looking, though.
...
var twoDivs = {
className: 'outerDiv',
onClick: this.outerDivClicked,
innerDiv: {
className: 'innerDiv',
content: 'inner-most-div!'
}.Div()
}.Div();
How do you feel about derby? (http://github.com/codeparty/derby)
Not that I know of any yet.
If you don't need any custom logic at all, you can easily use JSON to pass that object between client and server with no further changes. If you do need some custom logic, it'd be slightly more work, but then again you could just opt to use javascript for any small pieces of logic, as there are V8 and/or Spidermonkey wrappers for most or all of the languages supported by Mustache.
So I don't know what a 10-page forum has to do with it. I can render a 10-page forum in ~100ms without Javascript. It all depends on server-time and layout-data.
Maybe you should tell PG this site is years behind ;)
Most of us are too concerned (or straight up scared) of the JavaScript/HTML5 revolution that we can't see what is possible right now. Sharing templates server and client side is a magic bullet that everyone should be using.
Web applications are only going to get faster, and if you want to keep up, you're going to have to do implement modern solutions like Battlelog and Google+ do.
I can envision a time when full page refreshes are the exception and that isn't a bad thing.
Agreed. Different clients should get different views. I don't think we're that far off from having to support the js-light "web crawler" view, although we already have the tools to make this really easy.
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.
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.
It's not a future-proof solution.
This is because the # in an URL is supposed to be an identifier of a element in the page, not an actual resource.
IE 9 comes close, and can be considered modern.
And while people can build crawlers that can fetch Javascript rendered pages, these scripts will have to drive real browsers with rendering engines, not just simple HTTP clients. And this is a problem, because fetching millions of web pages will require serious infrastructure work, versus a crawler using libev that can fetch dozens of pages in parallel without a sweat.
Also, that spec you gave is not exactly how Google operates. That's the advice Google gives for making web apps compliant, but the reality is that Google is smarter than that and it takes Google a good amount of effort to fix other people's screwups.
Accessible to crawlers doesn't mean Google-only and you should be careful not to throw the baby along with the bathwater.
Also, if search engine referrals is all you're interested in, if Google drops you from their index, your website might as well not exist, right? As I said, be careful not to throw the baby with the bathwater. Google is not what made the web great, but a Google dependency might break it and website authors can be blamed for this.
This sounds like a huge imposition to implement -- so much so that I seriously doubt anyone will bother for anything even moderately complex. Not only do you have to produce an API for the client-side javascript to call, but you also have to render static HTML for Google to index.
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.
There is (thankfully) no law which say that your service must be usable for people who turn javascript of.
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.
It is one thing if we were talking about a webpage ala 1995 for joes autoshop. At most it will have a comment field (or, the horror, a guestbook) and each url will map logically to a specific public part of the site. Most likely there will be no concept of users at all.
The same thing goes for a blog although you won't get the auto updating twitter feed and, if the blog uses diques, you may have to click a couple of links to see them.
But a webapp is more like Google writer. It just lose all meaning to make it work without Javascript.
FYI.
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.
... with all the security/privacy problems that go with that, and then some.
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).
What I see in practice is the exact opposite. Everyone writing about "what is possible" with JavaScript (custom 3d rendering engine for every website!), very few people are concerned about architectural and practical issues of it all.
Web applications are only going to get faster, and if you want to keep up, you're going to have to do implement modern solutions like Battlelog and Google+ do.
I can envision a time when full page refreshes are the exception and that isn't a bad thing.
Full page refreshes are not what makes web applications slow. I used to browse the web on 133MHz computer over a mediocre modem connection. Today, despite all these promises of speed, many JS-heavy websites seriously lag on anything slower than 1.5MBps and 2GHz dual-core. (Try browsing via Kindle.)
Out of interest, what solutions are there for this currently?
But what I've tinkered with is very exciting.
I know that web apps is all the rage those days, but given the native plugin, pickiness about browser version, the fact that they apparently not care about being indexed by search engines, and all the trouble they went through to make it all work together - wouldn't they be better off to just implement the whole thing as a native app?
I'm not a web dev, but I like the client side rendering. (Even if I hate JS with a passion). This is a fantastic move as it lets you very clearly seperate presentation from business logic and the database. Also, the rendering HTML/JS can be easily cached. So you get a normal page load the first time you try the app, every time after that you get _instant_ results. Nice.
I muddled my point by mentioning Twitter - it was very nearly a non sequitur. They're supporting two paradigms but not because they want to. My understanding is that they don't have a single solution that works equally well on the client and server so they are using two different solutions.
Battlelog is really good. It responds almost instantly. You can middle click open server info pages, then middle click open the stats for every player on that server. Updates don't require a patch to the client, just change the HTML and JS that Battlelog is sending out (this was already done to add queues when servers are full).
It could certainly have been done in game with embedded WebKit/IE or something though, prepackaging the plugin alongside. I don't really mind either approach, since Battlefield 3, for once, is a game on Windows that has absolutely no problem with the use of alt+tab.
[1] http://www.blogcdn.com/news.bigdownload.com/media/2008/11/le...
2. The "massive JS framework" won't seem so massive once you browse a few pages – the payload savings will likely pay off pretty quickly. Notice that the AJAX data for the index page was 4KB, vs. 18KB for the fully rendered page.
3. Cross-language templating languages aren't so rare (Mustache being a very popular choice).
Consider this: once you want even just one tiny widget on the page to update via AJAX or push notifications, you've already got the code to support half of these features.
That said, it's only a matter of time before the "harder to develop and test for" goes away and rich apps will become more of the norm.
I actually find that bit easier, because I can separate out the the parts and worry about things a piece at a time. The other benefit of this is if you chose to develop for iOS, Android or any other platforms you already have an API. Equally if you wanted a developer program, again it's already there.
The complexity comes when you make the decision as to whether or not to support clients that can't or won't execute Javascript, if you want to make it work for them too you're stuck with more work and things do get more difficult.
As far as testing goes, there are plenty of mature javascript unit testing frameworks and if your inclined to unit test your javascript already this doesn't add a great deal of overhead. Your really just testing something in JS you would have otherwise done and tested server-side.
However, my experience is that it still has some mayor drawbacks. Javascripts frameworks (testing and otherwise) are still less mature, then their server-side counterparts are. It is not always as obvious how things should be done. There are still lots of incompatibilities between browsers. And when an error happens you can not log it (or at least you have to do more effort).
I have to say, too, that in my experience the more client-side state a web page keeps, the buggier it tends to be. Building applications this way is harder, and I hope we don't end up losing the characteristics that have made the Web so successful in the transition.
A lot of users complained that there was no feature to allow you to wait in a queue for a full server. So... they added it. Pushed a server update. No patch, no new binaries to download. A new checkbox simply appeared.
Now, there's no reason that this has to be in browser. EA and Valve both clearly have WebKit or IE implementations (I think I heard the "clicking" noise in the Origin browser) that play nice in fullscreen games. They could certainly be integrated as part of the game interface, but Battlelog makes it clear to me that HTML and CSS are the way to go with video game server browsers in the future.
I've noticed that too. You still need to load a fresh DOM from time to time. I'm sure future frameworks will have some sort of a semi-refresh where all of the static elements stay the same, but the framework runs a sort of cleanup on the DOM.
I've done my shared of such web-application using GWT.
This technique, known as the "single page application" is like writing a desktop-app but with additional complexity such as maintaining a history on your own and deciding what "back" button action means depending on the context.
The other additional complexity is the "offline" mode. Now suddenly you have sync issues.
Pretty difficult even with frameworks.
A month ago we decided to build a facebook app to reach users that don't have a smartphone. We chose not to change one bit of code in the backend, and we were able to build the web app in 3 weeks with backbone, jquery, and websocket-js.
You can try it here: http://apps.facebook.com/glancee
The app is just one 40-line html page, the rest is javascript (and templates embedded in js). You never refresh the page when clicking a link, which gives you the feeling of using something as fast and robust as gmail.
CSS files and JS files are compressed with requirejs before being deployed, so to load the page you need three requests (plus images). Right now our biggest bottleneck is the facebook api, which is tremendously slow.
Battlelog as a stat tracker is great. As a system of convenience run in conjunction with Origin and the actual Game EXE it sux.
If we make the assumption that: - The vision of Web 1.0 (mid- to late 90's) was Web 3.0 (the modern web app). - Web 2.0 really just evolved the technologies and tools.
During the 90's we deplored thick client apps. We had 2/3/n tier on the desktop, and we wanted web apps.
Now, 15 years later, we're building 2/3/n tier apps in the browser - but we make the same architectural mistakes we made with thick clients, we ignore user control and consent, we expose devices to all sorts of attacks that don't exist in thick client apps...
That's hard-core irony, right there.
There are plenty of templating engines that have been ported to Javascript. Mustache is the first example that comes to mind: http://mustache.github.com/
Once you have the templating engine the rest of the logic is pretty easy to build.
Rendering web apps entirely on the client in general is pretty awesome although there are two problems: 1) the push state API is not supported in all browsers yet, which forces you to resort the fragment identifier + onhashchange to approximate the same functionality. And of course the fragment identifier only affords you a fraction of the same luxuries as the push state API. And of course onhashchange is not supported in older browsers. 2) When you fall back to the fragment identifier rendering on the client is actually a little bit slower. The fragment identifier is not sent to the server meaning the javascript has to be loaded in the browser before anything at all is rendered. Does this lead to several seconds of delay? No. But it is noticeable. At least with push state you have the option of rendering the initial content on the server and all subsequent requests on the client without increasing complexity too much, assuming you have a good templating solution in place.
But yes I agree. Modern Web Apps are Here :)
Unreal did that back in 1998. They register the unreal:// protocol in windows so any hyperlinks that contain an address such as unreal://127.0.0.1 will launch the game and connect to that ip. The good thing about this is that it can also be used by third party websites such as promoting your clans server and it is completely browser independent. I don't know if it could be abused to "rickroll-launch" the game but i haven't heard of any such incidents.
Personally, I'm not a big fan of such solutions (Battlelog included) - mainly because switching between fullscreen game and browser is, in most cases, very jerky (although it has improved since "Unreal" times). Also, the difference between in-game and in-browser UX ruins the flow of the whole thing. Have to admit though that viewing friends, statistics, etc. through a web browser is very convenient.
cod4://212.85.69.40:28960/In terms of game manufacturers it is light years ahead of what they've done before. I just don't see why the author is quite so blown away by it..
What this means is that you can actually deploy these new features in the real world without freezing out part of your audience, as happened with Gawker's ill-fated redesign.
What's more, you can do this without having to develop everything twice, using abstractions like client/server shared language-agnostic templates and realtime libraries like Socket.IO.
Something I read a few months ago: Thoughtworks paper on technology that described GWT as a bad idea, very well implemented. :-)
It also makes a developer program something that's quick and easy to support, again the API is ready and waiting.
The framework then hooks into your browser's navigation code an intercepts all page loads. Instead of letting the browser replace the page with something new on load it instead does the HTTP request via Ajax and adds an additional header to the HTTP request: X-Ajax-Navigation.
Wouldn't it be better to intercept the page leave event, rather than load?
How do other people do file uploads with an asynchronous web server?