Pushup: a new compiler for making web apps in Go | Hacker News Reader

Pushup: a new compiler for making web apps in Go

github.com

215 pointstodsacerdoti119 comments

Pushup creator here. We're interested in feedback on the design. Pushup introduces a new lightweight template syntax that mixes Go code and HTML in the same page; pages are then compiled down to pure Go, relying on the net/http package. Pushup uses file-based routing, so adding a page adds a route to your app. The template language has an "inline partials" feature to make it easier support for modern hypermedia libraries like htmx in mind. Would love to know what the Go web development community thinks.

Here is a short demo of Pushup in action: https://www.youtube.com/watch?v=nkyiATkZ4Js

Also try to give usable web app ( todo ? ) hostel somewhere if possible.

Yes, we need to do that - I'll populate them here eventually https://pushup.adhoc.dev/docs/guides

Do you have any hosted demos?

The main project site is a Pushup app: https://pushup.adhoc.dev (look in the `docs` directory in the repo for the source code for the site)

There is a small demo of the inline partials feature here (click on the "view the Pushup source for this page" link at the bottom): https://pushup-htmx-template-fragments.fly.dev/demo

I’m Finnish. The caret is not always easy to type in my experience on international keyboards. Not sure what the added value is of creating yet another convention here, as there are so many already with each new templating language.

That's good feedback, thank you. My US-centric eye didn't consider that.

Same on a French keyboard, trying to type `^if {` will result in `îf {`

Oh yes it's pretty hard to type on a German keyboard as well. In most editors you will need two keystrokes.

But don't you need 4 keystrokes for the common alternative, {} enclosed template expressions? Same as french, nordic, and probably lots of other european intl layouts.

(Or even better against the {{ }} ones requiring 6)

