3 ms·

Fun project and all but we already have good solutions for this written by teams of professionals with huge test cases and lots and lots of real world usage and

by mdhb 2y ago

Fun project and all but we already have good solutions for this written by teams of professionals with huge test cases and lots and lots of real world usage and you’re not going to prompt your way to something remotely of comparable quality as say Lit which already has the same kind of JSX functionality you’re looking for here, I’d even argue it’s better than JSX to be fair.

jeswin 2y ago
1. Lit encourages the use of features which aren't a part of the spec. eg: @customElement('simple-greeting'). TC39 has been discussing decorators for years. It's not available yet on any browser. https://caniuse.com/decorators https://caniuse.com/decorators 2. I was not able to find a way to use JSX with lit. Template strings have so many downsides. vscode support is kludgy, because it's a template string. The idea behind webjsx is that you may not need much in the framework. webjsx is less than 200 lines of code.
- accosine 2y ago
  So much YES, somethin akin to JSX is the missing piece in web components. Lit-html, although impressive in itself feature wise, is painful to use and does not feel ergonomic.
- mdhb 2y ago
  You know that’s just some syntactic sugar for Typescript right? You can just use JavaScript without any of that but it’s certainly not something I would say is “non-standard”. I can’t actually think of a more standards aligned front end library than Lit. Also I have to say none of what you mentioned about JS template literals even remotely matches my experience nor have I ever heard of anyone mention this before I’d love to know more of what you’re referring to here though. How a feature that’s literally built into the JavaScript spec is somehow buggier than JSX is actually kind of confusing to me to be totally honest with you.
  - jeswin 2y ago
    > You know that’s just some syntactic sugar for Typescript right But it's also something JS is standardizing. Previously TypeScript had stuff that broke when JS decided to standardize differently. In fact, it's happened in decorators as well when the spec changed - old TypeScript code which used this syntax will stop working at some point if it hasn't already. > How a feature that’s literally built into the JavaScript spec is somehow buggier than JSX is actually kind of confusing to me The problem is that strings have no type information, unless we parse it into some AST and connect it with the rest of the program. You could do that during dev with extra tooling, but because JSX parsing is built into TypeScript (and hence VSCode) it just works out of the box.

by mdhb 2y ago

jeswin 2y ago

1. Lit encourages the use of features which aren't a part of the spec. eg: @customElement('simple-greeting'). TC39 has been discussing decorators for years. It's not available yet on any browser. https://caniuse.com/decorators https://caniuse.com/decorators 2. I was not able to find a way to use JSX with lit. Template strings have so many downsides. vscode support is kludgy, because it's a template string. The idea behind webjsx is that you may not need much in the framework. webjsx is less than 200 lines of code.

accosine 2y ago
So much YES, somethin akin to JSX is the missing piece in web components. Lit-html, although impressive in itself feature wise, is painful to use and does not feel ergonomic.
mdhb 2y ago
You know that’s just some syntactic sugar for Typescript right? You can just use JavaScript without any of that but it’s certainly not something I would say is “non-standard”. I can’t actually think of a more standards aligned front end library than Lit. Also I have to say none of what you mentioned about JS template literals even remotely matches my experience nor have I ever heard of anyone mention this before I’d love to know more of what you’re referring to here though. How a feature that’s literally built into the JavaScript spec is somehow buggier than JSX is actually kind of confusing to me to be totally honest with you.
- jeswin 2y ago
  > You know that’s just some syntactic sugar for Typescript right But it's also something JS is standardizing. Previously TypeScript had stuff that broke when JS decided to standardize differently. In fact, it's happened in decorators as well when the spec changed - old TypeScript code which used this syntax will stop working at some point if it hasn't already. > How a feature that’s literally built into the JavaScript spec is somehow buggier than JSX is actually kind of confusing to me The problem is that strings have no type information, unless we parse it into some AST and connect it with the rest of the program. You could do that during dev with extra tooling, but because JSX parsing is built into TypeScript (and hence VSCode) it just works out of the box.