6 ms·

What is this "higher abstraction level"? The frameworks are trying to solve components, and they're doing it by introducing a needlessly complex API. All you ne

What is this "higher abstraction level"? The frameworks are trying to solve components, and they're doing it by introducing a needlessly complex API. All you need is a template library like Handlebars and you're mostly set. For an SPA, a routing library like PageJS (https://visionmedia.github.io/page.js/ https://visionmedia.github.io/page.js/) should have you covered. If you prefer server-side rendering over SPA, just use jQuery-Pjax to get all the speed advantages of an SPA and all the SEO advantages of server-side rendering.

shaki-dora 10y ago
I think "just a template library" would re-render the complete DOM for every update, or require you to manually wire up all components. The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude.
- platz 10y ago
  I am genuinely curious what percentage of web apps are demonstrably affected by "slow DOM updates" of several orders of magnitude. You realize React solves a performance problem that it imposes on itself, due to immutability, right? Pre-react web apps to do attempt to re-render the entire page root on every press of a key. They simply handle events and remove/add/update the specific DOM nodes that are appropriate. remember appendChild() and removeChild() ? These are quite fast.
  - bigmanwalter 10y ago
    I am in total agreement with you. I am rarely updating more than a handful of DOM nodes in a pass. I don't need a diffing algorithm to tell me which ones are gonna change.
  - tracker1 10y ago
    Usually I've experienced the performance issues with poor event handling (at the control level) on grid-like views... That said, I like React's component structure... it works with me more than most. Though I tend to dev against react and build against preact-compat for reduced size. Which iirc uses real dom as point of truth. The main take away from React is flux-like state management (ie Redux)... this is what helps with the real pain of larger apps (especially MVC) and that is cross-cutting concerns and state management. This is why Redux has been adopted, or roughly copied to all the up and coming options.
    - platz 10y ago
      O.K., these organizational/structural concerns are fine, but are not what my point is addressing, which was OPs motivation of React on performance grounds. Yes, grids seem to always be a problem. This is one of those 'sticky wickets' (for frameworks too!). Of course it can be solved, but i'm more interested in the general case here.
  - milesrout 10y ago
    The problem with that is then you end up with the same horrible mess of event handlers all mutating global shared state. That's the same problem you have in most C# and Java UI programmes too.
    - platz 10y ago
      not what my point is addressing
      - milesrout 10y ago
        Yes it is. You said: >They simply handle events and remove/add/update the specific DOM nodes that are appropriate. Don't bloody pretend you didn't.
        platz 10y ago
        yes, "They simply handle events and remove/add/update the specific DOM nodes that are appropriate." is intended as a clarification as to why DOM updates in this style are FAST. I am not intending with that statement for it to serve any purposes about code clarity or structure. (Which i think is clear in the context of what I wrote in the same paragraph, and what I am responding to.) I am specifically responding to this: The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude." Of course you can take isolated sentences from me and purport alternate motivations (code clarity) to them so that you can make a new argument against that alternate motivation, but that is a different conversation.
        bigmanwalter 10y ago
        There seems to be a downvote brigade on us React disparagers. Try not to worry too much about. We're releasing faster than them anyway ;)
- bigmanwalter 10y ago
  That's if you use your template library to emulate React. What jQuery brings to the table is that you can sprinkle in a few selectors, event listeners and ajax calls, then you have no need for a shadow dom. The minimal transform is usually trivial to implement by hand: var message = $('.widget__message'), title = $('.widget__title'), button = $('.widget__button'); button.on('click', () => { $.get('/api/widget/1', response => { title.text(response.text); message.text(response.message); }); }); Not only is this technique significantly more flexible than react, there's no magic about it so it's far easier to reason about when things aren't working.

shaki-dora 10y ago

I think "just a template library" would re-render the complete DOM for every update, or require you to manually wire up all components. The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude.

platz 10y ago
I am genuinely curious what percentage of web apps are demonstrably affected by "slow DOM updates" of several orders of magnitude. You realize React solves a performance problem that it imposes on itself, due to immutability, right? Pre-react web apps to do attempt to re-render the entire page root on every press of a key. They simply handle events and remove/add/update the specific DOM nodes that are appropriate. remember appendChild() and removeChild() ? These are quite fast.
- bigmanwalter 10y ago
  I am in total agreement with you. I am rarely updating more than a handful of DOM nodes in a pass. I don't need a diffing algorithm to tell me which ones are gonna change.
- tracker1 10y ago
  Usually I've experienced the performance issues with poor event handling (at the control level) on grid-like views... That said, I like React's component structure... it works with me more than most. Though I tend to dev against react and build against preact-compat for reduced size. Which iirc uses real dom as point of truth. The main take away from React is flux-like state management (ie Redux)... this is what helps with the real pain of larger apps (especially MVC) and that is cross-cutting concerns and state management. This is why Redux has been adopted, or roughly copied to all the up and coming options.
  - platz 10y ago
    O.K., these organizational/structural concerns are fine, but are not what my point is addressing, which was OPs motivation of React on performance grounds. Yes, grids seem to always be a problem. This is one of those 'sticky wickets' (for frameworks too!). Of course it can be solved, but i'm more interested in the general case here.
- milesrout 10y ago
  The problem with that is then you end up with the same horrible mess of event handlers all mutating global shared state. That's the same problem you have in most C# and Java UI programmes too.
  - platz 10y ago
    not what my point is addressing
    - milesrout 10y ago
      Yes it is. You said: >They simply handle events and remove/add/update the specific DOM nodes that are appropriate. Don't bloody pretend you didn't.
      - platz 10y ago
        yes, "They simply handle events and remove/add/update the specific DOM nodes that are appropriate." is intended as a clarification as to why DOM updates in this style are FAST. I am not intending with that statement for it to serve any purposes about code clarity or structure. (Which i think is clear in the context of what I wrote in the same paragraph, and what I am responding to.) I am specifically responding to this: The "shadow DOM" at the root of React is quite central to its appeal, as it speeds up DOM changes by several orders of magnitude." Of course you can take isolated sentences from me and purport alternate motivations (code clarity) to them so that you can make a new argument against that alternate motivation, but that is a different conversation.
        bigmanwalter 10y ago
        There seems to be a downvote brigade on us React disparagers. Try not to worry too much about. We're releasing faster than them anyway ;)
bigmanwalter 10y ago
That's if you use your template library to emulate React. What jQuery brings to the table is that you can sprinkle in a few selectors, event listeners and ajax calls, then you have no need for a shadow dom. The minimal transform is usually trivial to implement by hand: var message = $('.widget__message'), title = $('.widget__title'), button = $('.widget__button'); button.on('click', () => { $.get('/api/widget/1', response => { title.text(response.text); message.text(response.message); }); }); Not only is this technique significantly more flexible than react, there's no magic about it so it's far easier to reason about when things aren't working.