9 ms·

Farewell to Regular Web Development Approaches

106 points by hunvreus 14y ago

deleted 14y ago
[deleted]
andrzejkrzywda 14y ago
It's both simple and revolutionary. It starts with saying "well, let's just render html on the client-side instead of on the backend". Suddenly you're in a new world of programming.
- iso-8859-1 14y ago
  It's document-generation versus API writing, as I see it.
- tluyben2 14y ago
  How about Google SEO? If content is pulled via AJAX and rendered in the client; what does Google see?
  - hunvreus 14y ago
    Google is actually starting to crawl that too. But more importantly, in many case it's not that much of a concern (private apps and/or content for example). And if you need so, you can follow Google's guidelines on the subject: https://developers.google.com/webmasters/ajax-crawling/ https://developers.google.com/webmasters/ajax-crawling/
    - Isofarro 14y ago
      It fails in practice though. Gawker tried this, and reverted it a few months later when it became clear that their traffic from search engines took a nose-dive.
      - hunvreus 14y ago
        Interesting. You're sure it's not because most of the advertising business right now is organized around the "more pageviews == more prints == more $$" logic? It sure doesn't help to sell to advertisers. But we're mostly building products that need to sell to users, we care a lot more about UX and relevancy.
        Isofarro 14y ago
        Very sure. http://news.ycombinator.com/item?id=2596263 http://news.ycombinator.com/item?id=2596263 -- that's what I wrote two years ago: Once of the reasons Gawker moved away from hashbangs is that they weren't well supported by Google, despite this being a "Google specification". Nick Denton, the founder of Gawker, has some interesting tweets about the use of hashbangs over the past few months: Nick Denton: "Dip in uniques largely because of drop in Google refers. Pageviews (which are driven more by core audience) less affected." -- http://twitter.com/nicknotned/status/61152134929981440 http://twitter.com/nicknotned/status/61152134929981440 Nick Denton: "Google does not fully support "hashbang" URLs. So we're eliminating them rather than waiting for Mountain View." -- http://twitter.com/nicknotned/status/61465859079671808 http://twitter.com/nicknotned/status/61465859079671808 Nick Denton: "Yeah, I'd advise against hashbang urls. Will kill search traffic -- even if you abide by Google protocol." -- http://twitter.com/nicknotned/status/62595141927583745 http://twitter.com/nicknotned/status/62595141927583745 So here's a high-profile failure of hashbangs when it comes to being indexed by Google. Which means if it's search indexability you want, hashbangs isn't it. The Google spec just isn't mature enough, or well supported by Google search itself.
  - RobAley 14y ago
    Google uses a crawler (allegedly) build on Chrome's internals, and renders a lot of Javascript/AJAX content just fine.
    - mmahemoff 14y ago
      I'm not sure they'll index content based on this though (yet). It's probably used to check other algorithm drivers like page performance and spam tricks.
      - blowski 14y ago
        They do index at least some AJAX content - https://twitter.com/mattcutts/status/131425949597179904 https://twitter.com/mattcutts/status/131425949597179904.
      - RobAley 14y ago
        They have been doing for a while, at least for non-user-initiated ajaxy data : http://www.tomshardware.com/news/google-googlebot-ajax-javascript-content,13881.html http://www.tomshardware.com/news/google-googlebot-ajax-javas...
  - steeve 14y ago
    One approach is to use PhantomJS as your app server (much like you would use Django, Rails or something else) to render HTML for the crawlers. See http://github.com/steeve/angular-seo http://github.com/steeve/angular-seo
    - crucialfelix 14y ago
      that's just crazy enough that it might work. have you run this in production ? it renders each fragment to a file and serves that to the bots, right ?
      - steeve 14y ago
        it does, I'm doing a version for html5modes angular apps (slightly more complicated!) careful to only serve these pages to bots tho
  - mmahemoff 14y ago
    SEO is really the last bastion, the one major benefit, of "the old way". Decent server-side JavaScript means there are becoming ways to deal with it. See the post from yesterday on AirBNB's dual-side JS approach. http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t...
  - andrzejkrzywda 14y ago
    The best way seems to be returning different results to the Google bots. It's recommended by Google. It's not as much pain as you would think, it's enough to just return some html. No css/js is needed. Still, that's some additional work.
    - Isofarro 14y ago
      No. Returning different content to Googlebot is a technique called cloaking. http://en.wikipedia.org/wiki/Cloaking http://en.wikipedia.org/wiki/Cloaking Probably worth reading this: http://productforums.google.com/forum/#!category-topic/webmasters/crawling-indexing--ranking/4sVFlIdj7d8 http://productforums.google.com/forum/#!category-topic/webma... They'll accept geo-targeted or mobile vs desktop optimised content, but everything else is a grey area.
      - andrzejkrzywda 14y ago
        The official documentation is here: https://developers.google.com/webmasters/ajax-crawling https://developers.google.com/webmasters/ajax-crawling
        Isofarro 14y ago
        That talks about using progressive enhancement as the primary approach to building websites.
- zanny 14y ago
  One problem I see is that a lot of that page generation being moved to the client increases the first time page loads (which matter) and on a mobile device can prove very taxing on 3 - 4 year old hardware. I think it is more about do you want to figure out the html in JS or something else, and do you want to pay the bill to make the pages at home or lose some customers who don't have the power to do it themselves.
  - andrzejkrzywda 14y ago
    It's not all or nothing. You can do what Twitter did. Allow some duplication and render html server-side on the first request.
  - hunvreus 14y ago
    Airbnb mentions that in a recent post: http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t.... I think, ultimately, it depends on how your app is structured and how heavy is your feature set. We usually try and keep things as simple as possible, but we've experienced the issue a couple more complex apps and spent a good deal of time optimizing things and dynamically loading dependencies. They ain't no silver bullet: you have to decide where you want to invest your time.
