6 ms·

Why is this syntax so popular? I haven't used it but it smells so weird.. https://skruv.io/Tutorial/step3/ https://skruv.io/Tutorial/step3/ (Inside the renderN

by queuep 5y ago

Why is this syntax so popular? I haven't used it but it smells so weird.. https://skruv.io/Tutorial/step3/ https://skruv.io/Tutorial/step3/ (Inside the renderNode) Nontheless, I like this direction of a small framework keeping it simple, like Vue was initially.

Oddskar 5y ago
Because you can pretty easily add a layer on top to make it nicer (like JSX). And it has the benefit of working with e.g. Typescript and give you type safety out of the box, unlike Frameworks that have their own template systems.
- skinkestek 5y ago
 Agree: Once one deliberately throws out support for all but JS-enabled browsers, HTML doesn't matter that much anymore and at that point tooling support like making it possible to work in TypeScript becomes a nice bonus. (Note however that while enjoy projects like these and also don't vilify most people who wrote JS-dependent websites, not even in my thoughts, I might think of those who write html with optional js-features as nicer people, more thoughtful/considerate and less childish ;-)
 - strogonoff 5y ago
 Throwing out support for HTML-only browsers is not a prerequisite for authoring a reactive UI with JS. Using Next.js, react-static, or even plain ReactDOM’s renderToString() you can generate static HTML+CSS for your pages, which would then be hydrated and become interactive only in user agents with JS enabled. Authoring components with awareness of that, you can degrade gracefully while reaping the benefits of type checking, reusable components etc. at development stage.
 - skinkestek 5y ago
 No, but the moment you depend on Javascript being enabled in the client, why not get rid of as much of html as possible and use a sane language like TypeScript?
 - strogonoff 5y ago
 Yeah, upon rereading I see I wasn’t replying to what you meant.
- vagrantJin 5y ago
 Honest question, why jsx over html/js and why particularly Typescript?
 - madeofpalk 5y ago
 Why not Typescript? Using a typed languge is such a productivity boon.
 - vagrantJin 5y ago
 This a is an answer thats made for those "why you should use Typescript in 2021" medium articles that pop up on my feed ad nauseum. The word productive on its own is wholly meaningless without elaboration. What makes a typed language productive? Does the size of the project matter?, why is vanilla js not productive? Is it a lines of code metric? Is it a test suite efficiency metric? Is it a quality metric?
 - Oddskar 5y ago
 Providing a thorough answer to your question would require a lengthy article. It's a bit much of an ask to have someone do this for you on HN. But very briefly I would say that these are the benefits as I see it: * Access to improved tooling. E.g. refactoring by renaming things is much easier to do without breaking things. Also auto-complete when using third party libraries is a huge benefit. * Some errors are automatically caught during build-time. E.g. checking the data used in a template lines up with what the component should be passing to that template. Without typescript one should probably verify this via unit tests. With TS these tests are superfluous. * Improved documentation. It's a lot easier to understand what the shapes are of data is that is being passed around in the application. It also provides the opportunity to define these in central locations (e.g. in the form of interfaces) which can then have additional documentation added to them. I think the benefits are not so much specific to TS as they are general benefits of using types and a typed ecosystem.
 - SCLeo 5y ago
 I have not used Skruv, but from my experience with vanilla js (document.createElement('div')), hyperscript (h('div')), and jsx (<div/>), jsx is hoesntly much easier to write and to read.
tobr 5y ago
What’s weird about it? It’s the most obvious declarative way to build a hierarchy of objects in vanilla JS. It’s easy to read and straightforward to understand; if you want abstractions around it is completely obvious how you would go about building those yourself.
- weego 5y ago
  recreating html node declaration in JS with janky and verbose syntax for attributes and child nodes is not an answer to a problem anyone has.
  - tobr 5y ago
    I guess I shouldn’t reply to flippant drive-by comments, but how the heck can that be considered verbose, and what’s your non-janky suggestion that doesn’t introduce some kind of extra tooling or parsing?
  - blacktriangle 5y ago
    The linked code doesn't show the full value of this technique, since its straightforward HTML that's coming out. Now what happens if you want a collection of list items generated by looping over an array? Assign classes based on some logical conditional? Conditional rendering? These are problems everybody has and every template language tries to solve with their own custom syntax. The point of this method is that rather than create some half-assed template language, you just write Javascript code that acts on and generates a data structure that can then be converted into HTML.
