re: Why the React community is missing the point about Web Components VIEW POST

TOP OF THREAD FULL DISCUSSION
re: but you can't npm i some useful react component and use it in your non-react app (or if "can't" is the wrong word, "probably won't ever") whereas ...

You can definitely do that if you want to.

For example: npmjs.com/package/web-react-compon...

or if "can't" is the wrong word, "probably won't ever"

That sounds more likely. But is it because it's so difficult? Or because using a declarative library lets component authors come up with more natural and expressive APIs instead of catering to the imperative lowest common denominator? I think it's the latter.

So maybe this means the holy grail of "code reuse between libraries" is not actually so desirable by developers? See my last two sentences. :-)

People like writing expressive code. There's a lot of expressiveness you have to give up in the component API if you're writing it for all consumers — precisely because you can't assume a declarative abstraction on top.

react-google-maps has 34k downloads, and it's a leaf.

I feel like we're trading notes about technical implementation when this discussion was really started about what it means to have the bigger navy.

Benny, you can npm install any react component and use it in any context you like, be it vue or vanilla:

codesandbox.io/s/p56vnm0kv0?module...

All you need is a dom node, the javascript boilerplate is about two lines, mount and unmount, which you can abstract if you like. If you know your way around your toolchain (webpack) you can shrink the overhead down to less than what a web components polyfill would cost you.

or I can

import('https://unpkg.com/@polymer/paper-input/paper-input.js?module').then(() => {
  const pinput = document.createElement('paper-input');
  document.body.appendChild(pinput);
});

without any toolchain whatsoever. I actually just opened a chrome tab to the new tab page and ran that in the console.

Can !== Should

A whole JS library for one component? This is what we're advocating now? I despair. Literal tears.

@benny you have to use a toolchain or a bundler for a real production web app at the end of the day. Even Google (the big force behind WCs) suggests using them: youtu.be/mIWCLOftfRw?t=690

No you don't need a toolchain. That's the whole point. You shouldn't need one. You may add one as an optimization (which is what Google is suggesting there) and I do as well in some of my apps. But you shouldn't need one. You should be able to serve files that you edited yourself directly and they should just work in the browser. That's the web I grew up with and that's the web I want to show to my kids in a few years time.

You can do that just fine with React. There are people who don't like JSX and they write vanilla JS, e.g. github.com/Jador/react-hyperscript....

And again, even adding JSX doesn't mean adding a whole a toolchain. JSX compiler is like a SASS compiler — one command to run a watcher which outputs files to another folder. No complex build systems.

It's irresponsible (to the users!) to ship code to production without a minifier. So you probably already have a build step if you care about your users. Why not put a JSX command before it?

var h = require('react-hyperscript');
var React = require('react');

var AnotherComponent = require('./another-component');

module.exports = React.createClass({
  render: function render() {
    return (
      h('div.example', [
        h('h1#heading', 'This is hyperscript'),
        h('h2', 'creating React.js markup'),
        h(AnotherComponent, {foo: 'bar'}, [
          h('li', [
            h('a', {href: 'http://whatever.com'}, 'One list item')
          ]),
          h('li', 'Another list item')
        ])
      ])
    );
  }
});
import { html, render } from 'https://unpkg.com/lit-html/lit-html.js?module';
import './another-component.js';
const tpl = html`
  <div class="example">
    <h1 id="heading">This is lit-html</h1>
    <h2>Creating HTML Markup</h2>
    <another-component foo="bar">
      <li>
        <a href="http://whatever.com">One List Item</a>
      </li>
      <li>Another List Item</li>
    </another-component>
  </div>
` 
render(tpl, container)

🤷‍♂️

The difference is obvious, isn't it? One is just JS functions. You can refactor them. Lint them. Runs code analysis tools on them. Split them out. Move to a different module.

The other one is a string blob.

It's not HTML though. It's a string blob inside Javascript code. You can wish it away, but the reality remains.

🤷‍♂️

If your problem is tooling then maybe this extension can help. Does it have to say .html on the file extension to be more than a "string blob"? HTML is text after all, it's literally in the name.

That extension doesn't negate the fact that it remains a string blob inside Javascript. Having a string inside a programming language and calling it something else doesn't make it something else.

I wonder how do you feel about writing inside <script> and <style> tags in HTML. In which ways <script> alert("hi") </script> differs from template.innerHTML = "<div> hi </div>"? (Provided that there's tooling support and that the browser knows it has to parse the latter string as HTML not JavaScript.)

I wonder if people actually know what tagged literals are in JS.

Hint:

html`string`

is nothing more than a single function call with, you guessed it, a string

html('string', ...)

No amount of word twisting and wishful thinking can change that. I really advise you to look at what lit-html does such as diligently parsing this string looking for tags and markers: github.com/Polymer/lit-html/blob/m...

And no. the browser does not know how to "parse this string as HTML". Because it's just a string, it's handled as a string, and is used a string, and nothing else.

You all realize that JavaScript is just a string in a file without an engine to parse, compile, and execute it, right?

Im fine with it being string blobs, string parsing is much faster than html parsing.

Well, it's a drop more complicated than that. Tagged template literals know about their static and dynamic parts. And lit-html uses template tags and weakmaps for fast parsing and efficient storage.

code of conduct - report abuse