https://code.google.com/p/rsc/source/browse/devweb/

Just trying to express the same redneckbeard said: until it is a very thin bottleneck, this should be no problem.

Lots of people have abandoned Rails for Sinatra, or Django for Flask. That's totally cool, and there are good reasons to do so. There are also very good and obvious reasons to use something that further abstractions common patterns if the software you are building conforms reasonably well to those patterns.

But in 2013 do I really want to use server side HTML tempalating? Why not just connect a webservice to a HTML/JS presentation layer like I am suggesting? If all you are doing is building a webservice then the abstractions beyond net/http + Gorilla are not buying you much IMHO, but they do come at quite a performance cost: http://www.techempower.com/benchmarks/#section=data-r7&hw=i7...

My first couple Go web applications did things the html/template way and were structured on the way I used to go JSF applications- but since I switched to the above approach my projects have been better performing, faster to develop , better scaling and easier to maintain. As we all know, we seldom get all those things in one technology choice without trade-offs.

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?

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.

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?

>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)

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

On the other hand, the complexity you're punting on needs to go somewhere, so now you'll need to muck about with something like Angular to make up for it. Difficult choices. It kind of continuously feels like we're on the edge of Nirvana with this stuff and something perfect in its elegance will emerge. I'm only 24 but this seems like a dangerous siren song to me... maybe we should all know better by this point, eh?

1) I didn't want routes in a text file. This is whiny, I know. Just a personal preference. 2) Go is the only programming language that has held my attention long enough to actually finish a fairly usable framework. Writing a framework is a good exercise in software design, so I felt like I had to use the opportunity.

I ask because I am looking to put my weight behind a framework and am undecided, but not at all attracted to Revel...

I've started writing subpackages as they become important to me. The most useful thus far is probably gadget/forms, which is very much inspired by Django forms. I prefer a data validation layer that is independent from or at least very loosely coupled to a model layer.

Please note that the microbench was "rigged" by the author of Node when he was first presenting it several years ago (spelled out in the article).

If you need a tl;dr, it's this: I don't care for JavaScript as a language. Many make the argument that JavaScript should be adopted widely server-side because of its speed. I assert that languages should be evaluated not only for performance but for maintainability, feature sets, standard library, etc. Go provides a great combination of execution speed, development speed, and ease of maintainability.

The default template language is also really archaic and no one has created a solid alternative yet that's actually well tested and used by the masses.

It might have good execution speed and the language itself might be nice but the only thing that matters is going from point A to point B. Go will not get you there faster than other languages and the execution speed is a non-issue for pretty much every platform (even rails) if you use tools available to you to their fullest.

P.S., I compared Go to Node almost a year ago and even wrote a mini framework for Go to resemble a smaller version of Express. I eventually just said fk it and stopped because the gains were not even close to being worth it.

The word "rigged" in your original comment implied dishonesty on my part. I just wanted to clarify that the JS code used in the microbench was Ryan Dahl's, and mine was just a port to Go. I was merely giving Go the same task that he did.

I don't want to spend most of my time solving boring issues. I want to spend most of my time writing features for apps I make. Being productive makes me happy but everyone has different happiness triggers I suppose.

I see performance as a somewhat solved problem in 99.999% of the cases so to me a language is not even worth looking at anymore if that's all it offers. I'm not fortunate to be involved in the other 0.001% where easy to do caching might not be enough.

I didn't mean to imply you were dishonest. I just wanted to point out that sending out 1MB responses is kind of silly.

It took me like 2.5 years of messing around to finally realize all I care about is being able to take an idea and turn it into working code that's maintainable and scales good enough for the time being.

The gorilla toolkit's APIs are inadequate and it seemed like quite a few people agreed too because most of them said they rolled their own solutions to do things that certain gorilla libs did but with a more intuitive and friendly API.

Go really isn't that young either. It's been what at least 4 years now? There's no excuse. It's not like the language is 6 months old.

As for re-inventing stuff, it's more so go's ecosystem rather than revel's shortcomings although revel does have its own shortcomings if you were to compare it to something like rails and not express.

Revel seems to be somewhere in between rails and express in terms of opinions which is fine but if it's going to make me less productive then I'm simply not going to use it.

1.5 if you count from the first stable release. Which IMHO is what matters, before was just a experiment with a lot of uncertainties. It took ruby 9 years to arrive from 1.0 to Rails. They were other times, sure, but still.

I still consider it very young, or at least I don't know of any other younger language with a better ecosystem.

> Revel seems to be somewhere in between rails and express in terms of opinions which is fine but if it's going to make me less productive then I'm simply not going to use it.

Well, everyone has their preferences, certainly in Go there are not many choices so is not for everyone. But I'd keep an eye on it. Things can change very quickly.

9 months to me is a huge amount of time. I don't want to have to wait years to be super productive. I want to be super productive right now and by using other platforms I can be.

For a new viable web platform to be accepted it needs to really explode in popularity. It has to offer MASSIVE gains.

Look at node, it offers performance and also offers the benefit of using the same language on both ends. That's pretty neat... maybe, but I think you would at least agree with me that node's popularity and growth has been unmatched. Even so, it's still quite far behind rails and I don't think it will catch up.

I'm not some massive rails fan boy either. I only started using it when 4.0 came out because the ease of caching seemed interesting to me and I was looking for an excuse to go from node/express to something more opinionated just to see if it was more productive.

Of course I agree. But node is an unique case, since javascript is not exactly new, and had a trillion people using it when node appeared. You can not expect that to happen again any time soon, unless all main browsers start supporting client-side PHP or something crazy like that.

Go is not 'there' yet, sure, and maybe it'll never be. But its growth can not be judged by node's standards, no really new language could compete then.

For a new language is growing quite good: http://www.google.com/trends/explore?q=golang#q=golang&cmpt=...

Of course this doesn't mean you have to use it, but IMHO it can not be regarded as a failure in anyway.

Luckily, Go has a decent head of steam behind it, so when I revisit it in a few years that should be a solved problem ;).