Possible alternative with less code? Or maybe not?

[dumblob]

I noticed you really want to "get the job done" in your projects. That's an awesome attitude.

Maybe the following will inspire you in your endeavors. It has some potential to save you some time :wink:.

https://hotwired.dev/

(note I'm in no way affiliated with them)

Feel free to close this for lack of actionable items.

One way or another, keep up the good work!

[joshbrew]

Thanks, yeah I've shied away from server side rendering, lately am getting into web components which is finally feeling like how I should be doing this. I just made this lib to be lazy in the react project we're working on but I wrote a native web component lib here that's pretty similar: https://github.com/moothyknight/domelement

[dumblob]

Thanks, yeah I've shied away from server side rendering, lately am getting into web components which is finally feeling like how I should be doing this.

That sounds interesting. Would you have any writeup about your journey?

I for myself didn't set out on such a journey yet (and not sure I'll ever will), so I'm eager to hear how it all developed in your case :wink:.

[joshbrew]

Haha am waiting to do more engineering design writeups when I finally feel qualified. But in brief:

• I learned C++, Matlab and Python. Hated all of it for trying to actually make UX. Did learn a ton about systems, game engines and performance though.
• very sloooowly reconfigured my brain for web, at the same time web's seen massive performance improvements in the past 5 or 6 years and with webgpu dropping it's genuinely viable to squeeze all the juice out of a computer alongside the basic multithreading support of web workers. Also, it's the most interoperable and lightest weight choice of application language out of the gate while still giving you nearly full freedom at least at the higher level (which we have low level now too via wasm but ugh assembly programming...)
• now focused on learning high performance and syntactic minimalism via web because both are major issues if you want a full stack framework and also your sanity to then move onto designing something genuinely complex as a software like CAD or game engines, otherwise for real time high channel count sensor streams because that's easier and real time signal analysis skills are rare and for cool kids. I still can't tell you what a complex number is though lol, fkn parametrics man.

I haven't seriously been coding until like 3 years ago, and even then it was sporadic for another year or so, long ways to go still I'd say. Just starting to feel sort of comfortable with data structures & algorithms but I am mostly self taught there so I don't have much to compare to.

Also main reason NOT to do serverside rendering is for standalone applications. I treat everything like its gonna be an application not a web page. The web page part basically now serves as a dynamic compiler and you can serve code blocks dynamically instead of just web pages. My brainatplay demo rarely is over 2mb on a page, so threejs etc only show up in the browser on demand rather than dumping a 100mb application on you with a thousand disconnected dependencies. Mainly I just like flexing with my 20kb apps haha, you ever see those 6kb game competitions? One guy made a 3d metroid demo with lighting and textures in 6kb.... the web should be that.

[dumblob]

Cool. Being self-taught means you're really much into the stuff. Which is great!

Also main reason NOT to do serverside rendering is for standalone applications. I treat everything like its gonna be an application not a web page. The web page part basically now serves as a dynamic compiler and you can serve code blocks dynamically instead of just web pages.

Ah, this didn't appear to me. I'll think about this as I'm genuinely offline-first/local-first guy :wink:. For some reason I never thought some might think server-side rendering is an obstackle for standalone apps (because it isn't :wink:). Thanks for mentioning this!

you ever see those 6kb game competitions? One guy made a 3d metroid demo with lighting and textures in 6kb.... the web should be that.

:+1:

[joshbrew]

I'm VERY into it haha, I've watched more of these damn lectures on computer science and math/ML/complex systems theory than I care to admit, I'm a slow learner though when it comes to practice but as long as I don't get hit by a truck in the meantime then I'll get REALLY good eventually.

It just depends on where you're coming from. I'm coming from doing my <100kb handwritten webapp served on an ESP32 to handle its data stream with a default UI, so the browser has all of the dependencies and it can pull third party resources if it connects through local wifi but that's not necessary. Was a good lesson in resource management haha. Local computers are so good now that doing SSR on a local node server would be a bit moot as you already have a whole browser engine in front of you.

[dumblob]

I'm VERY into it haha, I've watched more of these damn lectures on computer science and math/ML/complex systems theory than I care to admit, I'm a slow learner though when it comes to practice but as long as I don't get hit by a truck in the meantime then I'll get REALLY good eventually.

:smile:

It just depends on where you're coming from. I'm coming from doing my <100kb handwritten webapp served on an ESP32 to handle its data stream with a default UI, so the browser has all of the dependencies and it can pull third party resources if it connects through local wifi but that's not necessary. Was a good lesson in resource management haha. Local computers are so good now that doing SSR on a local node server would be a bit moot as you already have a whole browser engine in front of you.

Yep, that's admittedly a bit different use case which splits the burden among two servers - one on ESP32 and one is Chrome Web Store - with the latter needing some manual intervention to make it behave similarly to PWA.

I'll follow from time to time what you're working on. I hope some day I'll find some use of your creations (HEGs etc.) and support you also financially.