- jacques_chester 14y ago
  Shipping JS to a browser and then rendering the page with javascript DOM manipulation was the Hot New Thing in about about 1998, as I recall. It didn't last because, unsurprisingly, plain HTML loads renders a lot faster. That said: XHR is a genuine change in the model. So too the leaps and bounds in bandwidth and computing power.
  - martinced 14y ago
    "So too the leaps and bounds in bandwidth and computing power." And JavaScript engines performances too. What is your point? You write in italics that "plain HTML renders a lot faster" and then you contradict yourself.
    - jacques_chester 14y ago
      Plain HTML still renders faster.
      - blowski 14y ago
        First page load, definitely. Subsequent updates - depends.
        jacques_chester 14y ago
        Sure. Part of the confusion is that HTML is living a strange life as part document, part app platform. I mean if you compare HTML and JS to the fit-and-finish of a mid 90s platform it's a mess. But, it's what we have.
davidw 14y ago
It sounds like the big jump here might not have been so much moving to Javascript/frontend-based apps, as moving away from a CMS towards a model where they write and control the whole app.
- hunvreus 14y ago
  Interesting, I hadn't looked at things that way. I think though that the control over the code base wasn't much of the issue: the mental bloat it was bringing in our thought process though definitely was. We many times solved problems following the underlying CMS' patterns, and that ended up eating more and more of our resources. IMHO, our main gain here is the fact that we can focus back on the end user and the story we're trying to tell through our apps.
Kiro 14y ago
What about security? How do you authenticate users?
- zanny 14y ago
  You can still preserve session cookies over only a JSON exchange. I recently had to deal with this in an android app syncing with a backend server.
- hunvreus 14y ago
  We actually presented a few days ago at the local node.js meetup: https://speakerdeck.com/hunvreus/api-plus-static-clients https://speakerdeck.com/hunvreus/api-plus-static-clients CORS and session handling really are the main issue we faced. Easy to handle though once you understand the limitations.
why-el 14y ago
One small issue dev friends I talk to still face is pricing and the need to convince clients that a move to a ruby or js based tech stack vs Wordpress is worth it. In the country where I live, wordpress is far, far cheaper to host than anything else.
- tluyben2 14y ago
  Not to mention there are far more developers for it (good and bad), for some things it's much faster to work with (for most blogs with some extra fields and actually for most websites, even with mildy complex functionality it is quicker to set up and work with) etc. I'm not a WP fan, but sometimes the 'new way' is just for the hard-on and 'public profile' of the developer and outside silicon valley or other startup hubs it's just not that popular (yet).
- jonascopenhagen 14y ago
  Static HTML apps + REST APIs aren't dependant on Ruby/JS at all. You could easily use a REST-centric PHP framework such as http://www.slimframework.com/ http://www.slimframework.com/ as the backend. Same hosting price as WordPress. On top of that, Slim Framework is great to work with and is fast to set up compared to e.g. Sinatra or Node.
  - why-el 14y ago
    I am sure they aren't and I did not mean to suggest they are. When it comes to what backend to hook your static stuff to, it's just a matter of personal preference. All I am saying is that its harder in some parts of the world where Wordpress is still looked at as the cheapest, most viable option.
    - jonascopenhagen 14y ago
      What I don't understand is why WordPress would be cheaper than other forms of PHP software? Most smaller PHP frameworks such as Slim Framework or Laravel require even less memory than WordPress and could easily be installed on a small web hosting account.
boothead 14y ago
I've noticed this as well (and there was a post from Tarek Ziadé's blog a couple of days that mentioned it too) [1] I've evolved to this approach - with the addition of WebSockets and a data binding layer (knockout) - to building the infrastructure for an algorithmic hedge fund over the last couple of years and it works extremely well. Your backend components are free to do whatever they need to (in whatever language/technology) and publish data periodically. The web server simply dips into these streams of updates and transforms and routes them to the front end as needed. It's an extremely flexible and agile way to develop applications, I can't recommend it enough! In fact it's so nice to develop this way that I'm writing a book about the ideas and techniques I've used which I hope to post to HN in a couple of weeks when I've got the infrastructure and homepage up and running. [1] Post: http://blog.ziade.org/2013/01/25/a-new-development-era-essay/ http://blog.ziade.org/2013/01/25/a-new-development-era-essay... Discussion: http://news.ycombinator.com/item?id=5120020 http://news.ycombinator.com/item?id=5120020
jacques_chester 14y ago
Everything old is new again. This used to be called Service-Oriented Architecture. Before that, client-server computing. Before that, online terminals. No, it's not exactly the same. History in our industry, as Mark Twain said, doesn't repeat. But it sure does rhyme. My main concern is that people have a problem with Completely Legitimate Architecture X, and then stumble on Completely Legitimate Architecture Y. What was a nightmare in CLA-X is a cakewalk in CLA-Y. Then come the blog posts (previously the CACM articles). The books. The conferences. The whole grand crusade springs to life and promises to evict the horrid evils of CLA-X, now that the scales have fallen from our eyes. Then after a while, CLA-Y becomes the norm and CLA-X fades into infinite obscurity. CLA-Y is unquestioned, unexamined. Just how things are done. Why? Because. Then one day a bright programmer notices that if they rearrange the pieces like so, they solve a number of well known problems with CLA-Y. Not improve, not ameliorate. Solve! And somewhere, a 32-year-old curmudgeon called Jacques Chester begins to write a long post about how this is actually just CLA-X, with a different name ...
- andrzejkrzywda 14y ago
  It may help, if we focus on some specific examples of CLA-X and CLA-Y. Rendering html on the backend was the only option for years, as the clients didn't have the computation power. Now, we're getting to the point, where rendering client-side becomes possible. We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separation between the client and the server. We can (and we do) have separate teams working on client/server. It wasn't that easy before. I'm 33, if that makes my comment more legit ;)
  - Isofarro 14y ago
    > We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separation between the client and the server. Except the time to first user activity is delayed. Speed is an important criteria to responsiveness. The architecture problems can be solved without pushing it all to the client. It's a standard service-oriented architecture. Where the processing happens is mostly irrelevant.
