7 ms·

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 pag

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 https://www.youtube.com/watch?v=nkyiATkZ4Js

iamgopal 4y ago
Also try to give usable web app ( todo ? ) hostel somewhere if possible.
- paulsmith 4y ago
  Yes, we need to do that - I'll populate them here eventually https://pushup.adhoc.dev/docs/guides https://pushup.adhoc.dev/docs/guides
KRAKRISMOTT 4y ago
Do you have any hosted demos?
- paulsmith 4y ago
  The main project site is a Pushup app: https://pushup.adhoc.dev 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 https://pushup-htmx-template-fragments.fly.dev/demo
savolai 4y ago
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.
- paulsmith 4y ago
  That's good feedback, thank you. My US-centric eye didn't consider that.
  - thiht 4y ago
    Same on a French keyboard, trying to type `^if {` will result in `îf {`
- derkoe 4y ago
  Oh yes it's pretty hard to type on a German keyboard as well. In most editors you will need two keystrokes.
  - fulafel 4y ago
    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)
    - Zababa 4y ago
      "{" 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).
mholt 4y ago
Hey cool! Caddy plugin? :D I might be quite interested in this.
- paulsmith 4y ago
  We talked about exactly that! Yes, let's
jerf 4y ago
"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.
- robertlagrant 4y ago
  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.
  - jerf 4y ago
    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 https://en.wikipedia.org/wiki/Inner-platform_effect
    - robertlagrant 4y ago
digitalsankhara 4y ago
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.
- fprog 4y ago
  Love this idea. And I’ve been looking for something exactly like Pushup. Really excited to try it out.
oppositelock 4y ago
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 https://github.com/deepmap/oapi-codegen

iamgopal 4y ago

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

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

KRAKRISMOTT 4y ago

Do you have any hosted demos?

paulsmith 4y ago
The main project site is a Pushup app: https://pushup.adhoc.dev 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 https://pushup-htmx-template-fragments.fly.dev/demo

savolai 4y ago

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.

paulsmith 4y ago
That's good feedback, thank you. My US-centric eye didn't consider that.
- thiht 4y ago
  Same on a French keyboard, trying to type `^if {` will result in `îf {`
derkoe 4y ago
Oh yes it's pretty hard to type on a German keyboard as well. In most editors you will need two keystrokes.
- fulafel 4y ago
  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)
  - Zababa 4y ago
    "{" 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).

mholt 4y ago

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

paulsmith 4y ago
We talked about exactly that! Yes, let's

jerf 4y ago

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

robertlagrant 4y ago
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.
- jerf 4y ago
  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 https://en.wikipedia.org/wiki/Inner-platform_effect
  - robertlagrant 4y ago

digitalsankhara 4y ago

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.

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

oppositelock 4y ago

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 https://github.com/deepmap/oapi-codegen