"{" on a french keyboard is two key presses but at the same time (alt gr and 4), while ^ is two key presses one after the other, which makes it a bit slower. Most editors will also insert the corresponding } when you create a {. That makes in my experience {} faster than ^ and {{}} as fast as ^.

{} is still a common complaint in my circle of programmer friends and everyone has seriously thought even once about switching to an english/american keyboard, but then there's the issue of switching back when writing stuff in french (é by itself almost ruins the idea).

I use a Spanish keyboard but with US layout on top. I normally let autocorrect deal with special Spanish characters, but just switch layout if I’m writing something longer.

For German devs it makes sense to use a no dead keys keyboard layout IMHO. You rarely need the accents anyways and it saves a lot of time when coding. I made the switch a long time ago and don't regret it. For the occasional word like "Expose", I just leave off the accent and that's that.

same in french. it's a dead key on our keyboard, so it's basically two keystrokes instead of one to type it.

to be fair most special characters are behind AltGr on azerty, soooo...

Interestingly, there's no such problem on Cyrillic keyboards despite being a totally different alphabet. We only need to switch the current layout to English which is what we do all the time anyway.

Not despite, because. You need to switch to type in any other alphabet, so you switch to English. German, French keyboards work perfectly well for English, it’s just that the symbols are not as easy to reach.

Personally, I use and love EurKEY [0] as I rarely type in German anyway and rather optimize for coding.

[0]: https://eurkey.steffen.bruentjen.eu/

Admittedly ^ on a US keyboard also involves two keys.

I spent a lot of time in C# and ASP.Net, and I was struck by how closely this resembled Razor syntax, but with ^ instead of @. Switching to @ would make it slightly more familiar to that cohort, and it might even be possible to build on some Razor-parsing code for editor plugins or whatever.

I was inspired in part by Razor, although I'm not a C#/ASP.net developer. I just liked the way it looked and worked from examples I saw.

I actually started with @ [1] but changed to ^ for 2 reasons: having to escape for email addresses (although in retrospect maybe it's not such a problem), and the admittedly cheeky ^ being the "up" in "Pushup" :^)

[1] https://github.com/adhocteam/pushup/commit/04aa00bb5401bc93b...

OTOH I have an actual Finnish keyboard and caret is simply Shift-umlaut (the key has a caret over a pair of dots).

You still need to press space after that.

Ah. True dat.

Many templating engines allow to customize the delimiters. Quite useful sometimes.

Hey cool!

Caddy plugin? :D I might be quite interested in this.

We talked about exactly that! Yes, let's

"Pushup uses file-based routing, so adding a page adds a route to your app."

Make sure to have a clean way of escaping that and having some richer concept of how to route. This was the original way routing worked, back in the ASP (not ASP.net, the predecessor), CGI, original PHP days. We moved away from it for good reasons. It works well early but has scaling problems over time.

I'm not saying don't have it as a default per se... just make sure you have a "if you need to do something else here's how to override it".

I also strongly advise against trying to guess what the overrides might be and building special cases for "the three things I think people may need to do beyond thsi". I've got a router in my system that looks at client-side TLS certificates if it comes from certain IPs and uses LDAP authentication if it comes from certain other IPs, and does different things if the auth fails for each case. You'll never be able to guess all the possible ways people want to route. You need to make sure you don't lock the users into this so hard they can't escape except by leaving your framework entirely.

Edit: Also, I didn't look into this deeply, but if you throw away the ability to have middleware on specific routes you've really caused a big problem. The Go ecosystem is fairly dependent on that.

I have the same instinct (JSP / JSF had the same concept) but I must say, making pages as files in next.js is really nice. You can have all your dynamism within them, but having a simple way to do overall routing is lovely.

It is nice. It is easy. There's a reason we started there.

Then, suddenly after a certain amount of scaling, it isn't. And it's not like that's an impossible situation either, but you end up with all the consequences of building a framework to do X and then having to build an inner platform[1] to do some other Y inside of X instead.

[1]: A technical term: https://en.wikipedia.org/wiki/Inner-platform_effect

Sure. It's a tradeoff either way - ergonomics for common cases or not. I imagine in your case you're constructing lots of custom logic anyway, whether it's in an API gateway (or similar) component to put the auth logic before the application, or put the logic in some before_request handler in the web application.

Curious if you're explored the new `app` directory (beta), which includes a new routing system in Next.js? Open to feedback: https://beta.nextjs.org/docs/routing/fundamentals

I haven't, but I've just had a read. It looks well thought through and opinionated, which is what I'd expect and want from NextJS.

Time will tell if it misses a load of cases, but I can't think of any. I'm not doing any UI work at the moment, and while I wanted to introduce NextJS to my new team's new project, we tried it but couldn't get it to work with our slightly tricky component tech (StencilJS). I think that's a StencilJS <-> ReactJS issue rather than a StencilJS <-> NextJS issue, though.

Next.js routing limits have been for me the number one reason not to use it unfortunately.

Can you share more? With Middleware, you can run any arbitrary code to control routing: https://twitter.com/nextjs/status/1610663442825854980. And with the `app` directory (beta), we're reimagining the Next.js routing system from the ground up: https://beta.nextjs.org/docs/routing/fundamentals.

Not the author but for me it’s insane that the router doesn’t do http routing on verbs but rather leave it to be repeatedly reimplemented in every single page (and the fact that you can’t do simple things like what’s been available in rails for over a decade with resources).

Can you give an example of routing based on verbs?

https://hexdocs.pm/phoenix/routing.html

Understood. This I think is a slightly different way of making a web application - NextJS is built on REST calls and client-side view changes.

If I've understood correctly, your Phoenix example is more like traditional full page request response programming, where you can post a form and get back a whole new web page. Phoenix no doubt has magic to make the whole page not reload, but point being that I think a lot of NextJS's target users are developers who come from a REST + SPA background, and wouldn't think to send some data and get a changed view back. They'd send some data, maybe get a response, update their client side data store and their view would change automatically.

It works the same for JSON/REST in Phoenix though, you don’t have to concern yourself if it’s a GET or PATCH because the correct function has already been called from the router.

Sure, understood. You can (and probably should) have a separate logic/controller layer from HTTP handling. You can do this with either though, I think? Just call a function in another file?

I honestly don’t get all the file routing hype. How hard is it to setup a React Router? It’s like a few lines of code and you get a massively flexible setup, without any lock-in.

At the day gig (old school in house python framework) we used file based routing.

Works great. The few times we need to get fancy mod_rewrite is pretty easy.

The lack of ceremony is refreshing.

> If you throw away the ability to have middleware on specific routes you've really caused a big problem. The Go ecosystem is fairly dependent on that.

Agreed! Pushup pages compile down to structs that implement http.ServeHTTP. And an entire Pushup app is just a http.ServeMux too. So it should be trivial to insert middleware (although there isn't Pushup syntax for that yet), and/or embed a Pushup app in a larger Go app (this is quite possible today).

>It works well early but has scaling problems over time.

How?

Otherwise calling this out as cargo cult. As I remember the main reason we moved to app routing is because of the single process nature of non-blocking async code which was popularized with node / express.

This looks really good. I like the compilation to a single binary. I'm already using Htmx with Flask for routing/templating. File based routing with a page as the unit of functionality sit well with me.

The use of caret to denote Go code is quite clean, but given well formed HTML, could the parser detect anything not inside HTML tags as Go code and thus remove the need for a caret outside of HTML.

I will be trying this out. Thanks for this project.

Love this idea. And I’ve been looking for something exactly like Pushup. Really excited to try it out.

This is very neat, but you are delving into a very complex world, as you are well aware. In your video, you have generated static server side pages, without any JS, where your annotated HTML uses the embedded go to generate static HTML.

This is much nicer syntactically than using the Go html/template engine, but it seems roughly equivalent in expressive power. Are you converting your "up" syntax into go templates with the Go expressions extracted into compiled Go code, referenced be the templates, out of curiosity? If so, the way you've transparently handled interleaving (such as html elements in the for loop) is really cool.

How would your go scripting interact with JS? For example, say that I have a backend API that the fronted calls into. In your design, would I call out into Go to perform the http request, or would I do this in JS? I'm sure both would work - since the Go request would be handled server side and simply slow down static page generation, but it seems like calling into Go might not be the right thing to do for a more responsive AJAX app. Do you envision mixing Up/JS in the same pages? Can I do crazy stuff like use JS to insert a variable (by value probably) into your Go code, or vice versa?

Over the years, I've learned that web front ends are positively bonkers in the kinds of things they want to do, and when you are the developer of any kind of frameworks, you end up suffering greatly if you insert yourself into middle of that ecosystem, since you will be asked to support features that you never dreamed of. If you support them, the framework gets more use, if you don't, the cool kids move onto other things.

I've tried to tackle a much simpler problem with a project of my own [1], which is a backend server code generator to make implementing JSON models more easily from an OpenAPI spec, and I've found that even in this relatively simple concept, the limitations of a strictly, statically typed language like Go end up running into incredible complexity due to the dynamic nature of web frontends and JSON. Outside of trivial strings and numbers, you start running into the limits of the Go typing system.

Anyhow, good luck, this is very cool and it seems like a fun thing to play with.

1: https://github.com/deepmap/oapi-codegen

This looks really promising — at first blush, I like this a lot more than normal Go templating! That said: maybe it's just my bias as someone who primarily works with React, but I'm wondering why not just mimic JSX, which has been incredibly successful and has millions of people who already understand it.

The big missing piece to me here is composability. How can I encapsulate reusable bits of markup, styles and presentational logic? In most JS frameworks, I'd extract them into a "component" (in React, that just means a function that returns JSX). Pushup has "partials," but it's not clear to me whether they're reusable or if that word means something different in Pushup than it does in other templating systems. I see that layouts can denote sections to be filled in by pages, but IMO that's backwards — a page now needs to know details about its "call site".

Using ^ as a delimiter seems odd, but I suppose that's just a familiarity thing. I do wonder though how you handle your example of

    <p>The time is now ^time.Now().String().</p>

without having to backtrack, since that last period is ambiguous in this grammar.

> why not just mimic JSX

Definitely considered that. Might be worth revisiting.

> The big missing piece to me here is composability

You zeroed in on the right things ;^) I have a draft note to myself about pages-as-components. I have some ideas (basically, mimic ASP.net Razor components at the moment). Having a compiler with full control of the page makes this easier to figure out.

> without having to backtrack, since that last period is ambiguous in this grammar.

It doesn't backtrack, it just looksahead at the next token: https://github.com/adhocteam/pushup/blob/main/main.go#L3692

I actually hacked together "JSX in go" over a few weeks a couple years ago, targeting wasm/GopherJS so the code could actually execute in the frontend. It was a really fun exercise in reading/understanding the internals of the go compiler.

https://github.com/8byt/gox

I came across this during my initial research when starting Pushup, very impressive.

When it comes to traditional web frameworks, the most important part is handling regular HTML forms. Reason being, a form is the only native mechanism your customers have to use to interact with your service. Forms are important. Specifically, validation and error handling. I think Laravel does it really well. It's been a while, but Laravel has a wrapper around HTML forms. This wrapper does everything you need: server-side form validation, form generation, flexible error handling that takes care of client error messages, placeholders, input values, css classes for invalid states, you name it.

Does Pushup help engineers with HTML forms?

This plus CRUD pattern - after the submission you want to edit the data usually with a slightly different form.

Any more info on this form wrapper for Laravel?

This is how it used to be - https://laravel.com/docs/4.2/html

I haven't used Laravel for many years. I couldn't find the equivalent functionality in the latest version of the framework, which is 9.x, but pretty sure they should have something similar.

Here's the latest equivalent of those docs: https://laravel.com/docs/9.x/blade#forms

Regular HTML forms are hard. Source: I was the Drupal form API maintainer for a long time. Way too long.

Not yet, but that is the intent. As a long-time Django user I have a high bar for the kind of forms support a framework should provide. One of my thoughts/beliefs is that, as a compiler with complete control over the page, there is a lot Pushup can do on both the markup generation side as well as checks and validations. eg., automatic CSRF token insertion, compiler "warnings" for accessibility, etc.

As others have commented, just go for <?go ... ?> instead of the caret. You'll get thousands of users in an instant.

So basically PHP, but in Go? I love Go, but I honestly hope this doesn't become as widespread as PHP. There is a reason why we switched away from template-based frontends (à la PHP).

On the other side, it's also true that some frontend frameworks are partially moving back to SSR...

One counterpoint is React is doing gangbusters right now and uses the JSX syntax extension to embed HTML directly into JavaScript or TypeScript.

To my money, the main issues with PHP had little to do with template embedding and everything to do with Perl being a messy language for writing correct code (coupled with too many people in the era underestimating the importance of "correctness" for HTML rendering when the ability for a malicious operator to mutate HTML on a page can result in all manner of security exploits). Perl just has too many ways to write accepted almost-correct code that breaks abstraction / fails to string-escape in subtle and whole-farm-losing ways.

Are you equating PHP and Perl? If so, that's incorrect - the relationship between the two is just one of influence, PHP has some influences from Perl (but also tons from C, C++, and Java).

To be fair, you haven't exactly augmented the single-element list [Perl] with a host of languages that I'd consider improvements on writing correct code. ;)

Java, yes, mostly.

There's a difference though. JSX embeds html into strings while the way Php intermingles html and code uses global buffers. That makes composition more complicated since you have to deal with nested buffers, flushing, cleaning, etc. I really prefer the way JSX does it over Php's.

> So basically PHP, but in Go?

You say that like it's a bad thing ;^)

Then why not <?go ... ?> instead of the random ^ soup?

Why is that better?

Internationalization, not every keyboard has ^ easily accessible.

Looks like other SSRs. FEDs will thank you.

In real word HTML template are 90% DIVs, 10% generated content.

Please, no. Let's not intermix <> code fragments with <> html elements. Have you witnessed the nightmare of reading and updating JSTL, for example?

Meh, JSP and PHP do this already. JSP is of course <%… %>. ColdFusion does it all the time. It’s easier on the eye, especially with editor support, than having to scan for all those ^ characters.

Anyway, my original comment was a take on “PHP but for Go”, and only half serious. I don’t see myself using the product discussed here. I hear the people who say “I disable JavaScript” but frankly I always write my apps so that the frontend part communicates with the backend via JSON API. I’m not a frontend dev…

> There is a reason why we switched away from template-based frontends (à la PHP).

Can you elaborate on that reason? Genuine question. As you mentioned in your post, a lot of what newer web frameworks are doing (SvelteKit, Astro, Enhance.dev, etc.) are reminding me a lot of my early days with PHP. The benefits of SSR are widely acknowledged amongst the proper JS frameworks.

Frontends became more interactive, and as such, you can't really template that interactivity / reactivity away. Hardly anyone uses Vanilla JS nowadays, and thus, hardly anyone can create a template-based website for today's standards. This is just my opinion though, happy to be proven wrong :)

