[HN Gopher] Pushup: a new compiler for making web apps in Go
___________________________________________________________________
Pushup: a new compiler for making web apps in Go
Author : todsacerdoti
Score : 152 points
Date : 2023-01-04 15:49 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| shadowgovt wrote:
| 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).
| jakelazaroff wrote:
| 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.
| HALtheWise wrote:
| 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
| paulsmith wrote:
| > 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
| euroderf wrote:
| 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 ?
| eddwinpaz wrote:
| Some PHP fan trying to bring their deception to go.
| paulsmith wrote:
| 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
| iamgopal wrote:
| Also try to give usable web app ( todo ? ) hostel somewhere if
| possible.
| paulsmith wrote:
| Yes, we need to do that - I'll populate them here eventually
| https://pushup.adhoc.dev/docs/guides
| mholt wrote:
| Hey cool!
|
| Caddy plugin? :D I might be quite interested in this.
| paulsmith wrote:
| We talked about exactly that! Yes, let's
| jerf wrote:
| "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.
| paulsmith wrote:
| > 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).
| robertlagrant wrote:
| 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 wrote:
| 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
| robertlagrant wrote:
| 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.
| leerob wrote:
| 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
| mijamo wrote:
| Next.js routing limits have been for me the number one
| reason not to use it unfortunately.
| leerob wrote:
| 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.
| techpression wrote:
| 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).
| TylerE wrote:
| 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.
| savolai wrote:
| 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 wrote:
| That's good feedback, thank you. My US-centric eye didn't
| consider that.
| derkoe wrote:
| Oh yes it's pretty hard to type on a German keyboard as well.
| In most editors you will need two keystrokes.
| fileeditview wrote:
| 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.
| fulafel wrote:
| 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)
| kej wrote:
| 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.
| paulsmith wrote:
| 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/04aa00bb5401
| bc93b...
| euroderf wrote:
| OTOH I have an actual Finnish keyboard and caret is simply
| Shift-umlaut (the key has a caret over a pair of dots).
| tuetuopay wrote:
| 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...
| kgeist wrote:
| 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.
| Semaphor wrote:
| 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/
| playingalong wrote:
| Admittedly ^ on a US keyboard also involves two keys.
| digitalsankhara wrote:
| 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 wrote:
| Love this idea. And I've been looking for something exactly
| like Pushup. Really excited to try it out.
| KRAKRISMOTT wrote:
| Do you have any hosted demos?
| paulsmith wrote:
| 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
| oppositelock wrote:
| 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
| techn00 wrote:
| 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 "^"
| Eun wrote:
| 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
| denysvitali wrote:
| 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 (a la PHP).
|
| On the other side, it's also true that some frontend frameworks
| are partially moving back to SSR...
| shadowgovt wrote:
| 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.
| kennywinker wrote:
| 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).
| shadowgovt wrote:
| 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.
| hiccuphippo wrote:
| 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.
| kevinfiol wrote:
| > There is a reason why we switched away from template-based
| frontends (a 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.
| denysvitali wrote:
| 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 :)
| paulsmith wrote:
| > So basically PHP, but in Go?
|
| You say that like it's a bad thing ;^)
| rad_gruchalski wrote:
| Then why not <?go ... ?> instead of the random ^ soup?
| paulsmith wrote:
| Why is that better?
| sunbum wrote:
| Internationalization, not every keyboard has ^ easily
| accessible.
| nablaone wrote:
| Looks like other SSRs. FEDs will thank you.
|
| In real word HTML template are 90% DIVs, 10% generated
| content.
| dakiol wrote:
| > There is a reason why we switched away from template-based
| frontends (a la PHP)
|
| Who is "we"? There are more websites out there written using
| template-based frontends (mostly PHP) than the other way
| around.
| TobyTheDog123 wrote:
| 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.
| paulsmith wrote:
| Yep, or admins or settings apps, for example. Pushup is partly
| designed to support the "mildly dynamic" site
| https://www.devever.net/~hl/mildlydynamic
| fredrikholm wrote:
| 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.
| synergy20 wrote:
| I like this project to succeed but I can hardly like the ^ for
| template, please make it similar to PHP|django etc if possible.
| TobyTheDog123 wrote:
| 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>
| kroltan wrote:
| 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 "a" 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.
| andreygrehov wrote:
| 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?
| dakiol wrote:
| As others have commented, just go for <?go ... ?> instead of the
| caret. You'll get thousands of users in an instant.
| Gys wrote:
| Very interesting! Kind of react, but in Go. Fingers crossed for
| 'Pushup Native' for mobile ;-)
| teejays wrote:
| 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?
| paulsmith wrote:
| 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
| mxuribe wrote:
| 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!!
| warrentr wrote:
| Really great explanation, thanks. I've definitely felt a bit
| silly spinning up an entire react project for a "mildly
| dynamic" site
| kcartlidge wrote:
| 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!
| whage wrote:
| 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.
| [deleted]
| IceWreck wrote:
| 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.
| paulsmith wrote:
| Do you think all template languages that combine logic and
| markup are ugly? Or just Pushup's?
| robertlagrant wrote:
| I like that Flask has Jinja2, which has a simple template
| language in it, but doesn't let you run arbitrary Python.
| thefounder wrote:
| 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.
| aatd86 wrote:
| Interesting! Do you have a link?
| paulsmith wrote:
| 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.
| cube2222 wrote:
| 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/
| thefounder wrote:
| 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
| TachyonicBytes wrote:
| 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
| TobyTheDog123 wrote:
| 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)
| oefrha wrote:
| 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.
| nprateem wrote:
| 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.
| Xeoncross wrote:
| 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.
| lprd wrote:
| You've piqued my interest. Do you know of any OSS repos that
| implement any of these?
___________________________________________________________________
(page generated 2023-01-04 23:00 UTC)