Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It depends how really you use virtual DOM. React's "reconciliate whole world" approach can be excessive, yes.

But, for example in Sciter, vDOM works in [web] component cases that are similar to Svelte:

   class Beers extends Element {
     bottles;
     
     render() {
       return <span .bottles>{this.bottles}</span>
     }

     set value(v) {
       this.componentUpdate({bottles:v})
     }
   }
When you will do

   document.$(".bottles").value = 12;
it will update only what is needed. Pretty much Svelte style but with the convenience of vDOM.


To make it even closer to Svelte, Sciter has native signal() implementation, so

   let bottles = signal(0);

   function Beers() {
       return <span .bottles multiple={bottles.value > 1}>{bottles.value} bottles of beer</span>
   }

   document.body.append(<Beers/>);
That can be updated by simply changing signal:

   bottles.value = 42; // Party time!
Note: this does not require any preprocessors or precompilations.


Let's compare lines of code, because more lines invariably leads to more bugs.

Contents of Beers.svelte:

    <script>
      export let bottles = 99;
    </script>
    
    {#if bottles > 0}
      <span class="bottles"
            on:click={() => --bottles}>
        {bottles} bottles of beer on the wall
      </span>
    {:else}
      <span class="bottles">
        No more bottles of beer on the wall
      </span>
    {/if}
Then to use it:

    <script>
      import Beers from './Beers.svelte';
    </script>

    <Beers />
No knowledge of Reactor's existence needed let alone the library's "signal" function. No functions needed at all. No bespoke syntax for the "bottles" CSS class. No vDOM API call. No extra "values" accessing property. It's >90% plain old HTML, CSS, and JS with literally the bare minimum of syntax to handle data binding.

Yes, it requires a compiler, but I would honestly astounded if you even noticed the compiler build time in dev mode. AND the deployed code is smaller. AND it's simpler for the dev to understand and maintain. AND it's likely faster at runtime.

The argument that Svelte adds mental overhead is manifest nonsense. If you like the vDOM, have at it. Follow your bliss. Some folks like hitting and kicking trees. Some folks prefer their coffee too hot to drink.

I for one want a web framework that makes web development as simple, straightforward, and powerful as possible. HTML, CSS, and the smallest amount of JS and HTML annotation imaginable.


In Sciter you do not need any preprocessor at all, not even JS in your HTML:

    <style>
      div.beer {
        prototype: Beer url(/components/beer.js);
      }
    </style>
    <body>
       <div class="beer" />
    </body>
After that div.beer element will be instanceof Beer. In this case class Beer used as a [Web-alike] component.


1. I think you accidentally a <style> tag

2. Your example would have atrocious load time implications for any non-trivial web page. Iterating the DOM through querySelectorAll to replace items at load time? Yikes!

So apparently with Sciter you can either have minimal code or acceptable performance. Got it. Would rather have my cake and eat it too.


My sample is correct.

CSS prototype property is a Sciter specific extension.

When the engine computes styles it does [if needed] this (pseudocode):

   Object.setPrototypeOf(element, thatClass);
   element.componentDidMount();
on applied elements.

There is no "performance sacrifice" in case of handling prototype properties.

Prototypes are switchable if needed:

  div.beer { prototype: Beer url(...); }
  div.beer:hover { prototype: BeerHovered url(...); }


Oh geez. It's Internet Explorer CSS Behaviors all over again.

"Those who do not learn from the past…"


Close but not exactly, there is no esoteric HTC stuff for example.

   element.selector {
     prototype: ClassName url(in-module.js);
     color: blue;
     ...
   }
That above is significantly better than almost-dead-at-birth WebComponents:

   let customElementRegistry = window.customElements;
   customElementRegistry.define('my-custom-element', MyCustomElement);
One simple CSS property instead of 20+ additional entities https://developer.mozilla.org/en-US/docs/Web/Web_Components

Used quite a lot actually, on half of machines where Sciter is installed (~500..600 mln machines :)


Web Components is a marketing coup. It’s a great name. People wish it existed and did the thing it says. So they ignore that customElement and shadow DOM are two terrible APIs that are best ignored by 99% of developers…

Meanwhile, shit that would actually help framework authors, like native morphDOM don’t happen.


This seems pretty interesting.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: