non-grid-path-finder
stampino-element
| non-grid-path-finder | stampino-element | |
|---|---|---|
| 2 | 1 | |
| 12 | 38 | |
| - | - | |
| 0.0 | 6.2 | |
| about 1 year ago | about 1 month ago | |
| Rust | TypeScript | |
| - | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
non-grid-path-finder
-
An aesthetically pleasing pathfinding visualizer
Shameless self-promotion: A non-grid-based path finder I made with Rust and compiled to WASM: https://scleox.github.io/non-grid-path-finder/
(I made it a long time ago and I think the CI is broken...)
-
Show HN: Skruv – No-dependency, no-build, small JavaScript framework
I have tried writing websites with rust instead of JavaScript. Unfortunately, the tooling is just not there. More specifically, I am talking about wasm-bindgen, which provides two-way bindings. The problem with it is that since all the declarations are generated with build.rs, there is no autocompletion. Since I am spoiled by modern tooling, no autocompletion to me means not feasible pass demo stage. (https://github.com/rust-lang/rls/issues/1489)
Aside from the lack of autocompletion, passing rust closures to js land (DOM) is extremely janky as well. However, that might be caused by my lack of experience with rust.
(If you are curious, this is what I made: https://github.com/SCLeoX/non-grid-path-finder)
stampino-element
-
Show HN: Skruv – No-dependency, no-build, small JavaScript framework
As someone who helped lead the Polymer team in the transition from HTML-first Polymer to JavaScript-first lit-html/LitElement, I have some experience building approaches.
I think that JavaScript-first is far better for templating the more general case (or the lower level foundation) because JavaScript is where your data lives. It's generally much easier to bring markup into JavaScript than it is data and data manipulation into HTML.
In HTML you need re-invent expressions, scopes, control-flow, references, and imports. You're going to spend more time and code implementing a less expressive, slower, and more proprietary system.
In JavaScript you just need a way to describe fragments of the resulting DOM (whether you prefer JSX, function calls, or tagged template literals), and the rest is just JavaScript.
Now, I do see benefit from the HTML-first approach for a lot of people and some use cases. One reason I also push on web components so hard is that with interop comes flexibility in allowing a mix-and-match of approaches. As a side-project I'm working on an HTML-first declarative component system layered on top of LitElement: https://github.com/justinfagnani/stampino-element
What are some alternatives?
hyperscript - Create HyperText with JavaScript.
es-module-shims - Shims for new ES modules features on top of the basic modules support in browsers
Water.css - A drop-in collection of CSS styles to make simple websites just a little nicer
vanilla-teuxdeux - A case study to implement modern js app with vanilla web technologies
reagent - A minimalistic ClojureScript interface to React.js
mercury - A truly modular frontend framework
pathfinding-visualizer