3 ms·
I'm really not sure about the "problems" with React being described. Minified at 124k. Sure, but with gzip that's absolutely negligible. Unless your app utterl
by antihero 12y ago
I'm really not sure about the "problems" with React being described.
Minified at 124k. Sure, but with gzip that's absolutely negligible. Unless your app utterly tiny, 124K is nothing (the version of React with addons is 38K gzipped/minified).
I'm not sure what they're going on about with React's dirty checking - all of that stuff is override-able, and things like batching are just a sane way of doing DOM updates.
The verbosity, I'm not seeing it - sure there's JSX, but you mitigate this by abstracting components so you're building out of high-level components that mean that the complexity is only shown where it needs to be.
JSX is also far nicer and more explicit than using HTML templates, and brings a lot to the table, especially with 0.12, including ES6-style patterns that work really nicely for describing a structure of components.
Also, not sure about the "boilerplate". What are they talking about?
React.createComponent({ render(){ return <span/>; });
No boilerplate there.
There's not even that much to remember, aside from the component lifecycle, some handy utilities, and a few useful addons.
There are some more complicated but optional things like PropTypes (not necessary at all, but a nice way to provide type requirements for your component's properties) and contexts (which is at current undocumented and a bit weird, but that's not really an official feature).
Unless you are building apps that are utterly tiny, none of this makes sense.
Looking at Riot2, it looks very implicit and magical - how do we know where the HTML ends and the script starts? How do you break your logic apart and have any sort of code re-use?
And for a "non-framework" it certainly seems to deviate from HTML + JS quite a bit.
- Touche 12y ago> Minified at 124k. Sure, but with gzip that's absolutely negligible. Unless your app utterly tiny, 124K is nothing. Well React is just a view engine so you have to combine it with something else, usually a flux implementation. Then if you want to make things even easier you throw in ImmutableJS which is not small either. Or you might just use Omniscient which wraps this all up into a nice package. But by this point you're close to 400k pre-gzip. That's gigantic compared to the competition. IIRC MercuryJS (which has a VDOM and Immutable data structures) is like 40k. Mithril (which is an MVC VDOM library) is 15k.
- tipiirai 12y agoYou clearly love React and it works for you. The article is about the issues we had and how Riot solved them.
- lmartel 12y agoCould you answer a few of the parent's questions, though? We know that the article is about your issues, but we're curious to hear why these seemingly insignificant issues mattered to you.
- marrs 12y agoIt's worth remembering that the company behind Riot are a 3rd party provider delivering components to host websites. These websites already have jquery/angular/whatever in their own payload, and Moot won't be the only resource they are pulling into their page. In that context, you can see why reducing size is given such a priority. I can assure you, tags that don't take such measures can have a catastrophic affect on your site's performance.
- tipiirai 12y agoSure, I can answer. I think 124Kb does matter a lot. It's not just about the download size but several other things as well: 1. Code size. More vulnerable areas for bugs. Bigger stack traces. 2. Execution time. Scripts are not images. They block the page. And you cannot just remove them from the page like you can do with images. 3. On mobile bits and CPU cycles matter significantly more. Boilerplate. Look for the example on this page: https://muut.com/riotjs/compare.html https://muut.com/riotjs/compare.html and you can see that little things add up. I'm going to update the compiler so that HTML ends on the last tag and if you want to be explicit you can wrap the logic inside a script tag.