Earlier quoted context omitted.
Marketing and popularity aren’t unrelated.
Popularity can be faked through marketing.
Popularity is created through marketing.
Show HN: Sinuous – Small, fast, reactive UI library
41–47 of 47 posts
Re: Show HN: Sinuous – Small, fast, reactive UI library
#42This brings Svelte to my mind with mere kbs of code free of a virtual-dom runtime. What should I know more?
@aitchnyu it is similar to Svelte, a lot simpler, early stages, less features though.
I think one of the upsides of Sinuous is that stays much closer to plain JS and to the web standards.
Re: Show HN: Sinuous – Small, fast, reactive UI library
#43I took it for a super simple test run and behavior seems very… weird and incorrect: https://codesandbox.io/s/7o92r . Perhaps I'm just using it wrong, but it's not very clear why this example's state fails to update as you would expect. And I found a few examples of rendering that don't behave as expected.
This is fixed in v0.12.3,
https://codesandbox.io/s/sinuous-counter-hmp8x
The issue below is still to be fixed. It currently returns an array when it should be a DocumentFragment. It's related to the popular `htm` package that Sinuous uses.
html`${seq.map(i => html`Counter #${i} ${counter}`)}`
Re: Show HN: Sinuous – Small, fast, reactive UI library
#44All "top ranked" libraries that use fine-grained observables graph in this benchmark are actually "broken"[1]. 1. https://github.com/ryansolid/solid/issues/46
@localvoid thanks for the investigation, Sinuous can get around this with the template module I believe. Also Sinuous doesn't use the same library as Solid or S.js for tracking dependencies. I'll do some investigating if it has the same issue that you posted.
Your library has the same issue. Also, you are using linear search[1] when removing edges.
1. https://github.com/luwes/sinuous/blob/e33c5e8bcdb461be61f7d0...
Re: Show HN: Sinuous – Small, fast, reactive UI library
#45Earlier quoted context omitted.
Of course you can write a syntax highlighter for HTML in template literals. The lit-plugin VS Code extension provides syntax highlighting plus type checking for bindings. lit-html works by passing the template strings to the built-in HTML parser, so it doesn't need to bring its own. The benefit isn't just avoiding JSX and build steps, but more importantly avoiding VDOM and expensive diffs. Template literals separate…
> lit-html works by passing the template strings to the built-in HTML parser, so it doesn't need to bring its own. What do you call this then: https://github.com/Polymer/lit-html/blob/master/src/lib/temp... ? For example, used here: https://github.com/Polymer/lit-html/blob/master/src/lib/temp... lit-html parses strings with regexps, does an ungodly amount of string concatenation, and only then dumps the resulting str…
The preprocessing is far from an HTML parser. It just helps pick what marker to join template fragments with before passing to the built-in parser.
You seem to think this is enough of a problem to comment on every time I mention lit-html, but you never back it up with any reasoning. Why should it be bad to do some string processing? What's "ungodly" about joining the template fragments?
The fact is, lit-html is very fast, and allows embedding parameterized, updatable markup in standard JavaScript. You don't have to use it.
Re: Show HN: Sinuous – Small, fast, reactive UI library
#46Earlier quoted context omitted.
> lit-html works by passing the template strings to the built-in HTML parser, so it doesn't need to bring its own. What do you call this then: https://github.com/Polymer/lit-html/blob/master/src/lib/temp... ? For example, used here: https://github.com/Polymer/lit-html/blob/master/src/lib/temp... lit-html parses strings with regexps, does an ungodly amount of string concatenation, and only then dumps the resulting str…
The preprocessing is far from an HTML parser. It just helps pick what marker to join template fragments with before passing to the built-in parser. You seem to think this is enough of a problem to comment on every time I mention lit-html, but you never back it up with any reasoning. Why should it be bad to do some string processing? What's "ungodly" about joining the template fragments? The fact is, lit-html is very…
> You seem to think this is enough of a problem to comment on every time I mention lit-html, but you never back it up with any reasoning.
I did, 3 months ago: https://news.ycombinator.com/item?id=19649717
And in that same thread, in a sibling comment: https://news.ycombinator.com/item?id=19643593
That also addresses the "not parsing" part.
Re: Show HN: Sinuous – Small, fast, reactive UI library
#47I took it for a super simple test run and behavior seems very… weird and incorrect: https://codesandbox.io/s/7o92r . Perhaps I'm just using it wrong, but it's not very clear why this example's state fails to update as you would expect. And I found a few examples of rendering that don't behave as expected.
This is fixed in v0.12.3, https://codesandbox.io/s/sinuous-counter-hmp8x The issue below is still to be fixed. It currently returns an array when it should be a DocumentFragment. It's related to the popular `htm` package that Sinuous uses. html`${seq.map(i => html` Counter #${i} ${counter} `)}`