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.
Oh, standards. Standards.
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.
#lang web-server/insta
(define (start request)
(response/xexpr
'(html
(head (title "My Blog"))
(body (h1 "Under construction")))))
https://github.com/arclanguage/anarki/blob/master/apps/news/...
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.
1. https://github.com/luwes/sinuous/blob/e33c5e8bcdb461be61f7d0...
really recommend you to use proper names instead of single letter variables.
`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.
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>`)}`
Introduction of D3 observable notebooks didn't help :-(
I think one of the upsides of Sinuous is that stays much closer to plain JS and to the web standards.
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.
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 string blob into the DOM.
As HN user stevebmark said [2]:
--- start quote ---
…we’ve learned not to write code in strings. You’d think this would be a fundamental law of software engineering
…
Writing code, not strings, means you can do everything to it that you can do to code. You can type check code. You can lint it. You can optimize it, compile it, validate it, syntax highlight it, format it with tools like Prettier, tree shake it…
--- end quote ---
[1] https://dmitriid.com/blog/2019/03/tagged-template-literals/
Agreed, but not for the reasons you quoted.
It should be a law of software engineering because when you're writing code, you aren't writing strings, you're writing a serialized and prettified form of a tree. So when you have two pieces of code you want to join together, you should join trees, not strings.
Breaking this law is precisely why things like SQL Injection even exist in the first place.
Are there major IDEs that don't support language injections?
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.
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.
I’m not sure that it matters so much to the discussion, but it is a completely unique feature, and really has to be mentioned when discussing what tagged template literals offer.
EDIT: Looked for a good reference - best detailed description I could find was here: https://exploringjs.com/es6/ch_template-literals.html#sec_im...
Thank you for the explanation!