We did a bunch of experiments with running React in a web worker. Maybe we should revive them. Because it's React, it ends up being easy and is basically the same setup (serialized events etc) as what React Native does.
Exactly. I think moving everything but React into the web worker is enough. But that itself isn't easy as far as my limited knowledge, you need to have separate script files. Perhaps a webpack plugin that manages that for you?
I was actually wondering why this wouldn't just use React for the view. Then it could leverage all of the work going on with React (server-side rendering, possibly rendering from within a Web Worker, etc.)
I agree 100% about React - I can't help but think that an editor based upon it could really speed up all the DOM manipulation that holds back every webkit-based desktop app.
Re: Web workers, this probably isn't news to you but you can use transferable objects [1] to eliminate the serialization hiccup. Of course, if you're really trying to share objects across threads in real time, rather than transfer data, parse, and fire events, you may have bigger issues.
Ah, thanks. I'm more on sysadmin side for my day job, and didn't even know about this. I'll have to keep it in mind as I've been dabbling with learning a modern web framework and React was a candidate.
There’s only one DOM and one window. And then you start using web workers, service workers, audio weblets, … Or you want to write tests for your code, or you want to use the same code in a backend node service or with react-native.
The app I currently work on is 100% runtime plugin based. React has not been an issue there at all. I haven’t tried using web components, though, so can’t speak to that.
I'm building something with React + Relay + Sangria and it's working out well so far. There's a sample sangria project showing how to use it on akka-http, and if you write a pure web app like this, you could serve the javascript client from somewhere dumb like S3. Plus with this stack you can plug in react-native apps as well once your server is written.
I'm typing on my phone but if this works well, its the most promising web development platform since previous X (is that React?!). You're a genius! Any examples of how you organise your code, testing etc?
React is a JS library, so it needs a JS runtime to execute outside the browser.
It's hypothetically possible to use a JS runtime as a subprocess from another language to use React for plain HTML SSR, but it probably wouldn't work for React's streaming HTML generation (or at least would likely be very difficult to get working).
Thanks for the detailed response. I took a look at a post where react was still used and driven by server-side state using liveview hooks which looked quite interesting.
sounds interesting. not a fan on reacts workflow because i use jade templates w/ backbone that get compiled to html for me and its much less code, but separating javascript and native components into different threads is a great idea.
i believe we should be able to see javascript being used as a responsive language portable across all devices and being used to control native components as a separate layer.
im actually working with a flexbox xml/html wrapper framework for iscroll that i might use to build a responsive app that not only does pc animations but performs alot of nice mobile slider animations that seem to go at 60 fps on modern handhelds, but its up to emerging gapping technologies like cordova and this to make the use of future "responsive ui kits" which i believe should be emerging soon.
reply