drdaeman 14y ago
I wonder what were the reasons to actually change the whole stack/architecture and start to re-invent the world. There are tons "traditional" frameworks that are mature, proven to be reliable and are full of features. I've tried about a dozen of both various so-called "RESTful API" (server-side) and webapp frameworks (client-side), and my overall impression is things are far from being mature. Primitive todo-list apps are easy, but more complex things quickly run into lack of features, documentation or just bugs.
- PommeDeTerre 14y ago
  A lot of those problems you mention are due to JavaScript realistically being the only language available for client-side web development. It's just not a good language for anything but the shortest of scripts. It lacks a proper type system. It lacks proper support for namespaces and modularity. It is full of far too many inexcusable flaws ("quirks", as its advocates like to call them), even in such basic functionality as its equality comparisons. It's full of features that are outright harmful. Prototype-based OO has proven, in practice, to be inferior to the more traditional class-based OO approach. It's just one problem after another when using JavaScript. CoffeeScript and other languages that "compile" down to JavaScript may help somewhat, but their JavaScript legacy is still generally quite apparent. Instead of being "good", they're just "not as outright horrible" as JavaScript. Things would be much better if there were a wider variety of languages supported by browsers, including ones with the feature set necessary for effective, large-scale software development.
  - rbrcurtis 14y ago
    With commonJS javascript is a perfectly good language to write real, large code base apps in. With coffeescript, it's a pleasure.
    - drdaeman 14y ago
      I've recently used Require.js to load JS libraries (client-side) and had more problems (working around libraries that know nothing about R.JS/AMD), than benefits. Not sure how it is with CommonJS. IMHO, when compared to asset compilers in many modern frameworks, the profits are disputable.
steeve 14y ago
Next thing you know, we'll install JS apps just as desktop apps! ...wait a minute.
obituary_latte 14y ago
If their mobile site is any indication, were in for a rough ride. Of course there may be more pressing issues mentioned in the article, but I couldn't read it as 20% of every single line is cut off. I really think it's important tha and approach. When it isn't consi class. After all, there are only size.
- skormos 14y ago
  Srsly.
- hunvreus 14y ago
  We put it out there without checking on mobile devices: it's fixed. Our thoughts were not much about mobile in particular but the overall approach of using static clients and APIs in the backend.
jsiarto 14y ago
Every time I see posts like this, I come back to warpspire's "Dumb Software:" http://warpspire.com/posts/dumb-software/ http://warpspire.com/posts/dumb-software/ "But wait until you see the light! Software today is intelligent! Asynchronous front ends generated from esoteric scripting languages running on clusters of distributed virtual machines around the globe! Death to repetition! It’s more productive! It’s scalable! It’s fault tolerant! I followed the light and it only ended in darkness." I also don't understand comments like "we can make drastic changes in the UI without any change on the backend" In Wordpress or a Rails App, I can change the entire UI without having to touch any "backend" code (controllers, models, functions, etc). Am I missing something here?
- Isofarro 14y ago
  > I also don't understand comments like "we can make drastic changes in the UI without any change on the backend" All they've done is to move a chunk of the backend into the browser. It's still there, running on an untrusted environment.
- ams6110 14y ago
  we can make drastic changes in the UI without any change on the backend This has always been possible with well-architectected systems, but more importantly it's mostly a platitude. It just doesn't happen in real life. "Drastic changes" to the UI are almost always driven by changes in requirements and hence they impact the entire system.
- hunvreus 14y ago
  Well, for us updating a query for example is not much of a hassle. However, we often found ourselves quickly iterating on the workflows and UI elements. That, from experience again, has been traditionally much more painful to deal with when we had a more complex CMS underneath. With a clean separation of client and server, we've been able to deal with these changes more easily, being able to prototype something HTML5 + CSS and quickly transforming this prototype into the real final product. Working with fewer layers in between you and the actual code (effectively HTML5 + CSS + JS helped too. I'm not questioning your ability to be proficient at it with a CMS (or Rails). I am much more comfortable with our current approach though.
danso 14y ago
So...where's the examples. If the OP works with a lot of non-commercial entities, how does a data API trump the client just being able to create posts and static pages? Most humanitarian groups want an easy to use CMS with some features, like donation modules, added in. Is the OP building out the content editors too? How is that not a CMS? I've yet to work with a humanitarian group for which Wordpress was not more than they could handle on their own. When something breaks in their new-wave architecture, how day is it for them to fix on their own? Edit: I realize the OP is talking about web apps, not just websites...WP is likely not a great option then. But that's why I'm asking for some examples of what they've done and why it justifies a "farewell" to old web dev
- hunvreus 14y ago
  I believe I linked to our work in Sudan (wiredcraft.com/work/southern-sudan-referendum/index.html). We've also done stuff for the UN (http://reliefweb.int http://reliefweb.int), the World Bank, WRI (http://brtdata.org http://brtdata.org) and a whole range of other things my colleagues at Wiredcraft will be happy to mention. I still think there are relevant use cases for using a CMS. However, from experience I think that: 1. In many cases, CMS like Drupal or Wordpress are seen as the silver bullet for everything and anything; "Why use a 3rd party? Just built it in the CMS!". That's how you end up with expensive, tightly coupled platforms that are effectively locking these organisations in. 2. Many organizations are just engaging in some kind of arms race, copying what their neighbors and competitors have.
  - danso 14y ago
    Yes sorry, you caught me in my "reflexively-check-HN-just-as-I-wake-up-groggily" mood...Thank you for the links. I completely agree with you that CMS is seen as an intractable silver bullet. However, I think it is too extreme to say that web development, as we know it, is out the window. While Wordpress is not the silver bullet, the ability to graft on 3rd-party APIs and client-side apps (even something like Disqus/Facebook comments) makes knowing just Wordpress still incredibly useful, for clients who do not need bespoke data solutions. But even with a client who needs data-resources, it seems like Wordpress could still play a key part by being the HTML page server with javascript includes to an external data app...deciding to build a new framework just to accomodate unique data-resources can still be overkill.