> There is a reason why we switched away from template-based frontends (à la PHP)

Who is "we"? There are more websites out there written using template-based frontends (mostly PHP) than the other way around.

Copying React's JSX would be sooo cool (like Rust's https://dioxuslabs.com/ ), or something like phoenix liveview for elixir.

I don't like the "^"

It's a nice idea. I'm going to dig a little deeper in the design and developer experience choices.

That being said, I am a little curious -- what is the intended use case here? The reason I am asking is because I've been doing lots of web-development, with Go as a primary backend lang, for the last 9 years but never have I seriously felt the need to do serve the UI from Go. I guess there is some advantage reducing n (number of tools/languages in a stack) - but is there any other motivation behind it?

The imagined use-case for Pushup is the same niche that Rails, Django, and Flask apps occupy, which is a wide range but broadly I would describe as page-oriented, HTML-first, server-side frontends.

I started Pushup because I asked myself, I like programming in Go and think (like you) it's great for web backends - but what is holding it back from being a great full-stack web dev language or environment? net/http is a great building block, and html/template is solid, but I felt more was needed. Like opinionated project directory structure, for one. But also the world has changed since 2006 when Rails and Django debuted.

Obviously, we live in a world in which React and the SPA is seemingly dominant, but projects like htmx have recently shown that you can achieve modern UI/UX in the browser on a server-side app, which less JavaScript. BTW, more and more JavaScript frameworks, like Remix, are (re-)discovering the value of SSR.

