15ms to draw an empty table for a week's schedule, and 40ms during animation seems... excessive?
Vanilla-todo: A case study on viable techniques for vanilla web development
151–154 of 154 posts
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#152Earlier quoted context omitted.
As a consultant who often sees existing systems in enterprise environments, react apps often have dozens of additional packages. And the churn on these packages is significant. React project in the wild seems to exist in two modes from what I can see, the constantly tended garden, or the write and move on and leave it to someone else to rewrite in future (otherwise known as write only, or abbreviated to perl). /s
> react apps often have dozens of additional packages. And the churn on these packages is significant. IMO that's just poor engineering and not an inherent problem with React. The app I inherited at my current job had many such packages. And we have indeed had to update/replace some of them. However most of them were implementing functionality which could be trivially replicated in "plain react" so we've mostly repla…
I agree, for a significant portion of the packages yet not all.
Regardless, the diaspora of packages is just common culture in Javascript in the wild. As a reference, I site leftpad. As a remedy I offer the saying 'its better to laugh than to cry'.. :)
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#153> Naively re-rendering a whole component using .innerHTML should be avoided as this may hurt performance and will likely break important functionality such as input state, focus, text selection etc. which browsers have already been optimizing for decades. I think this statement deserves some serious scrutiny. In many cases the performance hit may not be relevant or noticeable. I know this because I've been very produ…
If your user data isn't sanitized you could run into your site being hacked.
Re: Vanilla-todo: A case study on viable techniques for vanilla web development
#154Another good guide to mvc with js is this one https://github.com/madhadron/mvc_for_the_web The neat thing is that it starts from scratch and adds things, like pub/sub, then models, controllers and so on.
It does start from scratch but it (re-)invents a whole lot of general-purpose code, in effect making up a framework/library, which was an explicit non-goal for the case study (because there are good ones already).
I didn't have time before to go through your case study. But after looking at it for a bit, it doesn't look that much different from the mvc example I linked.
It seems that you are leveraging the built-in event system for observers and using the dom for referencing your components. Personally, I don't feel that mvc for the web is inventing a whole lot more, just patterns and some utilities.
Having events that bubble from the child component up to the app component is an interesting approach. It simplifies the code by not having to pass controllers into views, but makes the child components less reusable in other contexts.
Btw, this structure also reminds me of backbone(1) and that riotjs 1kb blog post from ages ago(2).
I love the effort and thank you for making it.
(1) https://backbonejs.org/#View
(2) https://muut.com/blog/technology/riotjs-the-1kb-mvp-framewor....