DanielBMarkham 14y ago
I had a blast building hn-books (http://hn-books.com http://hn-books.com) All static. I could have deployed the app on a thumb-drive. And it had advanced searching, a book listing and recommendation system, a fully-configurable countdown clock for your startup, and a few other things. It got to the point that whatever I could imagine, I could imagine building it as a static site. And I would prefer doing so. This is truly separating the view from the data. The same back-end services (for hn-books I didn't even have a back-end!) could plug into zillions of variously-looking front-ends. And as it turned out, the Query String was a heckuva lot more useful than I imagined when I started. Neat stuff. ADD: One more thing. If, like most folks, you have a class of data that doesn't change very often, say lookup tables or in hn-books' case the actual database, there's no reason you can't deploy that information as a static file as well. You can pull JSON just as easily from a static file somewhere as as server, and it uses a lot less resources. For my newspaper23 site, I used a combination: 4 times an hour I rebuild the database and deploy as a JSON. Then the clients all just pull from that file. When combined with a CDN this has tremendous scaling potential. And it's very simple to do. Why thrash the database every time somebody visits your site when it's just returning the same stuff?
- hunvreus 14y ago
  We actually often deploy our front-ends on Github pages: it works great.
- hunvreus 14y ago
  I second the "ADD": Development Seed did something very similar on http://developmentseed.org/blog/2012/nov/29/open-undp-launches/ http://developmentseed.org/blog/2012/nov/29/open-undp-launch... and my friends at Wiredcraft are thinking about the same thing for a couple visualization websites (lots of map, lots of data, low amount of edits). Jekyll can be pretty damn slow though (especially on Github pages) so be careful with the size of your data set.
dos1 14y ago
Client side rendering and single page applications are not the best solution for most applications. I posit that a partial page refresh approach using PJAX (or something like it) where the server always sends back HTML is a more efficient and rapid approach to development. There was an article yesterday about how Airbnb was going through some serious gymnastics to get a fully rendered HTML page on initial request and then keep it interactive and client side rendered after that. Why bother? Just send back HTML all the time. I worked on a very large (100+ developer) application that was fully bought in on Backbone + JSON api consumption. In the few cases where there was a lot of client interactivity (editable grids and drag and drop, most notably) the client side rendering approach made sense. For 90 percent of the application though, partial rendering of HTML from the server would have made things easier and less complicated (and faster!) The initial time to usable page is MUCH longer when you render static content, then make an ajax call to get the data.
- amalag 14y ago
  It was interesting a few years ago that Twitter went from server rendered HTML to client rendered HTML back to server rendered HTML (current).
WA 14y ago
I have a hard time following this discussion and would be glad if someone could clarify a few aspects. 1. What is a "static client" in this context? From my understanding, a static client is a non-JS web browser that does one thing: render HTML code that is composed and served by the server. 2. People here talk about "(not) rendering HTML on the server". What's that supposed to be? I thought "rendering HTML" means that you take HTML and display it on a screen, which happens ALWAYS in the client and never on the server. Anyone care to explain?
- abraininavat 14y ago
  I'm not an expert, so take this with a grain of salt. Hopefully someone corrects me if I'm wrong, but.. "Static client" here doesn't refer to the user's browser. It refers to a front-end that serves web requests. It serves them statically, in that every URL maps to a static HTML file (with embedded javascript). Once the user receives that static HTML browser with embedded javascript, this then becomes the client. The javascript (run from within the user's browser now) communicates with a back-end or server, which the article describes as a "RESTful JSON API". It fetches JSON documents and uses the results to render HTML. "Render" here means "turn the backend data into HTML output". This all is in contrast with a more common approach to dynamic web-pages, in that every URL request prompts a dynamic process on the server to do some logic (fetch data from a database often, and parse and interpret request parameters) to render HTML which is then sent back to the user. Hope that helps.
- gbog 14y ago
  1. A static client is an empty page with a big js blob. 2. it is about where the html is generated, either by js on client or by a script on the server.
- felideon 14y ago
  (OT: wow I just learned the hard way that in Chrome C-k kills the rest of input at point and cannot be undone. Also, C-a goes to the beginning of the input, rather than beginning of the line, so my C-a C-k habit made me lose my typed-up comment twice already.) Answering your second question sheds light on the first. A better term would be "generating" HTML on the server — the browser is obviously in charge of rendering. In Rails for example, you can have ruby code in an ERB template which the framework compiles to HTML. Hence, the HTML is "dynamically" generated (on every request). The opposite of dynamic is "static" where the HTML is either written by hand or generated just once (like Jekyll) rather than on every request. In either case, as a sibling comment mentions, an actual HTML file is served. However, thanks to JavaScript development maturing and JS engines getting faster, a lot of functionality that used to be done mainly server-side can be relegated to the client. I personally wouldn't use the phrase "static client" much, though. (Edit: Problem with "static client". To me a 'static' site means that it has no communication with a database, such as marketing sites or statically-generated blogs. 'Client' is too ambiguous as it's not necessarily a browser. curl is an HTTP client, for instance, and a JavaScript-driven "single-page application" would be pretty limited via curl.)
dougk16 14y ago
I do think this is the immediate future, especially as we utilize typed languages that compile to JS in order to create more complex applications than are feasible with JS alone. I also think that there will be a swing back to an almost complete server-centric model after that, where all logic and rendering will take place on the server and be streamed to extremely dumb clients...like TVs with basic touch input. This will require a pretty intense infrastructure, but with some nice perks for hardware/software developers. For one, absolute control over an application...bump versions any time you like, easy access to debugging information (crash reports, etc.), watch user usage in real time, on and on. Hardware will also be insanely cheap. Users benefit from the practical equivalent of having a top-of-the-line computer embedded in their smartphones.
Osiris 14y ago
The product I'm working on right now is taking this approach. We're upgrading a legacy system. In doing so, we're writing a REST API and the components that we replace are all built to use the API rather than the old legacy data layer. The goal to to completely replace the application with an API and several UIs, including a full web UI, a mobile UI, and also 'embeddable' UIs. The API also serves as an integration point for other products in our suite. That allows us to scrape a dozen different SOAP services that are targeted to specific integrations and have those other products all utilize a single API that can do anything that the full product can do. I'm really happy with this architecture.
yycom 14y ago
That's not static. That's client-side dynamic. Words have broadly agreed meaning, despite what you or Humpty Dumpty may think.

106 points by hunvreus 14y ago

deleted 14y ago

[deleted]

It's both simple and revolutionary. It starts with saying "well, let's just render html on the client-side instead of on the backend". Suddenly you're in a new world of programming.

iso-8859-1 14y ago
It's document-generation versus API writing, as I see it.
tluyben2 14y ago
How about Google SEO? If content is pulled via AJAX and rendered in the client; what does Google see?
- hunvreus 14y ago
  Google is actually starting to crawl that too. But more importantly, in many case it's not that much of a concern (private apps and/or content for example). And if you need so, you can follow Google's guidelines on the subject: https://developers.google.com/webmasters/ajax-crawling/ https://developers.google.com/webmasters/ajax-crawling/
  - Isofarro 14y ago
    It fails in practice though. Gawker tried this, and reverted it a few months later when it became clear that their traffic from search engines took a nose-dive.
    - hunvreus 14y ago
      Interesting. You're sure it's not because most of the advertising business right now is organized around the "more pageviews == more prints == more $$" logic? It sure doesn't help to sell to advertisers. But we're mostly building products that need to sell to users, we care a lot more about UX and relevancy.
      - Isofarro 14y ago
        Very sure. http://news.ycombinator.com/item?id=2596263 http://news.ycombinator.com/item?id=2596263 -- that's what I wrote two years ago: Once of the reasons Gawker moved away from hashbangs is that they weren't well supported by Google, despite this being a "Google specification". Nick Denton, the founder of Gawker, has some interesting tweets about the use of hashbangs over the past few months: Nick Denton: "Dip in uniques largely because of drop in Google refers. Pageviews (which are driven more by core audience) less affected." -- http://twitter.com/nicknotned/status/61152134929981440 http://twitter.com/nicknotned/status/61152134929981440 Nick Denton: "Google does not fully support "hashbang" URLs. So we're eliminating them rather than waiting for Mountain View." -- http://twitter.com/nicknotned/status/61465859079671808 http://twitter.com/nicknotned/status/61465859079671808 Nick Denton: "Yeah, I'd advise against hashbang urls. Will kill search traffic -- even if you abide by Google protocol." -- http://twitter.com/nicknotned/status/62595141927583745 http://twitter.com/nicknotned/status/62595141927583745 So here's a high-profile failure of hashbangs when it comes to being indexed by Google. Which means if it's search indexability you want, hashbangs isn't it. The Google spec just isn't mature enough, or well supported by Google search itself.
- RobAley 14y ago
  Google uses a crawler (allegedly) build on Chrome's internals, and renders a lot of Javascript/AJAX content just fine.
  - mmahemoff 14y ago
    I'm not sure they'll index content based on this though (yet). It's probably used to check other algorithm drivers like page performance and spam tricks.
    - blowski 14y ago
      They do index at least some AJAX content - https://twitter.com/mattcutts/status/131425949597179904 https://twitter.com/mattcutts/status/131425949597179904.
    - RobAley 14y ago
      They have been doing for a while, at least for non-user-initiated ajaxy data : http://www.tomshardware.com/news/google-googlebot-ajax-javascript-content,13881.html http://www.tomshardware.com/news/google-googlebot-ajax-javas...
- steeve 14y ago
  One approach is to use PhantomJS as your app server (much like you would use Django, Rails or something else) to render HTML for the crawlers. See http://github.com/steeve/angular-seo http://github.com/steeve/angular-seo
  - crucialfelix 14y ago
    that's just crazy enough that it might work. have you run this in production ? it renders each fragment to a file and serves that to the bots, right ?
    - steeve 14y ago
      it does, I'm doing a version for html5modes angular apps (slightly more complicated!) careful to only serve these pages to bots tho
- mmahemoff 14y ago
  SEO is really the last bastion, the one major benefit, of "the old way". Decent server-side JavaScript means there are becoming ways to deal with it. See the post from yesterday on AirBNB's dual-side JS approach. http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t...
- andrzejkrzywda 14y ago
  The best way seems to be returning different results to the Google bots. It's recommended by Google. It's not as much pain as you would think, it's enough to just return some html. No css/js is needed. Still, that's some additional work.
  - Isofarro 14y ago
    No. Returning different content to Googlebot is a technique called cloaking. http://en.wikipedia.org/wiki/Cloaking http://en.wikipedia.org/wiki/Cloaking Probably worth reading this: http://productforums.google.com/forum/#!category-topic/webmasters/crawling-indexing--ranking/4sVFlIdj7d8 http://productforums.google.com/forum/#!category-topic/webma... They'll accept geo-targeted or mobile vs desktop optimised content, but everything else is a grey area.
    - andrzejkrzywda 14y ago
      The official documentation is here: https://developers.google.com/webmasters/ajax-crawling https://developers.google.com/webmasters/ajax-crawling
      - Isofarro 14y ago
        That talks about using progressive enhancement as the primary approach to building websites.
zanny 14y ago
One problem I see is that a lot of that page generation being moved to the client increases the first time page loads (which matter) and on a mobile device can prove very taxing on 3 - 4 year old hardware. I think it is more about do you want to figure out the html in JS or something else, and do you want to pay the bill to make the pages at home or lose some customers who don't have the power to do it themselves.
- andrzejkrzywda 14y ago
  It's not all or nothing. You can do what Twitter did. Allow some duplication and render html server-side on the first request.
- hunvreus 14y ago
  Airbnb mentions that in a recent post: http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-to-product http://nerds.airbnb.com/weve-launched-our-first-nodejs-app-t.... I think, ultimately, it depends on how your app is structured and how heavy is your feature set. We usually try and keep things as simple as possible, but we've experienced the issue a couple more complex apps and spent a good deal of time optimizing things and dynamically loading dependencies. They ain't no silver bullet: you have to decide where you want to invest your time.
jacques_chester 14y ago
Shipping JS to a browser and then rendering the page with javascript DOM manipulation was the Hot New Thing in about about 1998, as I recall. It didn't last because, unsurprisingly, plain HTML loads renders a lot faster. That said: XHR is a genuine change in the model. So too the leaps and bounds in bandwidth and computing power.
- martinced 14y ago
  "So too the leaps and bounds in bandwidth and computing power." And JavaScript engines performances too. What is your point? You write in italics that "plain HTML renders a lot faster" and then you contradict yourself.
  - jacques_chester 14y ago
    Plain HTML still renders faster.
    - blowski 14y ago
      First page load, definitely. Subsequent updates - depends.
      - jacques_chester 14y ago
        Sure. Part of the confusion is that HTML is living a strange life as part document, part app platform. I mean if you compare HTML and JS to the fit-and-finish of a mid 90s platform it's a mess. But, it's what we have.

davidw 14y ago

It sounds like the big jump here might not have been so much moving to Javascript/frontend-based apps, as moving away from a CMS towards a model where they write and control the whole app.

hunvreus 14y ago
Interesting, I hadn't looked at things that way. I think though that the control over the code base wasn't much of the issue: the mental bloat it was bringing in our thought process though definitely was. We many times solved problems following the underlying CMS' patterns, and that ended up eating more and more of our resources. IMHO, our main gain here is the fact that we can focus back on the end user and the story we're trying to tell through our apps.

Kiro 14y ago

What about security? How do you authenticate users?

zanny 14y ago
You can still preserve session cookies over only a JSON exchange. I recently had to deal with this in an android app syncing with a backend server.
hunvreus 14y ago
We actually presented a few days ago at the local node.js meetup: https://speakerdeck.com/hunvreus/api-plus-static-clients https://speakerdeck.com/hunvreus/api-plus-static-clients CORS and session handling really are the main issue we faced. Easy to handle though once you understand the limitations.

why-el 14y ago

One small issue dev friends I talk to still face is pricing and the need to convince clients that a move to a ruby or js based tech stack vs Wordpress is worth it. In the country where I live, wordpress is far, far cheaper to host than anything else.

tluyben2 14y ago
Not to mention there are far more developers for it (good and bad), for some things it's much faster to work with (for most blogs with some extra fields and actually for most websites, even with mildy complex functionality it is quicker to set up and work with) etc. I'm not a WP fan, but sometimes the 'new way' is just for the hard-on and 'public profile' of the developer and outside silicon valley or other startup hubs it's just not that popular (yet).
jonascopenhagen 14y ago
Static HTML apps + REST APIs aren't dependant on Ruby/JS at all. You could easily use a REST-centric PHP framework such as http://www.slimframework.com/ http://www.slimframework.com/ as the backend. Same hosting price as WordPress. On top of that, Slim Framework is great to work with and is fast to set up compared to e.g. Sinatra or Node.
- why-el 14y ago
  I am sure they aren't and I did not mean to suggest they are. When it comes to what backend to hook your static stuff to, it's just a matter of personal preference. All I am saying is that its harder in some parts of the world where Wordpress is still looked at as the cheapest, most viable option.
  - jonascopenhagen 14y ago
    What I don't understand is why WordPress would be cheaper than other forms of PHP software? Most smaller PHP frameworks such as Slim Framework or Laravel require even less memory than WordPress and could easily be installed on a small web hosting account.

boothead 14y ago

I've noticed this as well (and there was a post from Tarek Ziadé's blog a couple of days that mentioned it too) [1] I've evolved to this approach - with the addition of WebSockets and a data binding layer (knockout) - to building the infrastructure for an algorithmic hedge fund over the last couple of years and it works extremely well. Your backend components are free to do whatever they need to (in whatever language/technology) and publish data periodically. The web server simply dips into these streams of updates and transforms and routes them to the front end as needed. It's an extremely flexible and agile way to develop applications, I can't recommend it enough! In fact it's so nice to develop this way that I'm writing a book about the ideas and techniques I've used which I hope to post to HN in a couple of weeks when I've got the infrastructure and homepage up and running. [1] Post: http://blog.ziade.org/2013/01/25/a-new-development-era-essay/ http://blog.ziade.org/2013/01/25/a-new-development-era-essay... Discussion: http://news.ycombinator.com/item?id=5120020 http://news.ycombinator.com/item?id=5120020

