And if you already have a better solution, or your solution requires an even more complicated set of tooling, just add `--no-gulp` and it won't bother you.
How else is the framework going to handle/bundle these two parts together? There is so much code already out there that works for developing rich frontends that it seems silly for a "framework" that is trying to handle everything for you wouldn't handle that.
We made an asset pipeline in Go (aptly named pipedream, and it turned out to be one), our original plan was to use this instead of requiring an "external" dependency for asset management. We got to the point of handling all the different combinations of compilers and we were forced to pipe to them on the command line because there are no Go library implementations for most of these. Once we started doing this the problems became apparent. The interfaces for these tools on the command line are not very flexible in a lot of cases, and they wildly vary in implementation and flow. All the tools that you want to use to mess with Javascript (typescript, uglifier etc) have significant advantages when able to be used as a library instead of a standalone compiler. They're meant to be used like that and when we tried to break it into something nice based on "compilers" and "minifer" binaries, the dependency handling became a nightmare, recompiles became inevitable, and all this other fallout because the tools that are created for JS are all written in JS and there was no great way to bridge that gap and use them like gulp can/does.
To summarize why we failed with our pipedream efforts the biggest reason is because the command line interfaces to these compilers left so much to be desired. They all want to be their own recompiling watchers like typescript, and they don't think about pipelining. Gulp manages to pull it off by using their libraries, but you can't do that outside of JS.
I also want to state that I think the hate is overblown in our use case, once it's installed it's out of the way and you never have to worry about it. It's automatically taken care of by abcweb and as someone who isn't a fan of javascript or node I've had no problems with it and have been able to appreciate it for the work that it saves me.
The decision to use gulp didn't came lightly, but it happened to be the best option out there. We've made it entirely optional though `--no-gulp` if people want to try to build the dream like we did. Maybe they can succeed where we failed.
We realize that some people may not enjoy having a NodeJS dependency so we've made this entirely optional (abcweb new --no-gulp), however we highly recommend using it due to the conveniences it provides.
The other big thing is that it scaffolds out the application for you. This saves you additional time on top of the package selection by providing the glue between all the packages. If we were to make a "production-ready" application using Gorilla (meaning does logging, ctrl+c graceful shutdown, etc. etc.) hello world - abcweb would do it in 30s, whereas to build it all out by hand using Gorilla as your starter toolkit would take hours.
On top of this, you get a lot of additional features that require a bunch of work to stitch together too:
* abcweb is coupled with an awesome ORM and migration tool, and has a bunch of other useful commands.
* automatically rebuild your go app on change.
* automatically run your migrations and testdata sql against the test database when running `go test`. Starts with a clean slate every time.
* easily build and deploy with `abcweb dist` command and its various options.
* flexible configuration management, utilizing command line, env vars and config file all at the same time. You can add additional custom configuration and it will _just work_, we've made this really easy.
There are a lot of other things too, but the feature list can already be seen on the github. :-)
Too bad they didnt collaborate to make a single project better.
Building a web framework is one of those things everyone seems to try. Along with writing a CMS and/or message board.
I have no issue with the NIH mentality here just so long as the developers are realistic enough to accept that their pet project might not amount to anything significant in the wider community.
Mark chose to combine packages such as gorilla/mux into buffalo since they are popular, solid choices for most use cases
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.
> Install NodeJS
o_O