I was also motivated to give an old-school mod_php feel of, just add a file and you automatically get a URL route. That's a nice developer experience but also good for long-term project maintenance.

Finally I was struck by this essay[1] about the demise of the "mildly dynamic" site. There is a wide diversity of types of sites and apps, from quick experiments and prototypes, small-to-medium sites of many kinds. But also since it's Go, I think it could scale up on performance to large-scale sites, and as a static binary, be nicely suited to edge apps like fly.io.

[1] https://www.devever.net/~hl/mildlydynamic

Really great explanation, thanks. I've definitely felt a bit silly spinning up an entire react project for a "mildly dynamic" site

First off @paulsmith, thanks for creating Pushup! I've been meaning to learn Go, and in particular in web context...and I've always been a fan of the "mildly dynamic" approach to web sites, web apps. So, I will certainly dive in. Secondly, thank you for sharing that article that inspired you. I kept nodding along so much while reading that article, it was like i was a bobblehead! I don't code much over the last decade or more, but when i do (for web anyway), i almost always employ php in the "mildly dynamic" method...Because its easy and solves needs that come up. Thanks again!!

I have to be honest, I don't like the aesthetics. I know that's a trivial point, but if you're working in something for a living it matters. The suggestions elsewhere of using "<?go ?>" or similar look better to my eyes. I'd also be concerned that by the time there are enough features in it to support more complex sites, the learning curve will be enough that you may as well use Go directly. I could easily be wrong about that, and I know others will see value, so YMMV as we say.

