| > Too bad they didnt collaborate to make a single project better. To my knowledge I started working on this project before buffalo started development (buffalo's repo dates to December, abcweb dates to October). Maybe it was being worked on elsewhere before then? I'm not sure. By the time I actually heard about Buffalo when it was announced on Reddit I was already mostly finished with abcweb. There are also some key differences between the two: * The packages used are very different, they're using Gorilla toolkit but we're using various different packages to cover all of the features that toolkit has and I'd argue our package choices here are better. Chi instead of mux, our own sessions library which I think has a nicer interface but it has less storer implementations. We have cookie, disk, memory and redis storers but if you want something else you'd have to make the storer yourself using our interfaces. We use context.Context stdlib instead of gorilla/context. Some other package related differences include: Integration with a fully featured database ORM with strong relationship support, zap instead of logrus and Gulp instead of Webpack (I'll elaborate further on this in a minute). * To further elaborate on the router and Gorilla differences: When gorilla was first conceived, it used a global map to store things for gorilla/context. gorilla/mux used this to store routing parameters when a handler was hit. This allowed it's famous "standard library compatibility" that everyone viewed so highly. The tradeoff for this compatibility is that it came with type unsafety and big performance penalties because the global map has to be locked - this causes lock contention on busy sites. It also made it impossible to have isolated unit tests for a single routing method since you had to create an entire stack with a router in order to call your handler. Compare this to a router like httprouter which had much better performance; the drawback there was that you had to change the signature of the http handler, and therefore compatibility with other handlers and middleware took a hit. When Chi came along and promised great compatibility by not changing the signature via context.Context inside the std net/http libary's Request struct, as well as very reasonable performance the choice to switch was obvious. Gorilla's prolific use of gorilla/context throughout their libraries and this global map was one of the reasons to look elsewhere, they've since corrected the problem but these are the historic reasons that made other libraries so much more appealing. * We generate more code and more structure. This has pros and cons. The pros are: Easier for beginners to build from, no decision paralysis regarding where to put things and how to tie things together. It's also easier to change things because we expose functionality. On the other hand it doesn't look as clean for small projects. * We automatically vendor for you (using dep). I'm not sure how Buffalo handles breaking changes to the libraries they're using, but those aren't a concern for abcweb. * We use Gulp instead of Webpack. I think Gulp is a lot easier to learn than Webpack is, even if you've never used Gulp before you can figure out how to do things almost straight away just by looking at the gulpfile. Webpack is cleaner, but more complex. If you've used Webpack before and enjoy it then perhaps that's a better fit for you. We were aiming for people who have used neither, so we went with the simpler option that can handle all of the things people might throw at it. * ABCWeb automatically migrates and executes your testdata.sql when running `go test`. To my knowledge Buffalo doesn't have this feature and it's one that I would need to create manually to write thorough unit tests. * ABCWeb has a very flexible configuration management implementation. If you want to add new members to your generated config.toml file you can do so, and load them easily using the existing library. No need to create and load additional config files, it can all be in one place and it can utilize as many environments as you wish to create. There are also some things that Buffalo has that ABCWeb does not: * Buffalo bundles your assets into your binary, we originally had this but our implementation of it made things messier so we opted just for optional zip instead. It's nice to have, but not necessary in my mind. In saying all the above, the Buffalo guys have put a lot of work into their project and Mark has done a great job. We're actually using his refresh package to automatically rebuild the go binary for the `abcweb dev` command. |