It also has HTMX [1] integration to create slick/modern UI behavior without writing any JS.
[0] https://github.com/mikestefanello/pagoda [1] https://htmx.org
Go community has been pretty "anti-framework" (AKA "just use net/http" when it clearly doesn't solve every problems..., "don't put request scoped variables in context" when it's the very purpose of that interface...) and there was a lot of drama around some framework creators, unlike any other web language community I have seen by the way (remember Martini and the insane backlash? Iris and the constant drama, was that Iris, I don't even remember the name...) so it will be pretty interesting to see the reception for that framework.
One advice to the author, congrats but don't call your framework "framework", it's like the go community hate that word, just say "a set of useful libraries to help web development", it seems like euphemisms are easier to swallow for some...
I've started using Go at work so definitely interested in using this for side-project web apps to keep me in the Go mindset.
I started my programming career after following the Rails how to make a blog in 15min youtube video. Always a good choice.
I have been working with Go professionally since 2015 and quite often it makes me feel frustrated due to lack of full-stack web frameworks.
I was thinking to do something like your project, but with focus to full SSR/zero-js. Lucky me, you started it first . Maybe be in some things I will prefer different approach, however, your project already released (and it's excellent) while mine only in prototype. After I read the documentation in your project it feels like you really stepped on a lot of minefields. Great job!
One thing is still bothering me though (or maybe I missed it in docs): how is Bud dealing with relative links? Very often JS writers forgetting about the situation when the application could be served under different root locations. Does Bud have helpers to construct relative URLs without relying on user-provided server url? (I made PoC for that - don't use it in production https://github.com/reddec/gin-template-manager/blob/eb09f4e8...)
I see views and controllers in the documentation, but the only mention of model is that "model" is a reserved directory. What are your plans for models and persistence?
The last bit about single binary is quite interesting. I could easily deploy app to my raspberry Pi without worrying about bundling things. I know Go can do this but it's nice that framework aligns with Go philosophy.
I've been using Kenny Grant's Fragmenta[1] for past 3 years and I haven't had need for anything else because I like SSR with Go and aim to keep JS as minimal as possible. I assume you're trying to address the need of those who want a Go back-end but with modern JS front-end?
I hope that you get to answer the queries in other comments regarding the design decisions reg CSR & V8 while using SSR.
i come from a ruby, js and python background using frameworks like: react, django, rails, etc. always wanted to excuse to use GO and this might be it!
[0] https://community.cloudflare.com/t/support-golang-natively-f...
Can you elaborate how you were spoiled by Go and don't want to go back to writing PHP?
Constructively speaking:
Hacker culture could benefit from less frameworks to more low code/no code platforms (which is a space with more fertile ground)
_shameless plug_
I kind of made an almost similar thing can generate custom boilerplate for backend servers a while ago -> https://github.com/tompston/gomarvin
Yes, Go has nice standard templating and HTTP serving libraries, and nice dependency management. These are all important features for a web framework.
No, it will never be productive as its competitors in the web framework space, because you simply cannot write expressions like `order.customer.region` that intelligently hit the database, because you can't override the dot operator. Instead you have to write unreadable crap like `regionController.Show(userController.Show(order.customer).region)` which is infinitely less "productive" than the former, for obvious reasons. Oh, you can `go generate` the *.Show definitions from a simple struct definition (or with 1.18 generics)? Too bad the final product is still unusable!
Use Go where it excels and connect it to your Ruby/Python/Typescript web backend over gRPC or HTTPS.
I couldn't find anything describing the paradigm used for the JavaScript frontend. From the video, it looks like things are fully server side rendered, i.e. no client side routing as-in SvelteKit or Next.js? Are the Svelte components hydrated+interactive after page load? In my experience so far with SvelteKit and other SSR+SPA frameworks, there are too many tradeoffs with hydrating then opting to CSR for subsequent navigation. I like the browser's built-in implementation of navigating between pages because it preserves things like mutations to the document and scroll position out of the box, with no additional JavaScript. If you collapse a comment in this thread, navigate back to the home page, then use your browser's back button, the comment you collapsed should still be collapsed. In my experience with SPA CSR, you'll need to track and restore the JavaScript state driving that collapse on your own (a combination of the window.history object and CSR hooks), since navigating back to the page is a full client side re-render of the page.
I've found Svelte+React have good support for TypeScript, especially for guaranteeing the types of props passed to components, are there plans to support this? With controllers in Go and Views in Svelte/React, is there any way to help with correctness of data passed as props to the Svelte components?