I think I’d need to hear more about the dependency issues you’re talking about to offer a more exact answer, but to start:
There’s no technical reason that you can’t use material ui. It’s a pretty heavy library, and if your users will ever have iffy connectivity or under-powered devices, I’m not sure it’s a good idea, but there’s no technical blocker as far as I am aware. It’ll just take a bit longer for the project to load.
There’s no question that perspective component authoring is a bit of a dark art due to the mixing of different technologies. So let me break things down a bit and see if it helps. At the end of the day, only a few things are absolute requirements for making a simple perspective component module:
- You create a properly structured ignition module, using the gradle (or maven) plugin
- Your module contains (at minimum) a javascript file that properly implements a React component and a ComponentMeta that get exported to the window
- You register your components with the appropriate
ComponentRegistrys, each registration providing info about the component, and specifying the BrowserResources (e.g. - your js file)
In theory, this could be done 100% without nodejs, webpack, typescript or anything else.
When loading a project in a browser, perspective does little more than evaluate which components are involved in a project, and then build a set of all the BrowserResources that the project needs in order to operate. The perspective runtime loads those resources into the page, and then starts executing the project.
In the example project, we use webpack to bundle our js, but that’s not a requirement. We also use Typescript, as we’re big fans of static types, but that too is more of a suggested practice than a requirement. Ultimately the choice of tooling is up to you. If you use a bundler, you’ll want to make sure you aren’t bundling a bunch of things that are already provided by the page at runtime, including things like react, react-dom, perspective-client, etc, but that’s really the only major caveat (see the excludes in the webpack.config.js).
Dependency wrangling is an annoying pain that is an unavoidable part of working in the front end world. Unfortunately, there’s no quick fix there - front-end dependency management is a mess, and we share many of the same struggles. We’re evaluating things like Yarn’s PlugNPlay system to stabilize dependencies more as the product grows, but there’s really no great answer to offer at this point.
I will say, the version of node you build with doesn’t generally matter (plays no role at runtime - we don’t use nodejs at all in the product), as long as the emitted js is appropriate and runnable in the target browsers.
I do think there’s room to try and build a better system for integrating front end tools with java build processes, and that’s something I’m going to be looking at in the coming months, but I don’t have anything to share right now.
Anyway, not sure if this helps much, but if you have some specific issues, feel free to let us know and we’ll see if we can help you move forward with the project. But in the end, you are just trying to get a js file that can be added to your jar as a resource - how that js file gets built is up to you.