Thats quite a collection of nitpicks and I don't think they are all fair;
> There's no state management.
But there is state management via variables in every view. The state management is about decoupling views and data. in case you want a full featured redux like state manager, i don't even see its point.
> There are no tests.
Its an article. adding basic api tests is a trivial task. There are no tests as that wasn't what I wanted to show case.
> There's no performance improvements like memoization or a VDOM.
Using VDOM has no performance improvement unless you need to rerender the entire dom very fast which is where memoization and VDOM are superior. This is a simple event based html/js app. user clicks on something, DOM is rendered. thats it.
why the hell would I want to rerender the DOM every time for no use. This is like saying vanillajs is bad because I didn't write my code in typescript and convert to webassembly to drive web components in my html. I did none of those things because they are not needed...
> Even simple things like managing constants isn't done well (eg you've hardcoded the API address in to the getPost function).
I am not sure what the problem is here... Would it be better if I abstract it to a module where I maintain the map between the api and the function?
> There's no error handling, so if an API call to fetch a post fails nothing will happen except you'll get a JS error in the console to say 'post.id' not found when PostShow tries to expand out the template string.
yep. its a hook. This is a simple article on how things can be achieved. expecation is that when people can show the error message in the console, they can easily consume it in the html as well, if they so desire.
In my other project, where I am using the same error hook, i don't post it to a console but to an notifications div on top of the, page.
> No doubt you could implement all of those things, but by the end of it you'd probably have implemented something very similar to React. It's not unreasonable for people who want those things in their apps to just use React in the first place.
And my argument is that all of us don't really need all those things so why use the full react/vue ecosystem? just a 100 lines of vanillajs would suffice.
Anyway, the point of the article was to show a different way of doing things. i don't expect everyone to agree with it and its fine. each to his own. I personally don't like using frameworks when i can do the same stuff by myself with minimal effort.
> There's no state management.
But there is state management via variables in every view. The state management is about decoupling views and data. in case you want a full featured redux like state manager, i don't even see its point.
> There are no tests.
Its an article. adding basic api tests is a trivial task. There are no tests as that wasn't what I wanted to show case.
> There's no performance improvements like memoization or a VDOM.
Using VDOM has no performance improvement unless you need to rerender the entire dom very fast which is where memoization and VDOM are superior. This is a simple event based html/js app. user clicks on something, DOM is rendered. thats it. why the hell would I want to rerender the DOM every time for no use. This is like saying vanillajs is bad because I didn't write my code in typescript and convert to webassembly to drive web components in my html. I did none of those things because they are not needed...
> Even simple things like managing constants isn't done well (eg you've hardcoded the API address in to the getPost function).
I am not sure what the problem is here... Would it be better if I abstract it to a module where I maintain the map between the api and the function?
> There's no error handling, so if an API call to fetch a post fails nothing will happen except you'll get a JS error in the console to say 'post.id' not found when PostShow tries to expand out the template string.
yep. its a hook. This is a simple article on how things can be achieved. expecation is that when people can show the error message in the console, they can easily consume it in the html as well, if they so desire. In my other project, where I am using the same error hook, i don't post it to a console but to an notifications div on top of the, page.
> No doubt you could implement all of those things, but by the end of it you'd probably have implemented something very similar to React. It's not unreasonable for people who want those things in their apps to just use React in the first place.
And my argument is that all of us don't really need all those things so why use the full react/vue ecosystem? just a 100 lines of vanillajs would suffice.
Anyway, the point of the article was to show a different way of doing things. i don't expect everyone to agree with it and its fine. each to his own. I personally don't like using frameworks when i can do the same stuff by myself with minimal effort.