Its not too big of a deal it's just that since there is no code pruning with a bundler that code will stay there. This is fine if you are making use of sockets in your project but if it is not needed it's just so extra code in production that does nothing.
So the htm parser is not tied to preact in any way. It can be easily used with any had library like react. Performance wise it should be just as performant as a normal jsx implementation that has not been uglified and minified.
Yeah maybe you’ll find a way to re-architect it so the dev code doesn’t get deployed into production. Using a socket.io ping to automatically reload the client app though is quite neat.
I like the general idea of not having compile steps, so I think it’s a worthwhile exploration imo. Thanks for sharing.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Perhaps I’m missing something, but I actually think your client side reload is quite a clever use of socket.io. What makes you not like it?
I also quite like how the Preact version of JSX you use looks just like HTML with js template literals. Are there any downsides to it?
Its not too big of a deal it's just that since there is no code pruning with a bundler that code will stay there. This is fine if you are making use of sockets in your project but if it is not needed it's just so extra code in production that does nothing.
So the htm parser is not tied to preact in any way. It can be easily used with any had library like react. Performance wise it should be just as performant as a normal jsx implementation that has not been uglified and minified.
Yeah maybe you’ll find a way to re-architect it so the dev code doesn’t get deployed into production. Using a socket.io ping to automatically reload the client app though is quite neat.
I like the general idea of not having compile steps, so I think it’s a worthwhile exploration imo. Thanks for sharing.