mudgen
commented
4 years ago Hi Leo! Thank you for this feedback!
Webscript is meant to be used with an underlying DOM implementation, like the browser or jsdom etc. For now I removed the server-side mention in the documentation since I haven't tested it on the server side.
I think nooping booleans is a good idea. So I made that change. Thank you.
Yes, I need to deal with SVG better as you mentioned. Do you have any idea or suggestions about how to go about this? Just asking in case you know a good or realistic approach. I am very interested in developer experience.
Yes, I am aware that IE11 doesn't support proxies. I think this is a good thing in disguise because it means that I don't have to worry about the other things that IE 11 does not support which means less need for babel or transpiling which I want to get away from.
It is a good idea about adding a blurb to the docs about what tagged string templates are. I will do that. I'm doing a lot of work to improve the documentation.
Yes, I will add more documentation about the pros and cons. Thank you.
If you have other ideas, suggestions and feedback I am really happy to receive it.
theSherwood
Hi, rather than leaving a huge PM on reddit, I figured I'd leave a code review here.
First, wanted to say the idea of leveraging existing libraries is neat. I like the todo example leveraging solid.js.
I looked a little bit at the readme and it said it supports server-side rendering, but from looking at the code, that didn't seem to be the case. Is there another file or package I missed? Or is one meant to use jsdom? Some clarity there would be helpful.
Re: the code
In addChild I noticed you stringify booleans. You may want to consider nooping them to better support idioms like
error && 'Something went wrong'.I noticed the SVG handling code doesn't appear correct. Namely,
<title>can be an HTML element as well, and SVG has a number of other elements (e.g.<g>) and all of them need to be created using createElementNS, recursively, unless it's the content of a<foreignObject>(I know, it's very convoluted). Also, for attributes, there's also a createAttributeNS API, which is needed for things like xlink.I'm sure you're aware of the trade-off, but proxies don't work in IE11. Consider also that because of their dynamic nature, the API of your library might be difficult to typecheck and/or write typedefs for (for example, in React, you'd have
onClick, in Mithril, it'sonclick)The API for elementBuilders is a bit surprising (returns an object without second arg, but an array otherwise)
Other than those, I'd recommend adding a blurb to your docs about tagged string template (Not everyone knows what they are)
You may also want to think a bit about technical arguments if anyone inevitably asks about pros and cons. As I mentioned on reddit, what hyperscript has going for it is JSX compat. Since your lib is a layer on top of it, then by definition it can't be as fast, so it ideally should make up in other ways (e.g. developer experience). Bear in mind that some arguments are very opinionated - e.g. developer experience :)