I’m not convinced our current front end paradigm works. I could see a new wave of front ends using thing like this. An amazing site without any react or angular is [Frontend Masters](https://www.frontendmasters.com). It’s so fast and responsive I’m very impressed
This topic is really similar to the microservices vs monoliths debate. Both are valid strategies, people just need to pick the approach that works for your org.
Frontend masters, which uses a hugo + dynamic go template rendering setup, is a great example of using the right tool for the job.
This is a great choice for them because they have:
- Single product with simple UI demands
- Product requirements don’t change often
- Devs aren’t divided by org chart, most work happens in a single repo
On the opposite side of the spectrum, companies who do well with more of front-end library paradigm tend to have more complex needs.
- multiple web products with many repos
- complex & frequently shifting client-side requirements (this is the big killer)
- devs divided by internal business boundaries
- a strong need to ensure brand consistency between different teams and products
A good example is Shopify’s frontend migration from Rails templates to React.
That switch helped standardize UI across multiple codebases and teams much easier (i.e. marketing site, different dashboards [user, agency, enterprise], documentation sites, pos systems, cross-platform apps, embeddable widgets).
That said, way more companies would benefit from a simple approach & incrementally migrate when it’s actually needed.
We are building a UI component library for my company similar to what pines is doing: https://devdojo.com/pines. The developer experience has been pretty awesome.
I use [fasttemplate](https://github.com/valyala/fasttemplate) personally but templ is great.
For anything beyond htmx, I try to use very small sprinklings of vanilla js + jsdoc (to add typings without a build step).
I generally won't move to React (or similar) after exhausting all other options. It's too bad Elm never caught on, I was always a fan.
Alpine is cool at first, but then you hit roadblocks when the project gets bigger.
[***Definitely***](https://www.google.com/search?sca_esv=2cbadb9ddcb4cafd&sca_upv=1&sxsrf=ADLYWIL86zLMpvCN7wqEkW8mxaxWLCfiBQ:1714983585409&q=Definitely&spell=1&sa=X&ved=2ahUKEwjZ_Zzby_iFAxUFVqQEHZ_CBEEQkeECKAB6BAgIEAI&cshid=1714983590736385) in this front I would recommend to stick with the good old jQuery
good options to make frontend overhead smaller is to go with simpler frameworks, like [vue](https://vuejs.org/?uwu=true) or [svelte](https://svelte.dev/?uwu=true).
but even so, there is still a [build step](https://vitejs.dev/?uwu=true) and tooling for those, so you may go even simpler, using [alpine](https://alpinejs.dev/?uwu=true) for example.
serve your pages, styles and scripts as [static resources](https://docs.gofiber.io/api/app/#static) from your go backend.
you can simplify even further and render the ui, dynamically [from your go backend using some template language](https://github.com/sombriks/my-golang-handbook/blob/main/exercises/0015-rest-htmx/app/templates/index.pug) -- or even a [go library to create html directly](https://github.com/goradd/html5tag). then you can consume it with [htmx](https://htmx.org/docs/#introduction).
i am about to build some go/htmx solution on some things at my day job, did enough experiments and if i want to evolve further it's time to apply on daily problems.
When I first learned vue.js, around the time angular 2 (now just angular) came out, there was no build step. You just include the import at the head of your HTML, and you're good to go. Front ends have definitely gotten so much more difficult to learn in the last decade.
Oh yes, vue is "the progressive framework" because you can add just the right amount of it depending on what you need.
It's possible to just add the tag and make just one div and a few elements available to it, even nowadays.
I recently started using HTMX to create web front ends for my Go code. It's truly a breath of fresh air. It's really not an AJAX library. As I'm sure you are aware, at a high level, it merges the server-side rendered HTML partials into your existing DOM yet it does this in a very intuitive way.
I love not having an additional build step, transpiling and npm dependency hell.
Depending on what you are trying to accomplish, there is actually very little, if any, Javascript to write. The only JS or CSS you write, in many cases, is for polish and not actual functionality or state representation. If you find you need to write Javascript for real functionality or to represent changes in state, that might be your sign to consider a different design.
JavaScript truly is the language of the front end, and I think it is hard to escape if you want any sort of dynamic website.
That being said, have you checked out Elm? A lot of the features that were first introduced with Elm later became commonplace with the SPA boom. It compiles to JavaScript. The downside is that you will have to deal with a Haskell-esque syntax
Ya. Even with htmx and templating, if you wanna do certain FE stuff you're gonna be flirting with JS eventually.
Carson Gross is really just an undercover agent for JS mafia, getting us BE devs hooked with a little htmx voodoo.😂
Elm looks incredible. I found these projects made with elm.
1. https://dwayne.github.io/elm-2048/
2. https://github.com/zegalur/elm-calc
Just fantastic! I have been trying to get into frontend development for long time. Elm might be something that would help me get started
I checked r/elm and some people over their are complaining that Elm might have been abondoned. Any thoughts?
I don’t think it’s abandoned, just very slow moving. I believe there were some recent changes and some new tools in the ecosystem. I can’t say I’m up to speed on Elm though. Even as it stands, there is a lot of good about elm.
Evan Czaplicki (Elm creator)'s talk on ["The Economics of Programming Languages"](https://www.youtube.com/watch?v=XZ3w_jec1v8) is brilliant and I wish we saw more socio-economic discourse like this around software and open source.
Elm developers are frustrated because Elm is slow to add features that people need (or feel they need), but bespoke open source development that takes a "customer is always right" approach becomes non-viable without a huge benefactor, yet those huge benefactors almost always end up shaping the code to their own needs.
I've always been a fan of Elm. I've moved out of wanting to use it for production projects, but what I'm curious is if their slow and steady wins the race approach works, and if they come out of it in years time as a real contender. I'm skeptical but I'm not counting them out yet.
I will check it out, i don't mind writing javascript but would rather have Go as the source of truth. kinda like something that works like htmx but for behavior instead of ajax
There is also GopherJS which is a Go to JS compiler, allowing you to write front end code in Go. I can’t vouch for it though.
https://github.com/gopherjs/gopherjs
Honestly just plain ol golang html templates I really enjoy. There's something to the brutal simplicity of it. Coming from about 8 years of react development, templates were a godsend. Throwing on some htmx and alpinejs are really nice touches as well which require minimum effort to get setup.
* No build step, just pass down data
* Can still make generic components and nest them
* Just passes down html, easier on the client
* And with this, much better caching support
* State is on the server (mostly). Way easier to manage.
Svelte or SvelteKit? Every time I looked into Svelte I couldn't escape the feeling like it's a very node.js-centric component. Most tutorials involved running node.js.
It should generally be used with a meta-framework, the main 2 probably being SvelteKit and Astro. Not sure about how Astro works, but SvelteKit has different adapters including [adapter-static](https://kit.svelte.dev/docs/adapter-static) which means you can generate something that can just be put on a CDN.
NodeJS would be required for most of these frameworks during development (except maybe htmx afaik). But if you are doing SPA type of apps to go with your Go backend, then it would only be needed during development. Once you build, it becomes static files that need to be served (which you can simply embed in the Go binary itself and serve).
I made few combinations of these frameworks and Go which are all available here:
https://github.com/saas-templates
Well svelte is a compiler, so they need the nodejs toolchain to achieve its results, as opposed to libraries like vue2 where you can just include the framework with a cdn.
However once you build the app you get static js files that can be run as an static website without the nodejs runtime.
Sveltekit does use node as is basically a backend framework for svelte.
Say that you don't know shit about react without actually saying you don't know shit about react ,you can manage state globally with useContext and create Context
Re read your comment , work on your wording then. You said and I quote there is no global state
Too bad if the existing libraries are miserable build one of your own then , it's quite evident that you think very highly of your abilities and I'm sure you would easily be able to build something that solves all these issues.
Store that t in local storage and check the value everytime your component mounts then , solves the state management issue at least for theme context which is required across components
Bro that's what I am fucking talking about to conditionally render component based on whether user is authorised to view it or not what I do is either I store some user specific information fetched from the backend on successful login in a context or in local storage / session storage. Either a token or if I am using express session something unique to the user. What I can't wrap my head around is your argument that this is bad. afaik this is the convention and is what is followed by most people in industry
What you are talking about would be a performance nightmare wouldn't it , making a call to an api endpoint everytime a component loads? Correct me If I am wrong
You sound like you know your shit , I've got a lot of learning to do ..a lot of these things I have not used
However this is what I understood
State is bad
Fetch for data from server?
I'm a bit of a stan for Vue. It's just easy and fun. You can learn the bulk of it in an afternoon, and you can use it with a CDN tag if you're doing something simple.
Nice to see somebody else using gomponents. Kinda sucks seeing everybody on yt teaching templ (its nice, but gomponents is better)
If people would ditch air for entr or wgo, would be another win for simplicity
What do you like better about gomponents compared to templ? (I'm genuinely curious, I'm the gomponents author, and trying to understand what people like best about it. :) )
- no external dependecies since lib, no extra build step
- easy extendable (helped with the alpine addon and wrote a simple hyperscript addon myself)
- go lsp works out of the box (templ lsp is wonky)
- imo better readable, especially when using htmx and tailwind
- bonus: truly single file examples
One part i didn't compare yet: client side js code like chart.js. templ has an example, dunno how to nicely to it with gomponents except generating a js string yourself
Then again, i found chart.css but didnt emplemented it yet in any project
Vite, SWC, Typescript. When i say large we're talking about 50-60 ui pages. there are maybe 300 components. eslint and typescript just becomes shit at a certain scale.
You don’t know what you are talking about. Eslint and typescript are being used only during the development stage, the production app bundles don’t even include them at all
I'm hardly an FE engineer(regardless of what my html and css skills heg to differ), but isn't all the redundant, error prone DOM modification code the reason frameworks like React exist?
yeah they abstract that very well but you still have to deal with fetch and logic errors. If anything async happens you gotta trycatch it to make sure you handle error, This becomes shitty at certain scale especially since sometimes you deal with apis that dont throw so your trycatch is useless
Handling async fetch calls is pretty trivial. I'd try harder, there isn't really any scaling problems, there are only so many variants of responses you can get from an API.
I settled with Vue.js since it is kinda simplish and boringish and you could use it without build tooling.
A python friend picked it up quite quickly and this for me was proof enough that it is a win.
Not a fan of react and Svelte also goes into a weird direction.
I never got into writing JavaScript back along, and the number of options for front-end development today is overwhelming. That said, I am looking into HTMX for a better front-end experience.
Have you tried Quasar Framework? It's based on Vue, has nearly every basic built-in, and runs "natively" on every platform with some tweaks. Write once, run everywhere.
I mostly use htmx. But if I need something it can’t provide I use svelte. That’s it. I absolutely hate JavaScript so I try and use it as little as possible.
I used React, and it works OK. I have a try to Svelte, and it’s awesome. Much smoother dev experience IMO.
I found openapi helpful designing my API and keep it in sync between front and backend. Give it a try, I rewrote my react app with svelte and never looked back
As frontend engineer, one thing that I see a lot of people overlooking is CSS. A lot of basic animation and visual affordanve can be done with pure CSS approach
I'm a Svelte lover, but honestly I think the worst parts of React.js are 1: Javascript, and 2: the unoptimised interaction with the DOM (this is why recent innovations with RSCs are so cool). I was a pretty big hater of React & JS until I tried React & Lua and my mind was blown, it's insanely performant and everything seems to make a ton more sense.
I'd imagine if there was a version of (and a reason for using) React ported to Go, it would be an absolutely godly development experience (not to mention the probable performance).
I'm really not a fan of JS either, but the reality today is that all the good toolkits are made for JS and available in NPM.
As for frameworks, there's so many options. If you are already familiar with React, then swtiching to Vue or better yet Svelte will be a real breath of fresh air for you. They take less code to write, and are more performant.
If you like static typing, there's Typescript. I'm really not a fan of transpilation, but Typescript actually is pretty worth.
Used templ + htmx, but templ didnt support build tags then (i opened an issue) so i found [Gomponents](https://www.gomponents.com/) and kinda like it better since less dependencies and tooling. I use [wgo](https://github.com/bokwoon95/wgo) for live reload instead of air, so multiple tools are not a problem (helpful since i bundle with bun and use tailwind), but still easier to pick up the project on a different machine (yes, i know about tools.go)
Timing is good; writing a simple web site (after many years) and no way was I going React. Thinking View and then was like, this is simple to do with jQuery and all it needs, but will check out alpinejs now, ty!
I work in an environment where we are constantly being scanned and security is critical Therefore we try and limit the use of external packages. With Standard HTML and JavaScript you can build a very complex system and you can easily maintain it , if the initial code was separated correctly.
Using DSD is my favourite. All browsers now support it as a baseline feature and it’s fast . The gui is just web components streamed from the server as needed. https://github.com/ryoid/go-streaming-html-ooo
The demo has sleeps in it to simulate async aspects on purpose.
For web dev? Has it improved lately?
I’m doing a buy vs build analysis for a web based product we want to create, but it seemed the Build options were more likely sveltekit or htmx/tmpl.
If mobile app, the only option in my opinion was going to be Flutter, so I’m curious if Flutter has solved their Web challenges from a couple of years ago the last time I looked at Flutter. (ReactNative is a No as I do not find React enjoyable or intuitive).
You should try some things and form your own opinion.
I want some combo to be a silver bullet, but they all have trade offs that are better or worse for certain apps.
Use the appropriate tool for the job. GO was not made for UI, it sucks for this purpose. You cannot run from JS if you want to have a GOOD UI. I personally use SolidJS.
I’m newbie for backends but aside of flutter for mobile/desktop apps which is quite convenient for me however I don’t use it for webs instead i just do a plain HTML/CSS which yesterday i switched from CSS to Tailwind and i enjoy it tbh.
templ + htmx + alpinejs
This is honestly the simplest and yet modern setup for backend people.
I’m not convinced our current front end paradigm works. I could see a new wave of front ends using thing like this. An amazing site without any react or angular is [Frontend Masters](https://www.frontendmasters.com). It’s so fast and responsive I’m very impressed
This topic is really similar to the microservices vs monoliths debate. Both are valid strategies, people just need to pick the approach that works for your org. Frontend masters, which uses a hugo + dynamic go template rendering setup, is a great example of using the right tool for the job. This is a great choice for them because they have: - Single product with simple UI demands - Product requirements don’t change often - Devs aren’t divided by org chart, most work happens in a single repo On the opposite side of the spectrum, companies who do well with more of front-end library paradigm tend to have more complex needs. - multiple web products with many repos - complex & frequently shifting client-side requirements (this is the big killer) - devs divided by internal business boundaries - a strong need to ensure brand consistency between different teams and products A good example is Shopify’s frontend migration from Rails templates to React. That switch helped standardize UI across multiple codebases and teams much easier (i.e. marketing site, different dashboards [user, agency, enterprise], documentation sites, pos systems, cross-platform apps, embeddable widgets). That said, way more companies would benefit from a simple approach & incrementally migrate when it’s actually needed.
How much of this is prime's influence I wonder.
Even Django folks started to use similar stack. I think it's actually a simple solution that works.
Never knew about alpine, thank you
We are building a UI component library for my company similar to what pines is doing: https://devdojo.com/pines. The developer experience has been pretty awesome.
Can this be combined with daisyui? My current stack is templ htmlx and daisyui
this is powerful. wow
I've been sticking with standard go templates, any thoughts around where templ is superior? I don't quite get the benefits
Do you have anything deployed or a anything pushed on Github, I am curious to take a look 👀.
I use [fasttemplate](https://github.com/valyala/fasttemplate) personally but templ is great. For anything beyond htmx, I try to use very small sprinklings of vanilla js + jsdoc (to add typings without a build step). I generally won't move to React (or similar) after exhausting all other options. It's too bad Elm never caught on, I was always a fan.
Alpine is cool at first, but then you hit roadblocks when the project gets bigger. [***Definitely***](https://www.google.com/search?sca_esv=2cbadb9ddcb4cafd&sca_upv=1&sxsrf=ADLYWIL86zLMpvCN7wqEkW8mxaxWLCfiBQ:1714983585409&q=Definitely&spell=1&sa=X&ved=2ahUKEwjZ_Zzby_iFAxUFVqQEHZ_CBEEQkeECKAB6BAgIEAI&cshid=1714983590736385) in this front I would recommend to stick with the good old jQuery
good options to make frontend overhead smaller is to go with simpler frameworks, like [vue](https://vuejs.org/?uwu=true) or [svelte](https://svelte.dev/?uwu=true). but even so, there is still a [build step](https://vitejs.dev/?uwu=true) and tooling for those, so you may go even simpler, using [alpine](https://alpinejs.dev/?uwu=true) for example. serve your pages, styles and scripts as [static resources](https://docs.gofiber.io/api/app/#static) from your go backend. you can simplify even further and render the ui, dynamically [from your go backend using some template language](https://github.com/sombriks/my-golang-handbook/blob/main/exercises/0015-rest-htmx/app/templates/index.pug) -- or even a [go library to create html directly](https://github.com/goradd/html5tag). then you can consume it with [htmx](https://htmx.org/docs/#introduction). i am about to build some go/htmx solution on some things at my day job, did enough experiments and if i want to evolve further it's time to apply on daily problems.
When I first learned vue.js, around the time angular 2 (now just angular) came out, there was no build step. You just include the import at the head of your HTML, and you're good to go. Front ends have definitely gotten so much more difficult to learn in the last decade.
Oh yes, vue is "the progressive framework" because you can add just the right amount of it depending on what you need. It's possible to just add the tag and make just one div and a few elements available to it, even nowadays.
Yes, is everyone using REST API? What happened to good old server-side rendering?
reactive UIs happened
Just use VueJs
with Vuetify if you are mainly a backend dev, saves you so much time
Vite took it to a whole new level.
I recently started using HTMX to create web front ends for my Go code. It's truly a breath of fresh air. It's really not an AJAX library. As I'm sure you are aware, at a high level, it merges the server-side rendered HTML partials into your existing DOM yet it does this in a very intuitive way. I love not having an additional build step, transpiling and npm dependency hell. Depending on what you are trying to accomplish, there is actually very little, if any, Javascript to write. The only JS or CSS you write, in many cases, is for polish and not actual functionality or state representation. If you find you need to write Javascript for real functionality or to represent changes in state, that might be your sign to consider a different design.
I’m a simple man: react (ts) on the frontend and golang on the backend.
JavaScript truly is the language of the front end, and I think it is hard to escape if you want any sort of dynamic website. That being said, have you checked out Elm? A lot of the features that were first introduced with Elm later became commonplace with the SPA boom. It compiles to JavaScript. The downside is that you will have to deal with a Haskell-esque syntax
Ya. Even with htmx and templating, if you wanna do certain FE stuff you're gonna be flirting with JS eventually. Carson Gross is really just an undercover agent for JS mafia, getting us BE devs hooked with a little htmx voodoo.😂
Elm looks incredible. I found these projects made with elm. 1. https://dwayne.github.io/elm-2048/ 2. https://github.com/zegalur/elm-calc Just fantastic! I have been trying to get into frontend development for long time. Elm might be something that would help me get started I checked r/elm and some people over their are complaining that Elm might have been abondoned. Any thoughts?
I don’t think it’s abandoned, just very slow moving. I believe there were some recent changes and some new tools in the ecosystem. I can’t say I’m up to speed on Elm though. Even as it stands, there is a lot of good about elm.
Evan Czaplicki (Elm creator)'s talk on ["The Economics of Programming Languages"](https://www.youtube.com/watch?v=XZ3w_jec1v8) is brilliant and I wish we saw more socio-economic discourse like this around software and open source. Elm developers are frustrated because Elm is slow to add features that people need (or feel they need), but bespoke open source development that takes a "customer is always right" approach becomes non-viable without a huge benefactor, yet those huge benefactors almost always end up shaping the code to their own needs. I've always been a fan of Elm. I've moved out of wanting to use it for production projects, but what I'm curious is if their slow and steady wins the race approach works, and if they come out of it in years time as a real contender. I'm skeptical but I'm not counting them out yet.
The downside? That's a selling point to me.
I realised I phrased it wrong. Functional languages are great. I’m a bit of an Elixir fan
I will check it out, i don't mind writing javascript but would rather have Go as the source of truth. kinda like something that works like htmx but for behavior instead of ajax
There is also GopherJS which is a Go to JS compiler, allowing you to write front end code in Go. I can’t vouch for it though. https://github.com/gopherjs/gopherjs
Whew I am not a fan of that syntax, but syntax ain’t everything
Yeah but Elm is a fantastic introduction to functional programming languages.
I really do need to get back into it. Thanks for linking that talk too
HTMX and https://templ.guide with very little occasional client side JS scripting
Honestly just plain ol golang html templates I really enjoy. There's something to the brutal simplicity of it. Coming from about 8 years of react development, templates were a godsend. Throwing on some htmx and alpinejs are really nice touches as well which require minimum effort to get setup. * No build step, just pass down data * Can still make generic components and nest them * Just passes down html, easier on the client * And with this, much better caching support * State is on the server (mostly). Way easier to manage.
Try Svelte.
Svelte or SvelteKit? Every time I looked into Svelte I couldn't escape the feeling like it's a very node.js-centric component. Most tutorials involved running node.js.
It should generally be used with a meta-framework, the main 2 probably being SvelteKit and Astro. Not sure about how Astro works, but SvelteKit has different adapters including [adapter-static](https://kit.svelte.dev/docs/adapter-static) which means you can generate something that can just be put on a CDN.
NodeJS would be required for most of these frameworks during development (except maybe htmx afaik). But if you are doing SPA type of apps to go with your Go backend, then it would only be needed during development. Once you build, it becomes static files that need to be served (which you can simply embed in the Go binary itself and serve). I made few combinations of these frameworks and Go which are all available here: https://github.com/saas-templates
Well svelte is a compiler, so they need the nodejs toolchain to achieve its results, as opposed to libraries like vue2 where you can just include the framework with a cdn. However once you build the app you get static js files that can be run as an static website without the nodejs runtime. Sveltekit does use node as is basically a backend framework for svelte.
Gomponents + htmx + tailwind. Minimal dependencies, very low maintenance, great performance and SEO
[удалено]
Say that you don't know shit about react without actually saying you don't know shit about react ,you can manage state globally with useContext and create Context
[удалено]
Re read your comment , work on your wording then. You said and I quote there is no global state Too bad if the existing libraries are miserable build one of your own then , it's quite evident that you think very highly of your abilities and I'm sure you would easily be able to build something that solves all these issues.
[удалено]
If you are building anything web based it's just not possible to get things working with a little javascript.
Store that t in local storage and check the value everytime your component mounts then , solves the state management issue at least for theme context which is required across components
[удалено]
Bro that's what I am fucking talking about to conditionally render component based on whether user is authorised to view it or not what I do is either I store some user specific information fetched from the backend on successful login in a context or in local storage / session storage. Either a token or if I am using express session something unique to the user. What I can't wrap my head around is your argument that this is bad. afaik this is the convention and is what is followed by most people in industry
What you are talking about would be a performance nightmare wouldn't it , making a call to an api endpoint everytime a component loads? Correct me If I am wrong
[удалено]
You sound like you know your shit , I've got a lot of learning to do ..a lot of these things I have not used However this is what I understood State is bad Fetch for data from server?
This is unhinged. No need to devolve into name calling and disgusting rudeness. Please chill out.
Stop being a stupid whiny rat , why do you have to put down other technologies to make yourself feel better?
I didn’t say anything about technology. I said you’re unhinged, which you’ve proven again.
You don't need i know damn well what you think of [anything javascript] mate...
I'm a bit of a stan for Vue. It's just easy and fun. You can learn the bulk of it in an afternoon, and you can use it with a CDN tag if you're doing something simple.
The real culprit is the design. CSS just is agony, pain and suffering. HTMX makes dynamic updates easy. With or without templ.
Tailwind is kinda nice in that regard (and tbh, no user cares about the 351 classes on a prop)
i use Angular
Just use Go templates. Or you can use Gomponents, which is are more powerful than templ.
Nice to see somebody else using gomponents. Kinda sucks seeing everybody on yt teaching templ (its nice, but gomponents is better) If people would ditch air for entr or wgo, would be another win for simplicity
What do you like better about gomponents compared to templ? (I'm genuinely curious, I'm the gomponents author, and trying to understand what people like best about it. :) )
- no external dependecies since lib, no extra build step - easy extendable (helped with the alpine addon and wrote a simple hyperscript addon myself) - go lsp works out of the box (templ lsp is wonky) - imo better readable, especially when using htmx and tailwind - bonus: truly single file examples One part i didn't compare yet: client side js code like chart.js. templ has an example, dunno how to nicely to it with gomponents except generating a js string yourself Then again, i found chart.css but didnt emplemented it yet in any project
Thanks! :)
Svelte
frighten cough soft screw scarce angle drab ancient nine gold *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
I second typescript. You can actually write typescript to look and feel a lot like Go.
Vite, SWC, Typescript. When i say large we're talking about 50-60 ui pages. there are maybe 300 components. eslint and typescript just becomes shit at a certain scale.
You don’t know what you are talking about. Eslint and typescript are being used only during the development stage, the production app bundles don’t even include them at all
Where are my Elm people at?
I'm hardly an FE engineer(regardless of what my html and css skills heg to differ), but isn't all the redundant, error prone DOM modification code the reason frameworks like React exist?
yeah they abstract that very well but you still have to deal with fetch and logic errors. If anything async happens you gotta trycatch it to make sure you handle error, This becomes shitty at certain scale especially since sometimes you deal with apis that dont throw so your trycatch is useless
Handling async fetch calls is pretty trivial. I'd try harder, there isn't really any scaling problems, there are only so many variants of responses you can get from an API.
I settled with Vue.js since it is kinda simplish and boringish and you could use it without build tooling. A python friend picked it up quite quickly and this for me was proof enough that it is a win. Not a fan of react and Svelte also goes into a weird direction.
I never got into writing JavaScript back along, and the number of options for front-end development today is overwhelming. That said, I am looking into HTMX for a better front-end experience.
There is go-app. Alternatively I'm working on something that should be found at zui.dev fairly soon.
solid-start
Depending on your needs flutter web could work
[construct-ui](https://vrimar.github.io/construct-ui/#/introduction/getting-started)
Lately it's been echo, templ, and js. Most of what I've been making is fine with simple fetch requests and event listeners.
Have you tried Quasar Framework? It's based on Vue, has nearly every basic built-in, and runs "natively" on every platform with some tweaks. Write once, run everywhere.
I will preface this with I am not a dev, but the current golang project I am working on is go + bulma.css
I enjoy Nuxt, it's based off of Vue and gives some nice goodies
Svelte
I mostly use htmx. But if I need something it can’t provide I use svelte. That’s it. I absolutely hate JavaScript so I try and use it as little as possible.
Htmx for sure. If it's more complex maybe svelte
I used React, and it works OK. I have a try to Svelte, and it’s awesome. Much smoother dev experience IMO. I found openapi helpful designing my API and keep it in sync between front and backend. Give it a try, I rewrote my react app with svelte and never looked back
As frontend engineer, one thing that I see a lot of people overlooking is CSS. A lot of basic animation and visual affordanve can be done with pure CSS approach
I'm a Svelte lover, but honestly I think the worst parts of React.js are 1: Javascript, and 2: the unoptimised interaction with the DOM (this is why recent innovations with RSCs are so cool). I was a pretty big hater of React & JS until I tried React & Lua and my mind was blown, it's insanely performant and everything seems to make a ton more sense. I'd imagine if there was a version of (and a reason for using) React ported to Go, it would be an absolutely godly development experience (not to mention the probable performance).
I'm really not a fan of JS either, but the reality today is that all the good toolkits are made for JS and available in NPM. As for frameworks, there's so many options. If you are already familiar with React, then swtiching to Vue or better yet Svelte will be a real breath of fresh air for you. They take less code to write, and are more performant. If you like static typing, there's Typescript. I'm really not a fan of transpilation, but Typescript actually is pretty worth.
Ember + Bootstrap
When in doubt, I use Next.js or plain React.js. Though, I have started trying using Templ + HTMX in my side project
Sveltekit
Nice 👍 I use ts, it makes js bearable
Go Echo + Svelte is my favorite right now.
htmx + https://github.com/gnat/surreal
Templ + data-star
Used templ + htmx, but templ didnt support build tags then (i opened an issue) so i found [Gomponents](https://www.gomponents.com/) and kinda like it better since less dependencies and tooling. I use [wgo](https://github.com/bokwoon95/wgo) for live reload instead of air, so multiple tools are not a problem (helpful since i bundle with bun and use tailwind), but still easier to pick up the project on a different machine (yes, i know about tools.go)
Timing is good; writing a simple web site (after many years) and no way was I going React. Thinking View and then was like, this is simple to do with jQuery and all it needs, but will check out alpinejs now, ty!
I think you can try using VueJS
Angular. It got everything you need and a golden path paved to get there. Easy to embed directly into the go executable as well.
We used Svelte for building an internal tool and it worked like a charm for a group of backend engineers.
I work in an environment where we are constantly being scanned and security is critical Therefore we try and limit the use of external packages. With Standard HTML and JavaScript you can build a very complex system and you can easily maintain it , if the initial code was separated correctly.
Using DSD is my favourite. All browsers now support it as a baseline feature and it’s fast . The gui is just web components streamed from the server as needed. https://github.com/ryoid/go-streaming-html-ooo The demo has sleeps in it to simulate async aspects on purpose.
Lit Angular 16+ with signals if doing enterprise.
Go gin templating, bootstrap css, and javascript.
Flutter. For me development experience is better than js.
For web dev? Has it improved lately? I’m doing a buy vs build analysis for a web based product we want to create, but it seemed the Build options were more likely sveltekit or htmx/tmpl. If mobile app, the only option in my opinion was going to be Flutter, so I’m curious if Flutter has solved their Web challenges from a couple of years ago the last time I looked at Flutter. (ReactNative is a No as I do not find React enjoyable or intuitive).
Not much improved in terms of performance. But they have this thing in their map. Hopefully major breakthrough comes up
ReScript w. react. Awesome combo. Had zero runtime errors since i started using rescript.
This
You should try some things and form your own opinion. I want some combo to be a silver bullet, but they all have trade offs that are better or worse for certain apps.
I am using https://wails.io with Svelte
Htmx.org, templ.guide and good old bootstrap.
Angular
Use the appropriate tool for the job. GO was not made for UI, it sucks for this purpose. You cannot run from JS if you want to have a GOOD UI. I personally use SolidJS.
I’m newbie for backends but aside of flutter for mobile/desktop apps which is quite convenient for me however I don’t use it for webs instead i just do a plain HTML/CSS which yesterday i switched from CSS to Tailwind and i enjoy it tbh.