5 ms·

I removed all of our React and replaced it with Web Components, and I'm not missing anything. I'm sticking to cached static resources, and just sending data ov

I removed all of our React and replaced it with Web Components, and I'm not missing anything. I'm sticking to cached static resources, and just sending data over. Not rendering from the server, but not writing single-page apps, either. The more you render from the server, the larger your caches end up. Not doing that for HTML. Just HTML, CSS, and JavaScript. No tooling. No building. Web Components and fetch(). No frameworks on the client-side. Express still on the server. I'm trying to optimize for not swapping out dependencies on a several year scale, and it's working out pretty well so far. I removed React because they're not interested in UMD builds anymore, and I'm not going to jump through hoops to make it work on my end, either.

morganherlocker 2y ago
Same, and I've found this works quite well with a C++ backend. Just send over binary data as struct-of-arrays, load it into typed arrays, render components. Your app will be bottlenecked only on bandwidth, as it should be, even for heavy 3d applications. There's nothing fundamentally stopping react apps from being fast like this, but the dependency snowball has a way of hiding accumulated dynamic memory allocations and event listeners. Instead, we should be intentionally grouping allocations and events, keeping them contained to a few well understood pieces of code. Without this, these apps could be ported to native C++ or rust and they would still be nearly as slow because there is no magic language that can make a slop of millions of tiny dynamic allocations fast and low overhead.
- kopirgan 2y ago
  C++ backend? Could you elaborate please?!
  - morganherlocker 2y ago
    If most data between the backend/frontend is raw numeric array binary blobs, and you target array types that can be loaded directly into JS TypedArrays (int32_t* -> Int32Array, float* -> Float32Array, etc.), you have a more or less optimal data transfer mechanism with zero dependencies. The JS parsing is faster than the fetching, even with 10s of millions of items, provided you keep the number of arrays fixed and reasonably small. This is a natural fit for data-oriented programming in most systems languages, including C++. It's also compatible with numpy and any other dynamic language backends that have a performance-oriented array primitive or lib. The data can be served dynamically from memory, or written to files on a static server like nginx.
TheFragenTaken 2y ago
What kind of project did you "remove all React"? Also, curious whether you ended up with vanilla Web Components, or fast-element/LitElement/others?
- andrewmcwatters 2y ago
  Completely vanilla, just using the web standards themselves. this.innerHTML with a string template prefixed with /* html */ so syntax highlighting is applied.
fergie 2y ago
Interesting- how to you handle templating?
oxavier 2y ago
I find this no-nonsense approach very appealing. > The more you render from the server, the larger your caches end up. Not doing that for HTML. Is HTML really that much larger or complex than JSON? Based on the following it seems to be only +10-15% larger (n = 1 dataset obviously). https://github.com/1cg/html-json-size-comparison https://github.com/1cg/html-json-size-comparison Is the amount of data transfer the main reason to use JSON or do you find Web Components play better with JSON payloads? I could imagine the template string being rendered on the server, fetch()-ed by the client and swapped with this.innerHTML. Do you manage any amount of cross-component state? It's one use case where JSON would win over "HTML over the wire".

morganherlocker 2y ago

Same, and I've found this works quite well with a C++ backend. Just send over binary data as struct-of-arrays, load it into typed arrays, render components. Your app will be bottlenecked only on bandwidth, as it should be, even for heavy 3d applications. There's nothing fundamentally stopping react apps from being fast like this, but the dependency snowball has a way of hiding accumulated dynamic memory allocations and event listeners. Instead, we should be intentionally grouping allocations and events, keeping them contained to a few well understood pieces of code. Without this, these apps could be ported to native C++ or rust and they would still be nearly as slow because there is no magic language that can make a slop of millions of tiny dynamic allocations fast and low overhead.

kopirgan 2y ago
C++ backend? Could you elaborate please?!
- morganherlocker 2y ago
  If most data between the backend/frontend is raw numeric array binary blobs, and you target array types that can be loaded directly into JS TypedArrays (int32_t* -> Int32Array, float* -> Float32Array, etc.), you have a more or less optimal data transfer mechanism with zero dependencies. The JS parsing is faster than the fetching, even with 10s of millions of items, provided you keep the number of arrays fixed and reasonably small. This is a natural fit for data-oriented programming in most systems languages, including C++. It's also compatible with numpy and any other dynamic language backends that have a performance-oriented array primitive or lib. The data can be served dynamically from memory, or written to files on a static server like nginx.

TheFragenTaken 2y ago

What kind of project did you "remove all React"? Also, curious whether you ended up with vanilla Web Components, or fast-element/LitElement/others?

andrewmcwatters 2y ago
Completely vanilla, just using the web standards themselves. this.innerHTML with a string template prefixed with /* html */ so syntax highlighting is applied.

fergie 2y ago

Interesting- how to you handle templating?

oxavier 2y ago

I find this no-nonsense approach very appealing. > The more you render from the server, the larger your caches end up. Not doing that for HTML. Is HTML really that much larger or complex than JSON? Based on the following it seems to be only +10-15% larger (n = 1 dataset obviously). https://github.com/1cg/html-json-size-comparison https://github.com/1cg/html-json-size-comparison Is the amount of data transfer the main reason to use JSON or do you find Web Components play better with JSON payloads? I could imagine the template string being rendered on the server, fetch()-ed by the client and swapped with this.innerHTML. Do you manage any amount of cross-component state? It's one use case where JSON would win over "HTML over the wire".