jacques_chester 14y ago

Everything old is new again. This used to be called Service-Oriented Architecture. Before that, client-server computing. Before that, online terminals. No, it's not exactly the same. History in our industry, as Mark Twain said, doesn't repeat. But it sure does rhyme. My main concern is that people have a problem with Completely Legitimate Architecture X, and then stumble on Completely Legitimate Architecture Y. What was a nightmare in CLA-X is a cakewalk in CLA-Y. Then come the blog posts (previously the CACM articles). The books. The conferences. The whole grand crusade springs to life and promises to evict the horrid evils of CLA-X, now that the scales have fallen from our eyes. Then after a while, CLA-Y becomes the norm and CLA-X fades into infinite obscurity. CLA-Y is unquestioned, unexamined. Just how things are done. Why? Because. Then one day a bright programmer notices that if they rearrange the pieces like so, they solve a number of well known problems with CLA-Y. Not improve, not ameliorate. Solve! And somewhere, a 32-year-old curmudgeon called Jacques Chester begins to write a long post about how this is actually just CLA-X, with a different name ...

andrzejkrzywda 14y ago
It may help, if we focus on some specific examples of CLA-X and CLA-Y. Rendering html on the backend was the only option for years, as the clients didn't have the computation power. Now, we're getting to the point, where rendering client-side becomes possible. We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separation between the client and the server. We can (and we do) have separate teams working on client/server. It wasn't that easy before. I'm 33, if that makes my comment more legit ;)
- Isofarro 14y ago
  > We're not rendering html client-side for fun. It makes the UI more responsive, while keeping the overall architecture more simple. There's a cleaner separation between the client and the server. Except the time to first user activity is delayed. Speed is an important criteria to responsiveness. The architecture problems can be solved without pushing it all to the client. It's a standard service-oriented architecture. Where the processing happens is mostly irrelevant.

