Marketing Opportunity: Premier First-Party Reactive / Immutable Programming Support

[JSpraul]

As I continue to share feedback I hope will be helpful, I wanted to explain that the only reason I even circled back to the land of Saltarelle-style C# to JavaScript transpilers was because of this blog post demonstrating what's possible today with Bridge.NET + React + Redux. Honestly, it looks promising but messy because it is missing support from the toolchain.

This is a rapidly moving target except that at this moment as React begins moving away from legacy browsers there is a unique opportunity to provide a solid platform for enterprise developers stuck targeting those browsers. It may be too early to bet on the right horses, but the opportunity here could grow into something similar to what has already been done with the Ext.NET project!

At this point I plan wander off into pure-JSX land with React.NET because Bridge.NET is focused more on the transpiling than the JavaScript libraries/frameworks. This definitely makes sense, but I look forward to a future similar to what WebSharper is pursuing (though they're currently stuck with F#).

I did also want to be sure to mention that I was impressed by the professionalism of the project and especially the willingness to help developers who are hitting edge cases of the technology stack.

[geoffrey.mcgill]

it looks promising but messy because it is missing support from the toolchain.

We'll have to wait until ProductiveRage can respond.

I haven't had much chance to play with the Bridge.React, but it's high on my list. There's a couple projects I'd like to start soon where Bridge.React would be used.

I did also want to be sure to mention that I was impressed by the professionalism of the project and especially the willingness to help developers who are hitting edge cases of the technology stack.

Cool. Thanks for the feedback.

[ProductiveRage]

Hi, author or the "Bridge.NET and React" post here! For my own curiosity, what did you mean by:

it looks promising but messy because it is missing support from the toolchain.

I realise that I've been working with this combination for quite a while now and so it's very possible that I've become a bit blinded (or maybe just forgiving) of any its rough edges, since I'm so close to it. Did you mean specifically the fact that the JSX format is not supported (and so the code to declare components is a little more verbose - or "raw", even)? Or are there other parts of the tooling chain that you think are lacking when writing React with Bridge?

While I'm quite content with writing components in this way, one other avenue of exploration that I think could be quite interesting is to write all of the application logic in C# - using Bridge - and to then write the components in TSX, that way you still get the benefits of static typing (since it uses TypeScript) and the more "markup-esque" format of JSX. Using a Flux-like architecture encourages the separation of nearly all of the logic of the application away from the components, so this approach could feasibly work quite well (you would have a separate project for the C# / Bridge code and a separate project for the TypeScript side).

As a last point, the Facebook post that you linked about legacy browser support - it does say that they are hoping to support IE8 in React 1.0, which doesn't sound like they're killing off support for legacy browsers too soon. (Speaking of 1.0, it seems like the next version of React will jump us out of the 0.x era, though it won't be 1.0.. it will be called 15.0! If you haven't already, see Facebook's New Versioning Scheme post).