Some PHP fan trying to bring their deception to go.
Pushup: a new compiler for making web apps in Go
71–80 of 121 posts
Re: Pushup: a new compiler for making web apps in Go
#72Earlier quoted context omitted.
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/
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?
Re: Pushup: a new compiler for making web apps in Go
#73There'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. . 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 numbe…
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.
Re: Pushup: a new compiler for making web apps in Go
#74I like this project to succeed but I can hardly like the ^ for template, please make it similar to PHP|django etc if possible.
Re: Pushup: a new compiler for making web apps in Go
#75So 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...
> 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 :)
Re: Pushup: a new compiler for making web apps in Go
#76So 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...
> 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.
Re: Pushup: a new compiler for making web apps in Go
#77As others have commented, just go for instead of the caret. You'll get thousands of users in an instant.
Re: Pushup: a new compiler for making web apps in Go
#78Pushup 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 libra…
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.
Re: Pushup: a new compiler for making web apps in Go
#79When 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?
Re: Pushup: a new compiler for making web apps in Go
#80Earlier quoted context omitted.
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).