# Introducing Blueprint: Build native JUCE interfaces with React.js

**URL:** <https://forum.juce.com/t/introducing-blueprint-build-native-juce-interfaces-with-react-js/34174>\
**Category:** General JUCE discussion\
**Created:** [July 1, 2019, 1:28pm UTC](https://forum.juce.com/t/introducing-blueprint-build-native-juce-interfaces-with-react-js/34174 "2019-07-01T13:28:34Z")\
**Posts on this page:** 1\
**Showing post:** 40

<div class="post-metadata">

**Author:** ![jucemarler](https://avatars.discourse-cdn.com/v4/letter/j/49beb7/32.png) [@jucemarler](https://forum.juce.com/u/jucemarler)\
**Post date:** [May 20, 2020, 1:32pm UTC](https://forum.juce.com/t/introducing-blueprint-build-native-juce-interfaces-with-react-js/34174/40 "2020-05-20T13:32:06Z")

</div>

> [@ncthom](#):
>
> I think we can have both, we just have to be careful about it. For example, the blueprint core module could carry only the standard native views that port easily to web, and we could ship a second “blueprint extras” module which wraps some juce components. For those people who want that, just add the module to your project and render a `<WrappedJuceSlider>` . And for the people who don’t want it, it’s not intrusive in any way. I think this is also generally supported by just how flexible React itself is. For example, let’s say that I’ve added the “blueprint extras” module and I want to use the wrapped juce slider, but I _also_ want portability to web. I could do this:

This.

Yeah that’s exactly how I view it, make these offered components an additional module/repo. I was even going to suggest an `if (window) return <Slider />` approach heh. Some condition to switch the render based on environment.

I’ve already got some juce wrappers up and running @ncthom so feel free to drop me a message about an “extras” module or similar and I can contribute some stuff.

---

_[View the full topic](https://forum.juce.com/t/introducing-blueprint-build-native-juce-interfaces-with-react-js/34174)._