6 ms·

I would love to hear why I would want something like this, or revel, or goweb, over: angular.js + Go web-service (net/http + Gorilla).

redneckbeard 13y ago
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.
- voidlogic 13y ago
  > 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. 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&test=json&l=cn4 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.
  - recuter 13y ago
    You have a point, no pun intended. Focusing on serving up tidy endpoints does away with a lot of complexity (I call shenanigans on the performance argument, especially if you're using Go and not Python/Ruby) - the only unsolved technical debt with this approach would be making GoogleBot happy. If you don't need to care about making crawlers happy this can be great... 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?
  - grey-area 13y ago
    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?
codegangsta 13y ago
If you don't want it then you don't want it. Both Gadget and Martini pretty clearly outline the value that they bring to the table. If that value proposition does not win you over then these frameworks are not for you. I personally have seen a great improvement in code simplicity, readability, and overall DRYness when projects are written using Martini. Choosing a framework isn't about following some sort of socially acceptable way to build your web apps. Just build them! If a framework solves a problem for you then use it, otherwise keep using net/http handlers.
- voidlogic 13y ago
  I'm glad you like these frameworks, and I not telling anyone not to use them. Like I said, I was just interested in hearing why I would want something like these frameworks which focus on server side templating, over a HTML/JS frontend + webservice approach. If you are just writing a webservice I think using Gorilla in addition to net/http is pretty much perfect.
  - codegangsta 13y ago
    shameless plug. Martini doesn't even have html template rendering out of the box. I originally built it because I wanted a better experience building webservices for Angular frontends :) https://github.com/codegangsta/martini https://github.com/codegangsta/martini You and I sir, are on the same wavelength
    - voidlogic 13y ago
      Interesting, I'll have to play with it. Thanks for sharing. You should consider adding benchmarks to that it is easy to compare martini to net/http. This will let you keep an eye on performance as you work on it and accept pulls.

redneckbeard 13y ago

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.

voidlogic 13y ago
> 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. 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&test=json&l=cn4 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.
- recuter 13y ago
  You have a point, no pun intended. Focusing on serving up tidy endpoints does away with a lot of complexity (I call shenanigans on the performance argument, especially if you're using Go and not Python/Ruby) - the only unsolved technical debt with this approach would be making GoogleBot happy. If you don't need to care about making crawlers happy this can be great... 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?
- grey-area 13y ago
  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?

codegangsta 13y ago

If you don't want it then you don't want it. Both Gadget and Martini pretty clearly outline the value that they bring to the table. If that value proposition does not win you over then these frameworks are not for you. I personally have seen a great improvement in code simplicity, readability, and overall DRYness when projects are written using Martini. Choosing a framework isn't about following some sort of socially acceptable way to build your web apps. Just build them! If a framework solves a problem for you then use it, otherwise keep using net/http handlers.

voidlogic 13y ago
I'm glad you like these frameworks, and I not telling anyone not to use them. Like I said, I was just interested in hearing why I would want something like these frameworks which focus on server side templating, over a HTML/JS frontend + webservice approach. If you are just writing a webservice I think using Gorilla in addition to net/http is pretty much perfect.
- codegangsta 13y ago
  shameless plug. Martini doesn't even have html template rendering out of the box. I originally built it because I wanted a better experience building webservices for Angular frontends :) https://github.com/codegangsta/martini https://github.com/codegangsta/martini You and I sir, are on the same wavelength
  - voidlogic 13y ago
    Interesting, I'll have to play with it. Thanks for sharing. You should consider adding benchmarks to that it is easy to compare martini to net/http. This will let you keep an eye on performance as you work on it and accept pulls.