- pjmlp 5y ago
  Web components and tagged strings are the most obvious way.
  - tobr 5y ago
    Tagged template literals can certainly be nice, but they basically require you to ship a parser to the browser, or introduce a complex build step, or give up the idea of doing vdom-like patched updates. (Not sure I see how web components fit into this discussion.)
scoopertrooper 5y ago
OP was trying to keep their framework small and avoid a build step, both of which (especially the latter) would preclude the use of a DSL like JSX. Are you suggesting another approach other than function composition?
deleted 5y ago
[deleted]
azangru 5y ago
I believe this is the original syntax for describing a virtual DOM.
gmac 5y ago
I have no problem with it, except in this variant the empty braces everywhere are a bit annoying (and seem very likely unnecessary).
lhorie 5y ago
There are two major flavors of syntax when it comes to minimalist/no-build JS templating: 1) tree of function calls like this or hyperscript - this is popular because the language syntax enforces markup well-formedness (e.g. you can't express `foo</s>`) and it's easy to implement minimalist engines on top of this API style. Hyperscript in particular is also compatible with JSX. 2) template strings - this is popular because you can actually write angled brackets without a build step, but it tends to come at a cost of less syntactical safety (e.g. `foo</s>` may or may not explode early enough in the dev cycle) and some might argue the semantics of various syntactical permutations are less clear and/or more complex to implement (e.g. what are these supposed to do? `<${a}>`, `<a ${[b, c, d]} />`, `<a ${'b=c'} />`, `a<b, c>d`, etc)
- spankalee 5y ago
 For template strings you can have a compiler or IDE plugin check the templates. For lit-html we have lit-analyzer, ts-lit-plugin, and lit-plugin (VS code) that do both general HTML linting and lit-html specific type-checking and syntax highlighting.
 - lhorie 5y ago
 Sure, when you have compilers and third-party static analysis tools, the palette of what is feasible broadens significantly. I was speaking strictly about no-build-step frameworks.

by queuep 5y ago

Oddskar 5y ago

Because you can pretty easily add a layer on top to make it nicer (like JSX). And it has the benefit of working with e.g. Typescript and give you type safety out of the box, unlike Frameworks that have their own template systems.

skinkestek 5y ago
Agree: Once one deliberately throws out support for all but JS-enabled browsers, HTML doesn't matter that much anymore and at that point tooling support like making it possible to work in TypeScript becomes a nice bonus. (Note however that while enjoy projects like these and also don't vilify most people who wrote JS-dependent websites, not even in my thoughts, I might think of those who write html with optional js-features as nicer people, more thoughtful/considerate and less childish ;-)
- strogonoff 5y ago
  Throwing out support for HTML-only browsers is not a prerequisite for authoring a reactive UI with JS. Using Next.js, react-static, or even plain ReactDOM’s renderToString() you can generate static HTML+CSS for your pages, which would then be hydrated and become interactive only in user agents with JS enabled. Authoring components with awareness of that, you can degrade gracefully while reaping the benefits of type checking, reusable components etc. at development stage.
  - skinkestek 5y ago
    No, but the moment you depend on Javascript being enabled in the client, why not get rid of as much of html as possible and use a sane language like TypeScript?
    - strogonoff 5y ago
      Yeah, upon rereading I see I wasn’t replying to what you meant.
