Has anyone managed to get SSR to work consistently?

[timadevelop]

It seems like NodeJS server process leaks leading to a crash and I wonder if it's something on my side.

I could go down the road of debugging these leaks, though I'm not sure it's worth the time considering other folks gave up and disabled SSR.

Are there people who actually use SSR with live_svelte & NodeJS in production?

The project is on 0.13.1 vsn.

Thx for your work @woutdp

[acco]

FWIW, we too experienced Node process leaks with SSR enabled. Tried a few different things, including configuring Node to GC more aggressively. Eventually decided it wasn't worth it and disabled SSR.

[Valian]

The default implementation of NodeJS package clears import cache on each call.

It kills performance and possibly introduces memory leaks. I'm not exactly sure what's the best way to set NODE_ENV, since worker env is not customisable. Maybe setting env variable for elixir process would be enough, since ENV should be inherited? 🤔

I noticed all these problems when implementing PR with ESM modules support needed for my library LiveVue to function correctly. There's some actions from maintainers, hopefully it will get better soon 🤞

[dmbr0]

sorry for the dumb question but why can't phoenix/elixir take the place of SSR?

[timadevelop]

quick reply:

seems like changing NODE_ENV fixes it to some point, but I had no time to perform stress tests. So cannot verify it works yet.

sorry for the dumb question but why can't phoenix/elixir take the place of SSR?

@dmbr0 Phoenix can SSR anything you want but there's a case when you have lots of JS-based components written in Svelte / Vue / React / whatever that are not ported to LiveView / PHX. One can go and "copy" needed components into heex templates but this might become a mess to support. Hence most people need to render JS components on the server for SSR -> Node or Bun dependency is inevitable.

[johninvictus]

I am hoping this issue is fixed soon

[dmbr0]

@timadevelop how would it be anymore of mess than the components being somewhere else?

I just feel like the erlang VM would be better suited at taking over SSR than the node VM. these memory leaks are notorious and the erlang VM is much better at managing system resources.

[dmbr0]

after my limited interaction with this I just think having the erlang/elixir VM take over SSR from node would be incredible with svelte.

[timadevelop]

@dmbr0

I just feel like the erlang VM would be better suited at taking over SSR than the node VM. after my limited interaction with this I just think having the erlang/elixir VM take over SSR from node would be incredible with svelte.

Maybe I misunderstood your statement, but there's no way to render or run JS without node/bun/other JS runtime. There might be someone who is fond of binding BEAM with V8 / Chakra / JSC but it's a huge amount of work and will likely come with its own problems.

how would it be anymore of mess than the components being somewhere else?

If you mean ditching JS on server side and leaving it only on client-side, you're looking into something like alpine / jquery / lit / liveview. In all other cases, when traditional frameworks like React / Solid / Svelte are used, supporting 2 versions of the same component in 2 different ecosystems is unfeasible for most teams imo. We're stuck with these frameworks until someone creates react-aria / radix alternative that works on all platforms with all languages. i.e. "universal accessible component system" that runs everywhere you want: on BEAM without JS, on JS env, in browser, in ruby, etc. Years ago I thought about creating such a design system + a set of libraries for many platforms, came to a conclusion that I need tons of cash and time to achieve this. Web components ergonomics are not on par with modern frameworks (unfortunately).

SSR with JS runtime on backend is defo not a "lean" solution, it's a mess we have to live with because of hiring and existing ecosystems. I think this mess is one of the reasons why @dhh created turbo/hotwired/stimulus combo in ruby world. Also @chrismccord works on liveview / heex components, and even though it has potential, no company invests heavily in it due to reasons like hiring budgets uncertain future adoption etc. Things like Petal framework are just not on par with React / Svelte / Vue world.

Devs need to ship -> no time invest into something better -> occasional memory leak is acceptable for most companies because these modern JS frameworks allow them to ship fast.