Hacker News Reader

Comment by paulsmith | Hacker News Reader

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

View on HN

"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.

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.

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 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.

Hey cool!

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

We talked about exactly that! Yes, let's

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

Reply on news.ycombinator.com