vagrantJin 5y ago
Honest question, why jsx over html/js and why particularly Typescript?
- madeofpalk 5y ago
 Why not Typescript? Using a typed languge is such a productivity boon.
 - vagrantJin 5y ago
 This a is an answer thats made for those "why you should use Typescript in 2021" medium articles that pop up on my feed ad nauseum. The word productive on its own is wholly meaningless without elaboration. What makes a typed language productive? Does the size of the project matter?, why is vanilla js not productive? Is it a lines of code metric? Is it a test suite efficiency metric? Is it a quality metric?
 - Oddskar 5y ago
 Providing a thorough answer to your question would require a lengthy article. It's a bit much of an ask to have someone do this for you on HN. But very briefly I would say that these are the benefits as I see it: * Access to improved tooling. E.g. refactoring by renaming things is much easier to do without breaking things. Also auto-complete when using third party libraries is a huge benefit. * Some errors are automatically caught during build-time. E.g. checking the data used in a template lines up with what the component should be passing to that template. Without typescript one should probably verify this via unit tests. With TS these tests are superfluous. * Improved documentation. It's a lot easier to understand what the shapes are of data is that is being passed around in the application. It also provides the opportunity to define these in central locations (e.g. in the form of interfaces) which can then have additional documentation added to them. I think the benefits are not so much specific to TS as they are general benefits of using types and a typed ecosystem.
- SCLeo 5y ago
 I have not used Skruv, but from my experience with vanilla js (document.createElement('div')), hyperscript (h('div')), and jsx (<div/>), jsx is hoesntly much easier to write and to read.

tobr 5y ago

What’s weird about it? It’s the most obvious declarative way to build a hierarchy of objects in vanilla JS. It’s easy to read and straightforward to understand; if you want abstractions around it is completely obvious how you would go about building those yourself.

weego 5y ago
recreating html node declaration in JS with janky and verbose syntax for attributes and child nodes is not an answer to a problem anyone has.
- tobr 5y ago
  I guess I shouldn’t reply to flippant drive-by comments, but how the heck can that be considered verbose, and what’s your non-janky suggestion that doesn’t introduce some kind of extra tooling or parsing?
- blacktriangle 5y ago
  The linked code doesn't show the full value of this technique, since its straightforward HTML that's coming out. Now what happens if you want a collection of list items generated by looping over an array? Assign classes based on some logical conditional? Conditional rendering? These are problems everybody has and every template language tries to solve with their own custom syntax. The point of this method is that rather than create some half-assed template language, you just write Javascript code that acts on and generates a data structure that can then be converted into HTML.
pjmlp 5y ago
Web components and tagged strings are the most obvious way.
- tobr 5y ago
  Tagged template literals can certainly be nice, but they basically require you to ship a parser to the browser, or introduce a complex build step, or give up the idea of doing vdom-like patched updates. (Not sure I see how web components fit into this discussion.)

scoopertrooper 5y ago

OP was trying to keep their framework small and avoid a build step, both of which (especially the latter) would preclude the use of a DSL like JSX. Are you suggesting another approach other than function composition?

deleted 5y ago

[deleted]

azangru 5y ago

I believe this is the original syntax for describing a virtual DOM.

gmac 5y ago

I have no problem with it, except in this variant the empty braces everywhere are a bit annoying (and seem very likely unnecessary).

lhorie 5y ago

There are two major flavors of syntax when it comes to minimalist/no-build JS templating: 1) tree of function calls like this or hyperscript - this is popular because the language syntax enforces markup well-formedness (e.g. you can't express `foo</s>`) and it's easy to implement minimalist engines on top of this API style. Hyperscript in particular is also compatible with JSX. 2) template strings - this is popular because you can actually write angled brackets without a build step, but it tends to come at a cost of less syntactical safety (e.g. `foo</s>` may or may not explode early enough in the dev cycle) and some might argue the semantics of various syntactical permutations are less clear and/or more complex to implement (e.g. what are these supposed to do? `<${a}>`, `<a ${[b, c, d]} />`, `<a ${'b=c'} />`, `a<b, c>d`, etc)

spankalee 5y ago
For template strings you can have a compiler or IDE plugin check the templates. For lit-html we have lit-analyzer, ts-lit-plugin, and lit-plugin (VS code) that do both general HTML linting and lit-html specific type-checking and syntax highlighting.
- lhorie 5y ago
  Sure, when you have compilers and third-party static analysis tools, the palette of what is feasible broadens significantly. I was speaking strictly about no-build-step frameworks.