4 ms·

> You cannot rerender (and inject/replace) every time the underlying data changes. OK, so how do the frameworks do it then ?

Kiro 4y ago
This is a good start: https://reactjs.org/docs/faq-internals.html https://reactjs.org/docs/faq-internals.html https://reactjs.org/docs/reconciliation.html https://reactjs.org/docs/reconciliation.html
- tgflynn 4y ago
  Thanks.
joshstrange 4y ago
They do pathing/differential rendering. They don't all do it the same way but one example is they build the DOM "in memory", render it out, and then when they re-render they compare they old/new html and inject only the diff. They also have built in things to make sure you don't lose focus when you add an attribute to the input (or change it in some way). There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?
- tgflynn 4y ago
  > There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself? Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date. Thanks for the insights though, I wasn't aware they were doing all of that.
  - nuancebydefault 4y ago
    > I prefer working with my own code... Every programmer prefers to work with their own code. This is the biggest dilemma, it boils down to a lot of "make/buy" decisions. Rule of thumb after 20+ years of experience : do not reinvent frameworks. The framework you are thinking of already exists, and, even when not perfect, solves a lot of problems you hadn't even thought of.
    - spoils19 4y ago
      I disagree vehemently. Every time I reach for a JS framework, my fans spin and I get concerned that my notebook is going to take off to the moon. Writing my own, or better yet, staying away from JS altogether, has resulted in more stable, maintainable and profitable software.
      - phist_mcgee 4y ago
        Then you exist as a very skilled and rare software developer. Or what's more likely is that your lens of software development and software maintenance is quite different to the majority of web developers.
      - nuancebydefault 4y ago
        Think about it, are you the one that maintains said code? If so, can you really call that maintainable (as in, reusable, expandable by others while you are on vacation)? If not, you are a very skilled framework maker. Then other people are using your framework and hence, not reinventing the wheel, which is my point.
  - gremlinsinc 4y ago
    > Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date. The problem here is - if you need to bring in other developers. Finding react/vue devs, or devs w/ htmx, alpinejs, etc - it's going to be super easy to onboard, a custom framework you built yourself - not so much. Maybe it's easy, maybe it isn't but you will have to train new devs who work on your stuff, where otherwise you could save time/money by not having to train on things, plus is your framework well tested using jest or other testing frameworks? There could be lots of bugs that some of the bigger more established frameworks have already worked out, and especially security issues. Right now my favorite stack is laravel + alpinejs + livewire + filamentphp (admin dashboard) -- i can prottype in a week what used to take 3 months.
- naasking 4y ago
  > There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself? You can even avoid a shadow DOM or vDOM entirely and differentially render using the DOM itself: https://github.com/WebReflection/domdiff https://github.com/WebReflection/domdiff https://github.com/WebReflection/uhtml https://github.com/WebReflection/uhtml The JS framework benchmark shows these two are among the top performers.

Kiro 4y ago

This is a good start: https://reactjs.org/docs/faq-internals.html https://reactjs.org/docs/faq-internals.html https://reactjs.org/docs/reconciliation.html https://reactjs.org/docs/reconciliation.html

tgflynn 4y ago
Thanks.

joshstrange 4y ago

They do pathing/differential rendering. They don't all do it the same way but one example is they build the DOM "in memory", render it out, and then when they re-render they compare they old/new html and inject only the diff. They also have built in things to make sure you don't lose focus when you add an attribute to the input (or change it in some way). There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

tgflynn 4y ago
> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself? Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date. Thanks for the insights though, I wasn't aware they were doing all of that.
- nuancebydefault 4y ago
  > I prefer working with my own code... Every programmer prefers to work with their own code. This is the biggest dilemma, it boils down to a lot of "make/buy" decisions. Rule of thumb after 20+ years of experience : do not reinvent frameworks. The framework you are thinking of already exists, and, even when not perfect, solves a lot of problems you hadn't even thought of.
  - spoils19 4y ago
    I disagree vehemently. Every time I reach for a JS framework, my fans spin and I get concerned that my notebook is going to take off to the moon. Writing my own, or better yet, staying away from JS altogether, has resulted in more stable, maintainable and profitable software.
    - phist_mcgee 4y ago
      Then you exist as a very skilled and rare software developer. Or what's more likely is that your lens of software development and software maintenance is quite different to the majority of web developers.
    - nuancebydefault 4y ago
      Think about it, are you the one that maintains said code? If so, can you really call that maintainable (as in, reusable, expandable by others while you are on vacation)? If not, you are a very skilled framework maker. Then other people are using your framework and hence, not reinventing the wheel, which is my point.
- gremlinsinc 4y ago
  > Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date. The problem here is - if you need to bring in other developers. Finding react/vue devs, or devs w/ htmx, alpinejs, etc - it's going to be super easy to onboard, a custom framework you built yourself - not so much. Maybe it's easy, maybe it isn't but you will have to train new devs who work on your stuff, where otherwise you could save time/money by not having to train on things, plus is your framework well tested using jest or other testing frameworks? There could be lots of bugs that some of the bigger more established frameworks have already worked out, and especially security issues. Right now my favorite stack is laravel + alpinejs + livewire + filamentphp (admin dashboard) -- i can prottype in a week what used to take 3 months.
naasking 4y ago
> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself? You can even avoid a shadow DOM or vDOM entirely and differentially render using the DOM itself: https://github.com/WebReflection/domdiff https://github.com/WebReflection/domdiff https://github.com/WebReflection/uhtml https://github.com/WebReflection/uhtml The JS framework benchmark shows these two are among the top performers.