umbrella

You may be interested in bitfields and JS optimised vector operations, the @thi.ng universe has some useful implementations (also a WASM simd one): [0]: https://github.com/thi-ng/umbrella/tree/develop/packages/vec... [1]: https://github.com/thi-ng/umbrella/tree/develop/packages/vec... [2]: https://github.com/thi-ng/umbrella/tree/develop/packages/bit... [3]: https://github.com/thi-ng/umbrella/tree/develop/packages/sim... There's also Structura, which implements a few performant data structures: [4]: https://github.com/zandaqo/structurae/blob/master/README.md#...

It's possible. See https://github.com/thi-ng/umbrella/tree/develop/packages/was... for example.

For people interested in creative coding and data driven visualizations there is also the thi.ng umbrella [1] which provides a large collection of modular micro utilities. Many of them are clojure inspired and are written in functional-style typescript. A lot of these utilities (eg. transducers, multi-methods, stream utilities etc.) are very useful outside the data-visualization space as well. [1] https://github.com/thi-ng/umbrella/

This a is a really wide field. Basically its starts with one of the standard algorithms, like and l-system, a voronoi diagram, or simple combination of sin and cos to draw shapes. Have a look at thi-ng[1], just as example for a library that has implemented a lot of this kind of algorithms. The next step in my process is to think about how to destroy this forms as most of them are used a lot in this field and become boring. Using perlin noise as input to arguments of the algorithms is one way to do this. The other part is to make most all of the input variables easily changeable as most of the time the whole process is like writing the program and then spend a lot of time adapt the parameters until you get some interesting output. So in the end I have a small Svelte app, using Svelte only cause the data binding for the inputs so simple, w

@thi.ng/ksuid https://github.com/thi-ng/umbrella/tree/develop/packages/ksu...

I have limited exposure to Clojure transducers but I spend most of my time writing JS/TS and I've found thi.ng/transducers[0] a pleasure to work with and super elegant for constructing data processing workflows. [0] https://github.com/thi-ng/umbrella/tree/develop/packages/tra...

Okay, here you go https://github.com/thi-ng/umbrella/tree/master/packages/ecs Optimized Typescript ECS with a demo rendering 100,000 live 3D particles

There's also HDOM, part of the larger Umbrella collection of libraries: https://github.com/thi-ng/umbrella/tree/master/packages/hdom Purported benefits from the readme: - Use the full expressiveness of ES6 / TypeScript to define user interfaces - No enforced opinion about state handling, very flexible - Clean, functional component composition & reuse, optionally w/ lazy evaluation - No source pre-processing, transpiling or string interpolation - Less verbose than HTML / JSX, resulting in smaller file sizes - Supports arbitrary elements (incl. SVG), attributes and events in uniform, S-expression based syntax - Supports branch-local custom update behaviors & arbitrary (e.g. non-DOM) target data structures to which tree diffs are applied to - Component life cycle methods & behavior control attributes - Suitable for server-side rendering and

Hey, author here - this post/thread completely hit my by surprise, so apols for late reply: 1) ta_free() is only O(n) if block compaction is enabled, else it's O(1), i.e. a simple cons of the freed block addr to the free list (https://github.com/thi-ng/tinyalloc/blob/master/tinyalloc.c#...) 2) there's no hardcoded alignment (it's configurable via TA_ALIGN macro) and I'm confused about your other comment about not aligning the right address in general. that's a wrong observation and i think you misunderstood the diagram in the readme. 3) it's clearly stated in the readme that this is largely meant for memory constrained situations (or where not large numbers of blocks, realloc or multithreading is needed/available) and so it's not meant to be a replacement for dlmalloc / jemalloc caliber allocators etc. i needed something small & lightweig

@danpeddle already pointed out the important part, but just as an addendum... It all depends what one wants to do with a browser, doesn't it? For some of my projects the browser is merely a sandbox for delivering design tools and I really don't care about the HTML aspects of it at all. For other projects, I only care about HTML generation and use hdom's sister library to generate static HTML from the same components: https://github.com/thi-ng/umbrella/tree/master/packages/hicc... If a user has JS disabled in the browser, fine. If not, then the browser app can hydrate the static HTML and add interactive features and cause cancer :)

The commit table has a 100ms throttle on key press, but I think might have a bug, need to inquire more... :) There's also a stress test here which updates several hundred nodes each frame: https://github.com/thi-ng/umbrella/tree/master/packages/hdom... E.g. each cell shown requires 3 DOM updates per frame, so in the 256 cells config it updates 768 DOM nodes. On my MBP2016 this config runs at ~35 fps, 192 cells (576 real DOM updates) at 59-60fps

just wanted to point out that the joy of these approaches is that you can render on the server with the same components. the method for feeding it data obviously differs, but that's (when done right) pretty minimal. my favourite way of demonstrating this was actually to turn js off and still see everything working. the progressive enhancement flag is still flying, and tools like this make it easier by far. in this case, the server could be (soon!) java/clojure, which is insanely hard to do in an idiomatic, pleasant way with react components. really looking forward to getting this all wired up, and if anyone is interested we're discussing how to get hdom talking to CLJS here: https://github.com/thi-ng/umbrella/issues/36

That's because that demo is using SVG for graphics and hence updating 300+ DOM elements every frame will of course start stuttering... Once I've updated that example to use the hdom-canvas support lib (https://github.com/thi-ng/umbrella/blob/master/packages/hdom...) this will be a non-issue. E.g. here's another demo which draws 10k rectangles @ 60fps. Only once I go >25K, I'm starting to loose framerate (MBP 2016): https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-10k https://demo.thi.ng/umbrella/hdom-canvas-shapes/#points-50k

Thanks! The estuary package started in Java[1] back in 2011, but after years of learning from mistakes, several attempts in Clojure & endless refactoring has now morphed in this TS package[2], which I'm slowly getting more happy with... That demo will need to be refactored too and the plan is to extract those SVG components into their own package sometime during the winter break... [1] https://www.flickr.com/photos/toxi/albums/72157627351329656 [2] https://github.com/thi-ng/umbrella/blob/master/packages/rstr...