All these languages du jour should go out of their way to answer the question: "why bother?".
10x faster than react. OK cool. Except unless it has something like react native it's irrelevant if you might want to write an app in future with any sort of code reuse since you'll be tied to the web (unless you want the inevitable world-of-pain of trying to integrate this preprocessor into your xcode/android builds...).
These are devs who would rather build tools to build a web app than to build a web app. Different people have different itches. We don't have to consume what they produce. Just have to read about it on HN.
Well and fine, but those tools then need to be maintained forever, and they become yet another tool in the stack for developers who come on board to a company which has adopted them. It's easier and quicker to learn a new library like React, or even a new DSL like JSX, than a new language.
A few months ago I played with ImbaKit (https://github.com/judofyr/ImbaKit) which is essentially React Native iOS implemented on top of Imba. It's just an experiment for now, but there's only time and money which stops this from becoming a proper tool.
Building programming languages just for the heck of it is highly underrated, I think every programmer should at least try implementing a few languages of different paradigms.
Implementing a stack-based language made me write more readable point-free Haskell. Implementing a text-processing-oriented language taught me a ton about Unicode and Korean. Both are fun to work on.
This won't solve the problem of having to learn three different technologies, but whatever might mitigate the pain that we call JavaScript (quirks) is welcome.
People who specialize in webdev learn things by heart so perhaps they forget how bad they are.
The React core team themselves admit that React Native is not about code-reuse, but instead what they call "learn-once-read-everywhere" To require that all javaScript web frameworks compile down to native app code is ridiculous.
It might not be about code reuse, but there will be things that can be ported, just not the DOM stuff (e.g. redux/flux logic, other UI-independent business logic).
I get the whole "because it's fun" reason - just make it clear that that's the motivation, and don't give the impression it's a serious React competitor if it has major shortcomings.
I'm fatigued by the continual "x times faster than React" libraries, as if that really matters. As with all the language/framework debates it comes down to the ecosystem. Raw speed just doesn't cut it for me.
Yes, because everyone who uses React also uses React Native. 100% No one has separate repositories and no one keeps frameworks from crossing platforms in order to preserve some degree of software stability these days.
I hate it when people say, (and I'm paraphrasing) "well there's software for everyone's needs" but there really is. Everyone participates in different communities and ecosystems, and not everyone is riding the latest FluxTypeGoNativeAngular2 rollercoaster.
There are plenty of people who don't even use React because why bother?
And if I use react native, I'll still be tied to Javascript, which is one of the web technologies that people try to get away from when trying to get away from the web.
If I pick anything I'll be tied to something. If I (attempt to) write POSIX only code in straight C - I'll basically be tied to doing only things that can work in that kind of environment.
10x faster than react. OK cool. Except unless it has something like react native it's irrelevant if you might want to write an app in future with any sort of code reuse since you'll be tied to the web (unless you want the inevitable world-of-pain of trying to integrate this preprocessor into your xcode/android builds...).