[grey-area]

But in 2013 do I really want to use server side HTML tempalating?

Many people do yes. It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar before I even see the content as json is turned into html, and I'd rather all the logic was server side and a flat page was served to a web client (browser).

I don't agree doing rendering server-side necessarily means a significant performance cost, or is harder to maintain or slower to develop, why do you think that is the case? Caching and a server-side framework can make things far faster and easier, depending on what you are doing, and raw speed of rendering is not often an issue nowadays anyway.

I'm not sure what the test you pointed to there was showing, because using Go to output json could be done with a framework too by just bypassing the framework, in exactly the same way. It hardly seems a relevant test, and there were other issues in those tests when I looked at them previously - like comparing wildcard routes in one test to hard coded ones in another. Comparing bare JSON production with go to JSON production with webgo (do people use webgo?) is hardly very useful or a fair comparison. It would be trivial to make those equal in speed and I suspect the diff will just be down to different routing and/or template rendering. In addition, I don't want clients to see JSON, so the rendering speed of that is pretty irrelevant, what matters to most people is when html finishes rendering.

It would be interesting to hear the reasons behind the string of assertions in your penultimate sentence, are you sure all types of app would benefit equally from your approach? Can you describe the advantages as you see them to this approach?

[voidlogic]

>It may seem old-fashioned but when I load a web page I don't want to sit looking at a 'loading' message or a progress bar

This is how bad implementations look to users, consider something like Gmail as a counter example however...

>would be interesting to hear the reasons behind the string of assertions in your penultimate sentence

Sure:)

>are you sure all types of app would benefit equally from your approach?

Of course I am not, I didn't make a that claim. I think most typical applications benefit, it has worked well for me. I was asking questions to understand the point of view I don't hold-

> Can you describe the advantages as you see them to this approach?

  In this approach: 
  Performance:
    1. Most assets are (server side) static
    2. They are pre-gzipped and stored in memory using a little reusable code I wrote.
    3. They are extremely cache friendly
  Better scaling:
    1. Only a fraction of the previous work happens server side... You using your users compute power.
    2. You are transfering less data.
  Faster to develop/easier to maintain:
    1. This way you have two differnt apps that happen to talk to eachother. This makes it easy to replace one or the other.
    2. Responsibilities are clearly defined. This makes brining new people up to speed easier and makes thingse asier to test, debug, etc.

[grey-area]

Thanks for the comments, it'd be easier to read if they weren't styled using pre!

Of course I am not, I didn't make a that claim.

Sorry, I should have phrased that differently as something like - perhaps not all types of app would benefit equally? I wasn't trying to put words in your mouth. I do think it's a little early to start asking why anyone would use server-side logic any more, there is room for both approaches :)

Perhaps if you are serving data which is text-only, static and fits well into json as you describe, and don't mind coding in Javascript, client-side is a better fit. If you have a lot of server-side data and editing/auth requirements (more of a CMS), and depend on heavily nested templates etc, server-side may be a better fit, though I'm sure it's possible to handle every type of website in theory using either system. There is also the question of which language you prefer to work in - personally I'd rather keep JS use to a minimum, as it's pretty gnarly.

Re the separation of concerns, yes this is a valid point and is something you gain from serving an API if you have a complex system, though it is possible to have a back-end behind a traditional web framework too, with one side being the API serving json or whatever and a separate user-facing service serving HTML.

I don't think speed or caching are a big problem with server-side frameworks nowadays though, and I'd rather use a language like Go than JS to produce web apps. Out of curiosity, which client-side frameworks are you using?

[voidlogic]

I think we agree more than we disagree. Maybe we just differ on which approach is our default one. I dislike JS as well and will be switching to Dart on the front end when I feel it is ready.

>though it is possible to have a back-end behind a traditional web framework too.

Sure I think you get a lot of the maintainability pro's this way, but loose on some of the performance ones.

I mostly write systems software (in Go), but when I write webapps I use angular.js (frontend) + Go (backend) + One of many datastores (ex MySQL, Postgre, LevelDB etc)

[justin66]

> This is how bad implementations look to users, consider something like Gmail as a counter example however...

Gmail isn't a counterexample to the "loading" message thing. It manages to be slow on hardware and network connections that are incredibly fast.