5 ms·

Would have been amazing 10 years ago. Client side js is what would make this messy to use in big projects imho.

steve_adams_86 3y ago
I find myself thinking this as well. I love the idea of this for a few reasons, but there appear to be some hang ups that would cause me to go back to typescript, jsx, and a node process serving it. The developer experience is ridiculously nice in that ecosystem if you’re accustomed to it. So many QOL things have been dealt with and polished. But I do love the idea of something like that dev experience with Go instead of JavaScript powering it. Maybe this would be totally sufficient if you don’t want any SPA/interactivity features? Some sort of live pipe to component state like LiveView or similar could make it so a lot of JS would work implicitly, which might give a lot of the dev experience and user experience ease that people want. I’m not sure. But I do think something would often be missing with this library. Regardless, I love the idea and I’d be stoked to see it grow and improve the developer experience.
sneak 3y ago
I think it still makes sense to make web apps that can function without JS.
- berkes 3y ago
  I use templating in rust (jinja) even with rather some JavaScript. My JavaScript modifies the DOM rather than creating it.
  - philipswood 3y ago
    Stealing this quote for future use: > My JavaScript modifies the DOM rather than creating it.
  - trommlp 3y ago
    I agree. I use server-side rendering heavily in my projects at work and thus largely avoid custom Javascript (edit: the reason is laziness, not because I outright disliked Javascript). But if I want to enable some very basic user interactivity that does not alter "state" in any way, I will always go for a few lines of JS that e.g. toggles the visibility of some items when a button is clicked etc. So (as usual) the key is to find the balance that works for you instead of pursuing one way (only server-side rendering or only SPA Javascript framework). For the time being this approach works very well for me.
  - dgb23 3y ago
    This can get hairy very fast. With every project that grew the need for UI state I either wished I went with client side rendering or did so from the start for the parts that needed it. The issue is: manipulating the DOM can become hard to reason about. You either somehow manage to use the DOM as your source of truth, or you manually sync your state into and out of the DOM, and other things like the URL etc. The “immediate mode” style GUI model is much easier to reason about, because you can think of each render as a fresh start. You don’t need React for this, in fact other libraries do this faster and without additional complexity such as Lit. Plus if you use something with web components, it is easier to mix and match client side and server side templating.
    - sneak 3y ago
      I think JS is fine for some UI sugar, but the app should be usable even with JS off. What you are talking about is indeed better accomplished with an SPA.
      - berkes 3y ago
        I disagree with that premise. While "it must be usable with JS off" was true decades ago for accessability and compatibility reasons, this isn't the case anymore. In my case, the reason for changing and not creating the DOM with JS is pure simplicity. I'll just as gladly make something that won't work, because it cannot be changed this way. Because everyone except for a very few "mormons of the internet" have JS. Modern JS even.
    - berkes 3y ago
      Certainly. I never meant to say "my javascript strategy is X and its the best fit everywhere'. As always "it depends". Though, the simple idea of server-side rendered HTML that is enhanced with JS goes a very long way. > or you manually sync your state into and out of the DOM, and other things like the URL etc. The thing is: with server-side-rendered HTML, the issue of "State" is solved! Hypermedia is a state-machine (REST, HATEOAS etc). What is left, is "state" needed for rendering some variations. You don't need to store state of routers, or the state of JSON objects being pushed through immutable-redux-saga-whatevers. All you need is some state to determine "the accordeon is closed" or "the dropdown is open". I've applied my strategy to a client-side search system once. And while it worked, it quickly showed that actual state-management was needed. I used the URL/history-api to store all state - so that links where sharable, but there's only so much you can put into paths, query strings and anchors. I used HTML5 template tags for templates and components and some simple JS to fetch JSON from a search-backend and pull that through the template to insert into the DOM. What I'm saying is: yes! I agree. You'll need proper and nice design patters or architectures to build a UI of any scale. But I'm also saying: if you move state-management to REST (the backend, server-side-rendered) what you are left with is simple enough that it needs no framework most of the time.
treyd 3y ago
There's a huge swathe of projects that have no (or very little) use for client side js.
lelanthran 3y ago
Depends. If you know at the outset whether your client side is primarily an app or primarily a document, you can choose libraries that make sense. If you're going to shoehorn everything into "this is an app" or "this is a document" then you're going to have problems no matter what you choose.