That isn't to say I have any negative comment about your project on its own terms and merits, just that it isn't for me.

However I do thank you for the link to the "mildly dynamic" page. In addition to Go I also do C#, Node, Python, and others. Those others include PHP (on and off since PHP 3). For serious stuff I'm usually managed (or persuaded) into using anything other than PHP, but on the odd times I do use it the feeling is quite different from the rest and hard to explain. It feels like that linked page comes closest to explaining it for me, so cheers!

As the author of the above article I saw Pushup the other day and thought it looked interesting. If people are being inspired to bring back this sort of approach to webdev that makes me happy. Good stuff!

It's still a hard rule of mine that a website must work without JS and use progressive enhancement - I won't accept less in my own work. A lot of "modern" web frameworks get automatically disqualified when I evaluate them for this reason.

This looks great for simple projects, but I'm curious who is working on projects small enough to not be worth a separate dedicated and feature-filled frontend (ala JS/Flutter), but large enough to warrant server-side logic.

That's certainly not to say they don't exist, and Pushup is certainly filling a niche, but my mind immediately goes to those "forgotten" services like email unsubscription and confirmation links.

Yep, or admins or settings apps, for example. Pushup is partly designed to support the "mildly dynamic" site https://www.devever.net/~hl/mildlydynamic

This looks neat.

