redneckbeard

Use of gadget/template is totally optional. The _primary_ use case for Gadget is RESTful web services. That's why you can route to a resource, and have the appropriate controller methods hit by the correct HTTP verbs. The reason to provide support for HTML rendering on the server is no different than providing plaintext rendering: it's really really easy. It's almost free.

Recompiling and restarting the server has yet to become a bottleneck in development for me, or at least it hasn't caused enough friction or irritation to compel me to add something using fsnotify or other solutions. If you told me that you were very interested in using the framework but the lack of this feature was a barrier to adoption, I'd definitely think harder about it.

I just don't understand the argument that we should all just use HandlerFuncs for everything. Python and Ruby have stdlib HTTP facilities that are pretty good. They aren't nearly as nice as net/http, but you could totally build websites with them. People still have written lots of web frameworks, because it makes their lives easier. It lets them express programs in a simpler, higher-level way. I feel like this is even more valid now in 2013 since nearly anyone who's building websites has done so with one of those high-level frameworks, and they expect a similar experience.

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.

I would like to go something like "batteries included but not installed." The User interface I have now is a good example of what I mean -- I would prefer to keep everything built around implementing an interface, but it might be nice to provide an "official" authentication implementation as a subpackage.

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.

Two reasons:

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.

My understanding is that many people try Go and decide they don't like it, as you did; at the same time, many have experiences that are similar to mine and they embrace it. To each his own.

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.

Original author of the post in question here.

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.