5 ms·
So with these virtual DOM libraries, after seeing a lot of them try to fill in this supposed niche, and seeing two this week including this one, I'm of the opin
by yladiz 10y ago
So with these virtual DOM libraries, after seeing a lot of them try to fill in this supposed niche, and seeing two this week including this one, I'm of the opinion that it should either be completely JS looking, e.g. a simple wrapper around createElement, or React looking, e.g. with JSX.
The ones that are in between, while potentially having nice syntax or a nice looking homepage, aren't enough to convince me to use them over React, mainly because 1) if I'm doing any production code, I want other engineers to be familiar with it and its pitfalls; 2) I want to make sure it'll be supported 6 months down the road; 3) engineers are familiar enough with JSX or with createElement, but some other syntax may be confusing and have corner cases that a bigger project like React hasn't thought of... I don't want a lookalike React.createElement because I can just use React.createElement; 4) many of these libraries are built with "performance" in mind, but does it really matter how many more times it can process a ToDoApp if it doesn't really affect user facing performance?
While this isn't a jab at this library specifically (although it hasn't had much substantial development in a while...), but too many libraries are created to fill some supposed niche and then abandoned when they move to different pastures, and if you need to fix any of those corner cases you will inevitably run into, ideally you can submit a PR and get it fixed easily and with little delay.
- hashkb 10y agoI'm interested in tools like this because it allows me to build my front-end out of regular functions, which I can compose however I want using regular code. I never liked writing HTML or CSS in the first place.
- yladiz 10y agoBarring adding a build step, why couldn't you compose a function that returns JSX?
- __derek__ 10y agoOr just skip JSX and use ReactDOM directly.[1] JSX is just sugar for the functions underneath, after all. [1]: https://facebook.github.io/react/docs/top-level-api.html#reactdom https://facebook.github.io/react/docs/top-level-api.html#rea...
- hashkb 10y agoIsn't that a lot like hyperscript? Maybe I like this or mercury or I one of the other varieties better for one reason or another. Is ReactDOM the best fit for everyone?
- deleted 10y ago[deleted]
- __derek__ 10y agoI've never used HyperScript, and I made no claims about anything being the ONE TRUE TOOL. I suggested that yladiz's recommendation would fit your described preferences better without injecting JSX.
- cies 10y ago> I never liked writing HTML or CSS in the first place I also did not like the split between code and markup and or style. > build my front-end out of regular functions, which I can compose however I want using regular code Yes, me too! I want to share what I found. PureScript. Has some nice libs like Thermite (React under the hood) and Halogen (no React, plain PureScript, cleaner). And much more then these two... Elm. Has the batteries included. Nice lib in this language is elm-css, which makes CSS/HTML styling symbols typesafe! GHCJS. The heavy weight. Compiles Haskell to JS (Elm and PureScript merely inspired by Haskell). Coming along quite well, may not be very ready for production. Lots of interesting libraries. Big lib here is Reflex.
- joshontheweb 10y agoDo you have a library outside of React that you would recommend?