drdaeman 14y ago

I wonder what were the reasons to actually change the whole stack/architecture and start to re-invent the world. There are tons "traditional" frameworks that are mature, proven to be reliable and are full of features. I've tried about a dozen of both various so-called "RESTful API" (server-side) and webapp frameworks (client-side), and my overall impression is things are far from being mature. Primitive todo-list apps are easy, but more complex things quickly run into lack of features, documentation or just bugs.

PommeDeTerre 14y ago
A lot of those problems you mention are due to JavaScript realistically being the only language available for client-side web development. It's just not a good language for anything but the shortest of scripts. It lacks a proper type system. It lacks proper support for namespaces and modularity. It is full of far too many inexcusable flaws ("quirks", as its advocates like to call them), even in such basic functionality as its equality comparisons. It's full of features that are outright harmful. Prototype-based OO has proven, in practice, to be inferior to the more traditional class-based OO approach. It's just one problem after another when using JavaScript. CoffeeScript and other languages that "compile" down to JavaScript may help somewhat, but their JavaScript legacy is still generally quite apparent. Instead of being "good", they're just "not as outright horrible" as JavaScript. Things would be much better if there were a wider variety of languages supported by browsers, including ones with the feature set necessary for effective, large-scale software development.
- rbrcurtis 14y ago
  With commonJS javascript is a perfectly good language to write real, large code base apps in. With coffeescript, it's a pleasure.
  - drdaeman 14y ago
    I've recently used Require.js to load JS libraries (client-side) and had more problems (working around libraries that know nothing about R.JS/AMD), than benefits. Not sure how it is with CommonJS. IMHO, when compared to asset compilers in many modern frameworks, the profits are disputable.

