6 ms·

Show HN: Sinuous – Small, fast, reactive UI library

76 points by luwes 7y ago

evmar 7y ago
I work in this space so I am curious how your library is different from its similar competitors. I read the docs, but I didn't find anything about the actual model for how it works, like whether the whole UI rerenders on any observable change or not. Maybe consider this paragraph a request for documentation. PS: A minor suggestion: the word "blazing" is so overused in the JS world at this point, when I see it I always at first suspect the app is a parody. If it's fast, then the word "fast" suffices.
- voltagex_ 7y ago
  https://github.com/luwes/sinuous/ https://github.com/luwes/sinuous/ seems to have a little bit more info.
- jazoom 7y ago
  I've started learning Rust after many years of NodeJS. In the past 3 weeks I've seen more "blazing" in Rust library marketing than in all my years of NodeJS combined.
  - evmar 7y ago
    I've noticed it too. It drives me mad.
- deleted 7y ago
  [deleted]
- deleted 7y ago
  [deleted]
theprotocol 7y ago
I've toyed around with the template-strings-to-markup approach before, but couldn't quite figure out how using `map` to generate dynamic lists avoided doing a full O(n) loop upon each update without some kind of diffing engine (other than the browser's own markup diffing).
- luwes 7y ago
  it's indeed not possible, that's why there is a `map` module for rendering lists.
localvoid 7y ago
All "top ranked" libraries that use fine-grained observables graph in this benchmark are actually "broken"[1]. 1. https://github.com/ryansolid/solid/issues/46 https://github.com/ryansolid/solid/issues/46
- luwes 7y ago
  @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.
  - localvoid 7y ago
    Your library has the same issue. Also, you are using linear search[1] when removing edges. 1. https://github.com/luwes/sinuous/blob/e33c5e8bcdb461be61f7d078ac5e606b4745382a/packages/sinuous/observable/src/observable.js#L161 https://github.com/luwes/sinuous/blob/e33c5e8bcdb461be61f7d0...
_hardwaregeek 7y ago
I kinda don't get the whole "put html in template literals". Wouldn't there be no syntax highlighting? And the framework is either putting the string into the DOM with some regex manipulations, which would lead to some very confusing error messages, or it's parsing the string into a tree, which means it needs to implement what's essentially XML parsing, which would come with an overhead. And for what? Avoiding JSX? If you don't like JSX, just desugar it to nested function calls. Or just use a templating language.
- spankalee 7y ago
  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 the static parts if a template from the dynamic and remove the need to diff the parts that never change. It's more efficient.
  - dmitriid 7y ago
    > 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/template.ts#L227 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/template.ts#L97 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 string blob into the DOM.
    - spankalee 7y ago
      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.
Pmop 7y ago
Kind off-topic but related: sometimes I wonder how web development would be if Lisp had somehow won as standard, since we can use to do everything the stack HTML+CSS+JS+Backend-language does, in addition to standardized syntax and standard everything. Oh, standards. Standards.
- schpaencoder 7y ago
  We would probably just treat the html as data, that is normal lisp. So no syntax changes. Same for css I guess. Maybe in twenty years.
  - sooheon 7y ago
    Next best thing today: https://github.com/weavejester/hiccup#syntax https://github.com/weavejester/hiccup#syntax, https://github.com/noprompt/garden#syntax https://github.com/noprompt/garden#syntax
- kitd 7y ago
  From Racket [1]: #lang web-server/insta (define (start request) (response/xexpr '(html (head (title "My Blog")) (body (h1 "Under construction"))))) [1] - https://docs.racket-lang.org/continue/index.html https://docs.racket-lang.org/continue/index.html
  - e12e 7y ago
    And given this site, I suppose a link to arc/anarki is relevant too: https://github.com/arclanguage/anarki/blob/master/apps/news/news.arc https://github.com/arclanguage/anarki/blob/master/apps/news/...
- TeMPOraL 7y ago
  We were so close. Twice, JavaScript had a chance to be Scheme; both times marketing reasons prevailed (first, to capitalize on the marketing spending of Java; later, to compete against Microsoft's JScript). If Scheme was the language of the web, then HTML and CSS being represented as s-expressions would be the most obvious next steps, and we'd be like 15 years ahead in terms of progress.
codegladiator 7y ago
> import { o, h } from 'sinuous'; really recommend you to use proper names instead of single letter variables.
- ezekg 7y ago
  I second this. Also, this example on GitHub doesn't work since html is not defined.
- luwes 7y ago
  Thanks for the feedback! `o` is an alias for `observable`. `observable` can be used as well. `h` is the pragma, comes from hyperscript. it's used by a lot of libraries as the createElement function name so I didn't think this needed a more descriptive name.
aitchnyu 7y ago
This brings Svelte to my mind with mere kbs of code free of a virtual-dom runtime. What should I know more?
- luwes 7y ago
  @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.
ezekg 7y ago
I took it for a super simple test run and behavior seems very… weird and incorrect: https://codesandbox.io/s/7o92r 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.
- luwes 7y ago
  thanks for reporting, seems to be a bug. added to GH issues and will fix asap
- luwes 7y ago
  This is fixed in v0.12.3, https://codesandbox.io/s/sinuous-counter-hmp8x 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`<li>Counter #${i} ${counter}</li>`)}`
  - luwes 7y ago
    also fixed https://codesandbox.io/s/sinuous-array-bug-fixed-4s2nr https://codesandbox.io/s/sinuous-array-bug-fixed-4s2nr
azangru 7y ago
Is anyone else bothered by the two different meanings of the word "observable" (data streams vs getter/setter/proxy), when you are never sure which one was meant until you read the code? Introduction of D3 observable notebooks didn't help :-(

76 points by luwes 7y ago

I work in this space so I am curious how your library is different from its similar competitors. I read the docs, but I didn't find anything about the actual model for how it works, like whether the whole UI rerenders on any observable change or not. Maybe consider this paragraph a request for documentation. PS: A minor suggestion: the word "blazing" is so overused in the JS world at this point, when I see it I always at first suspect the app is a parody. If it's fast, then the word "fast" suffices.

voltagex_ 7y ago
https://github.com/luwes/sinuous/ https://github.com/luwes/sinuous/ seems to have a little bit more info.
jazoom 7y ago
I've started learning Rust after many years of NodeJS. In the past 3 weeks I've seen more "blazing" in Rust library marketing than in all my years of NodeJS combined.
- evmar 7y ago
  I've noticed it too. It drives me mad.
deleted 7y ago
[deleted]
deleted 7y ago
[deleted]

theprotocol 7y ago

I've toyed around with the template-strings-to-markup approach before, but couldn't quite figure out how using `map` to generate dynamic lists avoided doing a full O(n) loop upon each update without some kind of diffing engine (other than the browser's own markup diffing).

luwes 7y ago
it's indeed not possible, that's why there is a `map` module for rendering lists.

localvoid 7y ago

All "top ranked" libraries that use fine-grained observables graph in this benchmark are actually "broken"[1]. 1. https://github.com/ryansolid/solid/issues/46 https://github.com/ryansolid/solid/issues/46

luwes 7y ago
@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.
- localvoid 7y ago
  Your library has the same issue. Also, you are using linear search[1] when removing edges. 1. https://github.com/luwes/sinuous/blob/e33c5e8bcdb461be61f7d078ac5e606b4745382a/packages/sinuous/observable/src/observable.js#L161 https://github.com/luwes/sinuous/blob/e33c5e8bcdb461be61f7d0...

_hardwaregeek 7y ago

I kinda don't get the whole "put html in template literals". Wouldn't there be no syntax highlighting? And the framework is either putting the string into the DOM with some regex manipulations, which would lead to some very confusing error messages, or it's parsing the string into a tree, which means it needs to implement what's essentially XML parsing, which would come with an overhead. And for what? Avoiding JSX? If you don't like JSX, just desugar it to nested function calls. Or just use a templating language.

spankalee 7y ago
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 the static parts if a template from the dynamic and remove the need to diff the parts that never change. It's more efficient.
- dmitriid 7y ago
  > 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/template.ts#L227 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/template.ts#L97 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 string blob into the DOM.
  - spankalee 7y ago
    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.

Pmop 7y ago

Kind off-topic but related: sometimes I wonder how web development would be if Lisp had somehow won as standard, since we can use to do everything the stack HTML+CSS+JS+Backend-language does, in addition to standardized syntax and standard everything. Oh, standards. Standards.

schpaencoder 7y ago
We would probably just treat the html as data, that is normal lisp. So no syntax changes. Same for css I guess. Maybe in twenty years.
- sooheon 7y ago
  Next best thing today: https://github.com/weavejester/hiccup#syntax https://github.com/weavejester/hiccup#syntax, https://github.com/noprompt/garden#syntax https://github.com/noprompt/garden#syntax
kitd 7y ago
From Racket [1]: #lang web-server/insta (define (start request) (response/xexpr '(html (head (title "My Blog")) (body (h1 "Under construction"))))) [1] - https://docs.racket-lang.org/continue/index.html https://docs.racket-lang.org/continue/index.html
- e12e 7y ago
  And given this site, I suppose a link to arc/anarki is relevant too: https://github.com/arclanguage/anarki/blob/master/apps/news/news.arc https://github.com/arclanguage/anarki/blob/master/apps/news/...
TeMPOraL 7y ago
We were so close. Twice, JavaScript had a chance to be Scheme; both times marketing reasons prevailed (first, to capitalize on the marketing spending of Java; later, to compete against Microsoft's JScript). If Scheme was the language of the web, then HTML and CSS being represented as s-expressions would be the most obvious next steps, and we'd be like 15 years ahead in terms of progress.

codegladiator 7y ago

> import { o, h } from 'sinuous'; really recommend you to use proper names instead of single letter variables.

ezekg 7y ago
I second this. Also, this example on GitHub doesn't work since html is not defined.
luwes 7y ago
Thanks for the feedback! `o` is an alias for `observable`. `observable` can be used as well. `h` is the pragma, comes from hyperscript. it's used by a lot of libraries as the createElement function name so I didn't think this needed a more descriptive name.

aitchnyu 7y ago

This brings Svelte to my mind with mere kbs of code free of a virtual-dom runtime. What should I know more?

luwes 7y ago
@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.

ezekg 7y ago

I took it for a super simple test run and behavior seems very… weird and incorrect: https://codesandbox.io/s/7o92r 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.

luwes 7y ago
thanks for reporting, seems to be a bug. added to GH issues and will fix asap
luwes 7y ago
This is fixed in v0.12.3, https://codesandbox.io/s/sinuous-counter-hmp8x 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`<li>Counter #${i} ${counter}</li>`)}`
- luwes 7y ago
  also fixed https://codesandbox.io/s/sinuous-array-bug-fixed-4s2nr https://codesandbox.io/s/sinuous-array-bug-fixed-4s2nr

azangru 7y ago

Is anyone else bothered by the two different meanings of the word "observable" (data streams vs getter/setter/proxy), when you are never sure which one was meant until you read the code? Introduction of D3 observable notebooks didn't help :-(