Always be wary of this on a new web framework:

> Pushup is an experiment. In terms of the development life cycle, it should be considered preview pre-release software

The biggest risk with such software as a web framework is security exploits. The nuances of the HTML escaping dance are subtle and hard to get right.

(Not to say this gets them wrong or can't get them right, only that all such code should be assumed-risky for security until proven otherwise).

TBH all I want are Django's generic views implemented in Go to make it easy to map routes to DB resources to speed up making APIs.

Ideally it would automagically expose a whitelisted list of DB tables as API endpoints but allow the ability to override queries for each table and perform logic as necessary (i.e. support custom handlers as well as lightweight default ones).

If anyone knows of anything like that please let me know.

sqlc.dev plus gongular and you have a quick REST api

sqlc.dev plus gql-gen and you have a quick GraphQL server

sqlc.dev plus goa.design and you have a full-featured REST + gRPC server with OpenAPI for easy client generation

No need to write model code and validation for inputs/outputs. Just define your SQL queries and your request objects (or typedefs for GraphQL) and then let these tools generate everything else.

You've piqued my interest. Do you know of any OSS repos that implement any of these?

No, I'd really like to see this change as I feel there are a lot of hidden gems in the Go ecosystem. Developers arrive in Go, find Gin and start making their Rails/Laravel/Express.js MVC framework without realizing Go offers some alternatives by it's design (Rust too!)

There's an interesting conversation to be had about developer ergonomics. For me, on a Mac, it's far more easier to use characters and symbols on the bottom of the keyboard.

<script></script>.

It's even easy to use a select few symbols from the number row.

!, @, #, $ uses my left pinky on the left shift, left hand middle (or index) finger on the number

&, *, (, and ) use my left pinky on the left shift, right hand finger on the number.

^ (and % + & to an extent) seem to be a no-mans land, similar to smart phone screens only allowing limited easy reach.

If you're going to be typing a symbol character to mark a variable (or whatever else) it certainly needs to be easy to reach, and for me at least, the ^ isn't.

Maybe it's just my typing style or that I have small fingers :(

Edit: Also, what about IDE plugins? I would hate to lose type safety or smart suggestions for a line like this:

<p>The time is now ^time.Now().String().</p>

Also, some keyboard layouts use dead keys for inputting ^ as a diacritic (for example, ABNT2 Portuguese, the standard in Brazil).

This means that to type "â" I press the ^ key, which is actually Shift+~, then I press the letter to go under it, in this case, "a". If I want to type a standalone ^, I have to either press Shift+~ twice, or follow the Shift+~ with an invalid letter, such as "q" or space.

So typing a lot of code that uses ^ is very annoying. For example, to type "^section" you have to do: Shift+~, Space, S...

Additionally, and this is purely Apple's fault for being entirely deranged, on Macs you have to watch out even further, as it is possible to write both ^ and ˆ, depending on what you press. Shift+~ then space prints the lone diacritic, while Shift+~ then right arrow prints the ASCII ^ you've seen so far. Obviously, having to reach for the arrow keys for a common occurrence when typing is incredibly inconvenient, on top of the inconvenience described previously.

> Also, what about IDE plugins?

An LSP server for Pushup syntax is on the informal roadmap.

This really seems like php. I also think that mixing UI with logic is a recipe for disaster and there is already php (and several others?) for that. I suppose the creators of such a thing have a decent knowledge of compilers and related domains, knowledge which really seems wasted on a project like this.

Bravo! This makes me genuinely happy.

A sane, compiled template language for Go, integrated with a framework that pushes for HATEOAS via HTMX hits every row and column in my dream-webs-tack-bingo-card.

Looking forward to digging into this during the weekend.

This is really cool - so cool that I hate to be a naysayer. We used to build pages this way and to a large degree moved away from this practice because the applications became to hard to test. At the other end of the spectrum is "Passive View" which allows for testing of the business logic and easy mocking of the view - https://martinfowler.com/eaaDev/PassiveScreen.html.

Nice seeing going this forward. I built something similar in the past, that can be used as a base for such framework utilizing yaegi (from the creators of traefik): https://github.com/Eun/yaegi-template

well that is interesting. Is there a way to use different delimiter instead of "<$" .

Yes, you can just specify different start- and endrunes: https://github.com/Eun/yaegi-template/blob/master/template.g...

I don't like it. It looks like early php. This doesnt mean it is bad.

I'm working on a web framework as well based on wasm in the browser. It's perfect except it's not really usuable/production ready due to high memory consumption of the go->wasm implementation. My hope is that one day there will be support for GC in wasm and somehow the issue will go away.

Have you looked into using TinyGo[0]? It's a Go-for-embedded compiler and can compile Go to WASM as well.

It's supposed to result in much smaller artifacts.

[0]: https://tinygo.org/docs/guides/webassembly/

In my experience, TinyGo is far from ready for prime time, mainly because of its lack of support for JSON marshaling/unmarshaling.

I run Go code in Cloudflare Workers, and just use the regular-ol' WASM targets (GOOS=js/GOARCH=wasm)

Huh, CF Workers used to limit the payload to 1MB, and any slightly nontrivial golang js/wasm artifact (not tinygo) I’ve ever built was >2MB compressed, so the idea of running those on CF Workers was dead on arrival. However, apparently the limit was raised to 5MB for paid plans some time last year.

I'm using a lot of reflection and I believe tinygo has had some issues with the reflect package.

I'm not really ready to dig into Tinygo issues. I've spent a lot of time dealing with Go's own reflect issue(i.e [0]) in its default implementation.

https://github.com/golang/go/issues/15924

TinyGo does indeed have problems with the reflect package, as well as many others, one which I've managed to help with [1]. The developers have been very helpful, but the reflect package is still a big missing piece.

Your framework sounds interesting. Do you develop it in the open?

[1] https://github.com/tinygo-org/tinygo/issues/3274

Lack of reflection also creates issues for (for example) XML decoding, but I found that it's possible to delete reflection code from the source and compile it with basic decoding support. No annotations - but this is OK because Go's XML annotations are evil.

Since Pushup is a compiler, one thought I've had is giving the ability to demarcate server-side and client-side code in a Pushup page, and compiling down to WASM for the client-side code. Then the compiler would generate the network code to do the hand-offs.

Interesting! Do you have a link?

Looks cool! Two questions:

What does a Treeview look like - in a ".up" file, can I walk a tree (like io.fs.FS) ?

Can I compile a Pushup app into a giant WASM hairball and run the whole thing in the browser ?

> What does a Treeview look like - in a ".up" file, can I walk a tree (like io.fs.FS) ?

Yes, you can just write normal Go code to traverse a filesystem and do with it whatever you like.

> Can I compile a Pushup app into a giant WASM hairball and run the whole thing in the browser ?

I haven't tried this so I don't know what would happen, and a lot would depend on what kind of JS host runtime support there was for anything that is doing a syscall.

But related to WASM, an idea I have is to add syntax to be able to split a Pushup page into client-side and server-side code, compile the client-side code to WASM, and use the Pushup compiler to generate the appropriate handoffs for any network calls between (AJAX, websocket, etc.)

Ideally then, the client side could run in disconnected mode. But then you encounter DB sync issues. And I wonder what htmx does then.

I like this project to succeed but I can hardly like the ^ for template, please make it similar to PHP|django etc if possible.

Is there a decent auth library for go similar to what django provides, or do people just use keycloak for user accounts?

Very interesting! Kind of react, but in Go. Fingers crossed for 'Pushup Native' for mobile ;-)

PHP and Golang have had a child. At last, a modern rope to hang yourself with.

How do I debug apps built with this compared to dev tools with plain js?

Why a new template syntax? What wrong with the standard go templates?

OK so who's gonna integrate this with pocketbase and maybe datasette too ? Set a standard, maybe.

Some PHP fan trying to bring their deception to go.

These programmers were so preoccupied with whether or not they could, they didn’t stop to think if they should. That abomination of a markup cum programming langauge is so ugly.

Seriously tho, cool project but ugly syntax.

Do you think all template languages that combine logic and markup are ugly? Or just Pushup's?

I like that Flask has Jinja2, which has a simple template language in it, but doesn't let you run arbitrary Python.

Reply on news.ycombinator.com