steeve 14y ago

Next thing you know, we'll install JS apps just as desktop apps! ...wait a minute.

obituary_latte 14y ago

If their mobile site is any indication, were in for a rough ride. Of course there may be more pressing issues mentioned in the article, but I couldn't read it as 20% of every single line is cut off. I really think it's important tha and approach. When it isn't consi class. After all, there are only size.

skormos 14y ago
Srsly.
hunvreus 14y ago
We put it out there without checking on mobile devices: it's fixed. Our thoughts were not much about mobile in particular but the overall approach of using static clients and APIs in the backend.

jsiarto 14y ago

Every time I see posts like this, I come back to warpspire's "Dumb Software:" http://warpspire.com/posts/dumb-software/ http://warpspire.com/posts/dumb-software/ "But wait until you see the light! Software today is intelligent! Asynchronous front ends generated from esoteric scripting languages running on clusters of distributed virtual machines around the globe! Death to repetition! It’s more productive! It’s scalable! It’s fault tolerant! I followed the light and it only ended in darkness." I also don't understand comments like "we can make drastic changes in the UI without any change on the backend" In Wordpress or a Rails App, I can change the entire UI without having to touch any "backend" code (controllers, models, functions, etc). Am I missing something here?

Isofarro 14y ago
> I also don't understand comments like "we can make drastic changes in the UI without any change on the backend" All they've done is to move a chunk of the backend into the browser. It's still there, running on an untrusted environment.
ams6110 14y ago
we can make drastic changes in the UI without any change on the backend This has always been possible with well-architectected systems, but more importantly it's mostly a platitude. It just doesn't happen in real life. "Drastic changes" to the UI are almost always driven by changes in requirements and hence they impact the entire system.
hunvreus 14y ago
Well, for us updating a query for example is not much of a hassle. However, we often found ourselves quickly iterating on the workflows and UI elements. That, from experience again, has been traditionally much more painful to deal with when we had a more complex CMS underneath. With a clean separation of client and server, we've been able to deal with these changes more easily, being able to prototype something HTML5 + CSS and quickly transforming this prototype into the real final product. Working with fewer layers in between you and the actual code (effectively HTML5 + CSS + JS helped too. I'm not questioning your ability to be proficient at it with a CMS (or Rails). I am much more comfortable with our current approach though.

danso 14y ago

So...where's the examples. If the OP works with a lot of non-commercial entities, how does a data API trump the client just being able to create posts and static pages? Most humanitarian groups want an easy to use CMS with some features, like donation modules, added in. Is the OP building out the content editors too? How is that not a CMS? I've yet to work with a humanitarian group for which Wordpress was not more than they could handle on their own. When something breaks in their new-wave architecture, how day is it for them to fix on their own? Edit: I realize the OP is talking about web apps, not just websites...WP is likely not a great option then. But that's why I'm asking for some examples of what they've done and why it justifies a "farewell" to old web dev

hunvreus 14y ago
I believe I linked to our work in Sudan (wiredcraft.com/work/southern-sudan-referendum/index.html). We've also done stuff for the UN (http://reliefweb.int http://reliefweb.int), the World Bank, WRI (http://brtdata.org http://brtdata.org) and a whole range of other things my colleagues at Wiredcraft will be happy to mention. I still think there are relevant use cases for using a CMS. However, from experience I think that: 1. In many cases, CMS like Drupal or Wordpress are seen as the silver bullet for everything and anything; "Why use a 3rd party? Just built it in the CMS!". That's how you end up with expensive, tightly coupled platforms that are effectively locking these organisations in. 2. Many organizations are just engaging in some kind of arms race, copying what their neighbors and competitors have.
- danso 14y ago
  Yes sorry, you caught me in my "reflexively-check-HN-just-as-I-wake-up-groggily" mood...Thank you for the links. I completely agree with you that CMS is seen as an intractable silver bullet. However, I think it is too extreme to say that web development, as we know it, is out the window. While Wordpress is not the silver bullet, the ability to graft on 3rd-party APIs and client-side apps (even something like Disqus/Facebook comments) makes knowing just Wordpress still incredibly useful, for clients who do not need bespoke data solutions. But even with a client who needs data-resources, it seems like Wordpress could still play a key part by being the HTML page server with javascript includes to an external data app...deciding to build a new framework just to accomodate unique data-resources can still be overkill.

DanielBMarkham 14y ago

