Live data from Hacker News

Build Your Own Web Framework in Go

nicolasmerouze.com

31–37 of 37 posts

Re: Build Your Own Web Framework in Go

#31
post #10

The question is: Should you build a web framework in Go?

In my opinion, Go is great to make REST APIs, but for full-fledged frameworks (with server-generated HTML views) Rails will always be light years ahead for the developer productivity and happiness. That's why the article focus on a web framework to make REST APIs.

That is why Go frameworks need to be made though, the process of evolution will produce varying and improved frameworks. Flotilla(https://github.com/thrisp/flotilla/tree/develop) was started bring something Flask-like to the workflow at Thrisp. Its not rails and intended to be a micro framework, but aims for full-fledged.

Re: Build Your Own Web Framework in Go

#32

The original source talks at length about why you shouldn't use the Martini web framework, and links to another post where Jeremy Saenz (Martini's author) more or less disavows his creation ( http://blog.codegangsta.io/blog/2014/05/19/my-thoughts-on-ma... ). That's an interesting read, I'm surprised that I missed it earlier this year. I'm also surprised to read that Jeremy has written a more idiomatic successor frame…

I think you're being hyper-sensitive.

I mean it's a common drink.

Re: Build Your Own Web Framework in Go

#33
post #28
post #18

Earlier quoted context omitted.

> If you care about performance, nothing beats tuned prepared stated going through the wire and stored procedures for heavy duty work. for "heavy duty work",sure.Now write your own hydrators,again,again and again,and let's see how maintainable your code is. Now the fact is ,it's impossible to write an ORM in Go,without throwing all type safety,just like Java pre-generics,you'd cast and down-cast to Ojbect.

I don't even know what an hydrator is!

A hydrator populates an object from other data.

Re: Build Your Own Web Framework in Go

#34
post #29
post #20

Earlier quoted context omitted.

ORM works great for basic CRUD stuff like typical web applications. You don't have to use it in every part of your application.

Until you have the whole world banging into your site.

Not a problem that most people will have. If for some reason you do then hopefully you'll be able to monetize that popularity and hire someone who's actually really good it. ORM's are not optimal but they do let you make something quickly if you're not well versed in writing optimized queries, stored procedures, etc. For people like me dropping ORM's seem like a premature optimization.

Re: Build Your Own Web Framework in Go

#35
post #3

Yes, do make your own framework. And don't leave any documentation either. Hell, invent your own language while you're at it. It'll make the "should we throw this code out" discussion WAAAAY easier in five years.

I wrote plenty of things nobody but me will ever use, and I'm happy I reinvented lots of wheels along the way. I learned, I had fun, and I still like the results. Not all programming has to take place in a corporate cog-style environment, and not all articles about programming have to justify themselves in that environment, or for sites with millions of visitors. If it's not good for your job, don't use it for your j…

Writing a custom framework is cruel to the maintenance programmers down the line. Whoever works the project after you is stuck with a buggy undocumented framework.

Re: Build Your Own Web Framework in Go

#37
post #35

Earlier quoted context omitted.

I wrote plenty of things nobody but me will ever use, and I'm happy I reinvented lots of wheels along the way. I learned, I had fun, and I still like the results. Not all programming has to take place in a corporate cog-style environment, and not all articles about programming have to justify themselves in that environment, or for sites with millions of visitors. If it's not good for your job, don't use it for your j…

Writing a custom framework is cruel to the maintenance programmers down the line. Whoever works the project after you is stuck with a buggy undocumented framework.

Maintenance programmers solely dictating what is cool or allowed is cruel to all programmers everywhere. This is right at the start of my post:

> things nobody but me will ever use

Plus, I imagine I'll rewrite for example my CMS from scratch and/or in a different language every 5-10 years either way, taking a good hard look at what I really ended up needing, and how to best structure it. If I ever used a framework for that, I'd end up forking it and throwing out the 90% things it has which I don't need, cutting out redundant layers of indirection etc., and then what? The next version of the framework comes out, and I do it again? Or I just give up and just take on the bloat? Nah. Not worth it for me.

Post reply on HN