I find myself thinking this as well. I love the idea of this for a few reasons, but there appear to be some hang ups that would cause me to go back to typescript, jsx, and a node process serving it. The developer experience is ridiculously nice in that ecosystem if you’re accustomed to it. So many QOL things have been dealt with and polished. But I do love the idea of something like that dev experience with Go instead of JavaScript powering it. Maybe this would be totally sufficient if you don’t want any SPA/interactivity features? Some sort of live pipe to component state like LiveView or similar could make it so a lot of JS would work implicitly, which might give a lot of the dev experience and user experience ease that people want. I’m not sure. But I do think something would often be missing with this library. Regardless, I love the idea and I’d be stoked to see it grow and improve the developer experience.

sneak 3y ago

I think it still makes sense to make web apps that can function without JS.

berkes 3y ago
I use templating in rust (jinja) even with rather some JavaScript. My JavaScript modifies the DOM rather than creating it.
- philipswood 3y ago
  Stealing this quote for future use: > My JavaScript modifies the DOM rather than creating it.
- trommlp 3y ago
  I agree. I use server-side rendering heavily in my projects at work and thus largely avoid custom Javascript (edit: the reason is laziness, not because I outright disliked Javascript). But if I want to enable some very basic user interactivity that does not alter "state" in any way, I will always go for a few lines of JS that e.g. toggles the visibility of some items when a button is clicked etc. So (as usual) the key is to find the balance that works for you instead of pursuing one way (only server-side rendering or only SPA Javascript framework). For the time being this approach works very well for me.
- dgb23 3y ago
  This can get hairy very fast. With every project that grew the need for UI state I either wished I went with client side rendering or did so from the start for the parts that needed it. The issue is: manipulating the DOM can become hard to reason about. You either somehow manage to use the DOM as your source of truth, or you manually sync your state into and out of the DOM, and other things like the URL etc. The “immediate mode” style GUI model is much easier to reason about, because you can think of each render as a fresh start. You don’t need React for this, in fact other libraries do this faster and without additional complexity such as Lit. Plus if you use something with web components, it is easier to mix and match client side and server side templating.
  - sneak 3y ago
    I think JS is fine for some UI sugar, but the app should be usable even with JS off. What you are talking about is indeed better accomplished with an SPA.
    - berkes 3y ago
      I disagree with that premise. While "it must be usable with JS off" was true decades ago for accessability and compatibility reasons, this isn't the case anymore. In my case, the reason for changing and not creating the DOM with JS is pure simplicity. I'll just as gladly make something that won't work, because it cannot be changed this way. Because everyone except for a very few "mormons of the internet" have JS. Modern JS even.
  - berkes 3y ago
    Certainly. I never meant to say "my javascript strategy is X and its the best fit everywhere'. As always "it depends". Though, the simple idea of server-side rendered HTML that is enhanced with JS goes a very long way. > or you manually sync your state into and out of the DOM, and other things like the URL etc. The thing is: with server-side-rendered HTML, the issue of "State" is solved! Hypermedia is a state-machine (REST, HATEOAS etc). What is left, is "state" needed for rendering some variations. You don't need to store state of routers, or the state of JSON objects being pushed through immutable-redux-saga-whatevers. All you need is some state to determine "the accordeon is closed" or "the dropdown is open". I've applied my strategy to a client-side search system once. And while it worked, it quickly showed that actual state-management was needed. I used the URL/history-api to store all state - so that links where sharable, but there's only so much you can put into paths, query strings and anchors. I used HTML5 template tags for templates and components and some simple JS to fetch JSON from a search-backend and pull that through the template to insert into the DOM. What I'm saying is: yes! I agree. You'll need proper and nice design patters or architectures to build a UI of any scale. But I'm also saying: if you move state-management to REST (the backend, server-side-rendered) what you are left with is simple enough that it needs no framework most of the time.

treyd 3y ago

There's a huge swathe of projects that have no (or very little) use for client side js.

lelanthran 3y ago

Depends. If you know at the outset whether your client side is primarily an app or primarily a document, you can choose libraries that make sense. If you're going to shoehorn everything into "this is an app" or "this is a document" then you're going to have problems no matter what you choose.