Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
That sounds like nightmare.
Created a stack:
mov esp, stack_bottom
ars117076dI replaced Vue with golang wasm.
@AleCx04 I could be off the charts wrong here...
Most JS projects "want" server side rendering, though VueJS started as client side if my brain isn't lying. "want" is an subjective Interpretation - SSR has downsides, but these are things many people don't want to hear. 🙈
I'm not entirely sure where Go fits in this stack - the most sane thing would be as a webserver replacement, I think?
This is usually the part where most projects / IDEs "offer" the NodeJS Express framework / server or NGINX.
If we now replace ExpressJS with Go - part where I can be completely wrong - ,3 scenarios possible:
1) Go replacing middleware / webserver
- with Go packages / frameworks / libraries
2) Go replacing middleware / webserver
- only Go std library
3) Go replacing only the webserver
Now 1) and 2) make me very nervous.
It would mean adding an Go Environment to the existing Node environment...
Ouch. That will be _lot of ground_ to cover and guard.
If we only use the Go std library it means writing own middleware, can be done if minimalistic, but most likely it ends not well - after all, middlewares aren't minimalistic, as they try to hide all the complexity of HTTP in an OOP oriented manner... Which is definitely not minimalistic.
Now 3 is the part where my brain could agree on, as this could be mostly done with Net/Http of the std lib in Go. Meaning we wouldn't add an entirely different language stack + development environment.
Go as an webserver cannot be worse than Nginx without pro license.... I really wish Apache would be resurrected from it's death, an alternative to NGINX which is _just_ an webserver and not some funky blurry potpourri of opinionated middleware / jackass of all trades and HTTP webserver is sorely missed.
Note: Has nothing to do with Go itself.
it could be pronounced 'Ponzi" - schema
pong - (from ping pong)
or PNG stack
If I understood correctly, it seems that your dislike of this idea comes from the notion that Go and Node would be interlaced somehow as the development environment for the server side.
Go generates the standalone executable for the entire server, this includes routing, middleware etc. If the user in question decides to go with a frontend framework, then the entire aspect of the server is written in Golang.
Golang does feel very hands on/building everything from scratch, but it does not necessarily have to be.
Think of the libraries that people usually add like Gorilla or Chi as just the routing and middleware systems which add to the net/http std package that Go has. These be extensions more than anything.
That is just the backend, we usually use Nginx as a proxy for this, and we normally don't intend to have Go do everything by itself, that usually ends badly, so Nginx is usually thrown into the mix.
More or less.
What worries me most is that Node with it's gazillion libraries is already a nightmare to maintain.
Mixing it with another thing - as good as it might be - increases the maintenance cost tremendously.
If you cut it down to one framework and one framework alone it could work, but then you really need - as you pointed out - a clear structure and distinction between who's who.
I guess my nightmare stems from the fact that most of the times devs don't have a structure at all...
Which ends in the case of mixing different languages in a complete unmaintainable clusterfuck.
ng190513Microsoft support: "Your antivirus software is causing problems with the memory management." Me: "I use Windo...
Noob14Met a guy in the gym, he asked me to make him an online shop for supplements. I quickly made a reactive, angul...
danielsousaio3410 years later... A decent internet connection, at last! Let the downloads begin!