microsite VS procedural-gl-js

None are ready for the public yet, but all in the hopper or under serious consideration:

- Personal site/blog with a bunch of algorithmically generated art and other fun stuff, built on Node/Preact but progressively enhanced/almost completely JS-free at runtime. Motivation for the build approach is that I’m on the low/no client JS static site bandwagon but I quite like the DX of JSX components and CSS-in-JS.

- I’m using a few excellent existing tools[1][2] for said site which unfortunately aren’t designed to work well together, so I have a variety of wrapper tooling that makes them live peacefully together. I’m also developing a bunch of other build-stage tools for my use cases. I plan to open source (or hopefully contribute back) all of that as soon as I’m satisfied with their quality.

- A set libraries for building declarative, type safe, automatically validated/documented service API boundaries (HTTP/REST to start, but I also plan to support other transport protocols) — think io-ts[3] type interfaces but you get swagger docs for free in a transport-agnostic interface. I’ve built this kind of thing before, it was wildly successful in real world use, but it’s proprietary to a previous employer and I’m starting over with all the stuff I learned in hindsight.

- A “nag me” app that’s basically “reading list” plus “reminders” with minimal config, eg “nag me soon” or “nag me after a while”. My personal use case is I frequently screenshot/text myself/etc stuff I want to look at later (usually on phone but need a computer to dive in), then it just goes down the memory hole. I’ve tried setting reminders but it’s often too much fuss, and I’m far too ADHD to use a passive list.

- Exploring building yet another FE build tool/bundler that’s explicitly multi-stage/sequential with static input/output validation, per-step/time travel debugging. Motivation is that existing tools are just a big ball of config magic and totally inscrutable. I’d likely wrap existing build tools because their set of responsibilities isn’t my motivation and I don’t want to introduce that much more new API surface area to weary FE devs.

[1]: https://github.com/natemoo-re/microsite

Microsite es un generador de sitios estáticos (SSG) construido sobre Snowpack y que utiliza Preact como framework.

Nice writeup, I always like it when the shaders are highlighted like this. I got started in a similar way 7 years ago and have been making 3D terrains with THREE.js & WebGL since.

The real fun begins when you need to implement some sort of Level-of-Detail system and streaming in data to give the illusion of high detail everywhere without sacrificing performance.

Last year I released an open-source framework (https://github.com/felixpalmer/procedural-gl-js) for creating 3D terrains for web applications, you can see Uluru here: https://www.procedural.eu/map/?longitude=131.036&latitude=-2... (unfortunately the aerial imagery from our default provider isn't as high resolution as other places in Europe)

Great visualization and approach with compressing the tile data. Do you have a comparison of how much smaller the payload ends up being compared to simply sending PNG files?

I use PNGs to encode elevation data in my 3D mapping library (https://github.com/felixpalmer/procedural-gl-js/) and this does a pretty good job of compressing the data, for example in the ocean the PNG files are also very small as the image is mostly black. Different use case I now as your data is much more sparse, but I wonder how close the PNG compression would be compared to your approach.

Yeah, the React parts of this are very minimal. I'm not really sure what using it gets you, since it just manages a single div.

The _actual_ library that does all the work is here: https://github.com/felixpalmer/procedural-gl-js

- Tiny filesize means library is parsed fast. Package size is less than THREE.js thanks to code stripping

Check it out on Github: https://github.com/felixpalmer/procedural-gl-js/

The imagery comes from the Orthofoto dataset on https://www.basemap.at/ - the actual texturing is done by the Procedural GL JS library https://github.com/felixpalmer/procedural-gl-js