I had a blast building hn-books (http://hn-books.com http://hn-books.com) All static. I could have deployed the app on a thumb-drive. And it had advanced searching, a book listing and recommendation system, a fully-configurable countdown clock for your startup, and a few other things. It got to the point that whatever I could imagine, I could imagine building it as a static site. And I would prefer doing so. This is truly separating the view from the data. The same back-end services (for hn-books I didn't even have a back-end!) could plug into zillions of variously-looking front-ends. And as it turned out, the Query String was a heckuva lot more useful than I imagined when I started. Neat stuff. ADD: One more thing. If, like most folks, you have a class of data that doesn't change very often, say lookup tables or in hn-books' case the actual database, there's no reason you can't deploy that information as a static file as well. You can pull JSON just as easily from a static file somewhere as as server, and it uses a lot less resources. For my newspaper23 site, I used a combination: 4 times an hour I rebuild the database and deploy as a JSON. Then the clients all just pull from that file. When combined with a CDN this has tremendous scaling potential. And it's very simple to do. Why thrash the database every time somebody visits your site when it's just returning the same stuff?

hunvreus 14y ago
We actually often deploy our front-ends on Github pages: it works great.
hunvreus 14y ago
I second the "ADD": Development Seed did something very similar on http://developmentseed.org/blog/2012/nov/29/open-undp-launches/ http://developmentseed.org/blog/2012/nov/29/open-undp-launch... and my friends at Wiredcraft are thinking about the same thing for a couple visualization websites (lots of map, lots of data, low amount of edits). Jekyll can be pretty damn slow though (especially on Github pages) so be careful with the size of your data set.

dos1 14y ago

Client side rendering and single page applications are not the best solution for most applications. I posit that a partial page refresh approach using PJAX (or something like it) where the server always sends back HTML is a more efficient and rapid approach to development. There was an article yesterday about how Airbnb was going through some serious gymnastics to get a fully rendered HTML page on initial request and then keep it interactive and client side rendered after that. Why bother? Just send back HTML all the time. I worked on a very large (100+ developer) application that was fully bought in on Backbone + JSON api consumption. In the few cases where there was a lot of client interactivity (editable grids and drag and drop, most notably) the client side rendering approach made sense. For 90 percent of the application though, partial rendering of HTML from the server would have made things easier and less complicated (and faster!) The initial time to usable page is MUCH longer when you render static content, then make an ajax call to get the data.

amalag 14y ago
It was interesting a few years ago that Twitter went from server rendered HTML to client rendered HTML back to server rendered HTML (current).

WA 14y ago

I have a hard time following this discussion and would be glad if someone could clarify a few aspects. 1. What is a "static client" in this context? From my understanding, a static client is a non-JS web browser that does one thing: render HTML code that is composed and served by the server. 2. People here talk about "(not) rendering HTML on the server". What's that supposed to be? I thought "rendering HTML" means that you take HTML and display it on a screen, which happens ALWAYS in the client and never on the server. Anyone care to explain?

abraininavat 14y ago
I'm not an expert, so take this with a grain of salt. Hopefully someone corrects me if I'm wrong, but.. "Static client" here doesn't refer to the user's browser. It refers to a front-end that serves web requests. It serves them statically, in that every URL maps to a static HTML file (with embedded javascript). Once the user receives that static HTML browser with embedded javascript, this then becomes the client. The javascript (run from within the user's browser now) communicates with a back-end or server, which the article describes as a "RESTful JSON API". It fetches JSON documents and uses the results to render HTML. "Render" here means "turn the backend data into HTML output". This all is in contrast with a more common approach to dynamic web-pages, in that every URL request prompts a dynamic process on the server to do some logic (fetch data from a database often, and parse and interpret request parameters) to render HTML which is then sent back to the user. Hope that helps.
gbog 14y ago
1. A static client is an empty page with a big js blob. 2. it is about where the html is generated, either by js on client or by a script on the server.
felideon 14y ago
(OT: wow I just learned the hard way that in Chrome C-k kills the rest of input at point and cannot be undone. Also, C-a goes to the beginning of the input, rather than beginning of the line, so my C-a C-k habit made me lose my typed-up comment twice already.) Answering your second question sheds light on the first. A better term would be "generating" HTML on the server — the browser is obviously in charge of rendering. In Rails for example, you can have ruby code in an ERB template which the framework compiles to HTML. Hence, the HTML is "dynamically" generated (on every request). The opposite of dynamic is "static" where the HTML is either written by hand or generated just once (like Jekyll) rather than on every request. In either case, as a sibling comment mentions, an actual HTML file is served. However, thanks to JavaScript development maturing and JS engines getting faster, a lot of functionality that used to be done mainly server-side can be relegated to the client. I personally wouldn't use the phrase "static client" much, though. (Edit: Problem with "static client". To me a 'static' site means that it has no communication with a database, such as marketing sites or statically-generated blogs. 'Client' is too ambiguous as it's not necessarily a browser. curl is an HTTP client, for instance, and a JavaScript-driven "single-page application" would be pretty limited via curl.)

dougk16 14y ago

I do think this is the immediate future, especially as we utilize typed languages that compile to JS in order to create more complex applications than are feasible with JS alone. I also think that there will be a swing back to an almost complete server-centric model after that, where all logic and rendering will take place on the server and be streamed to extremely dumb clients...like TVs with basic touch input. This will require a pretty intense infrastructure, but with some nice perks for hardware/software developers. For one, absolute control over an application...bump versions any time you like, easy access to debugging information (crash reports, etc.), watch user usage in real time, on and on. Hardware will also be insanely cheap. Users benefit from the practical equivalent of having a top-of-the-line computer embedded in their smartphones.

Osiris 14y ago

The product I'm working on right now is taking this approach. We're upgrading a legacy system. In doing so, we're writing a REST API and the components that we replace are all built to use the API rather than the old legacy data layer. The goal to to completely replace the application with an API and several UIs, including a full web UI, a mobile UI, and also 'embeddable' UIs. The API also serves as an integration point for other products in our suite. That allows us to scrape a dozen different SOAP services that are targeted to specific integrations and have those other products all utilize a single API that can do anything that the full product can do. I'm really happy with this architecture.

yycom 14y ago

That's not static. That's client-side dynamic. Words have broadly agreed meaning, despite what you or Humpty Dumpty may think.