Support import statements

[tve]

Looking at various vue libraries they all show usage with import statements. For example https://github.com/skalinichev/uplot-wrappers has:

<script>
    import Vue from 'vue';
    import uPlot from 'uplot';
    import UplotVue from 'uplot-vue';
    import 'uplot/dist/uPlot.min.css';

    const Chart = Vue.extend({components: {uplotvue: UplotVue}});
 </script>

I don't know whether it's at all possible to support this stuff in uibuilder or whether it's already possible, but it sure would be nice. As it is, one has to install the npm module and then manually track down which files need to be loaded directly from the html. IMHO sorting this out should be higher priority than some of the editor improvements listed on the projects page, but that's just me :-).

[TotallyInformation]

Import statements are not natively supported in JavaScript unless you are using modern components.

They only work if you use a build step.

[tve]

I'm not sure what you mean by "using modern components". I tend to have the latest stable browser versions. They do support import as far as I know. But more stuff needs to line up...

But maybe what I'm asking for is the wrong thing. I think what's I'm bumping against is that the build-less mode is great for small demos but really doesn't scale. Just now, I needed to fix some bugs in vue-svg-gauge that the author evidently is not fixing. Since it's really all contained in a .vue file I naively copied that into my page's src directory. But no, it doesn't work 'cause it's importing TWEEN and lodash get. So now I either have to track down those dependencies or I need to go the other route of forking the repo, packaging my own module so I get a min.js file I can drop in. Painful.

NB: I'm not a regular JS programmer and am trying to avoid having to go through the whole process of figuring out which build system is the best here, how to use it, etc. I've done that in the past but every 2 years it all changes, so very frustrating...

[TotallyInformation]

https://developer.mozilla.org/en-US/docs/Web/Web_Components
https://www.w3.org/TR/NOTE-HTMLComponents#:~:text=HTML%20Components%20provide%20this%20ability,attached%20to%20by%20the%20HTC.

They are the next generation for HTML. Available in most if not all current generation mainstream browsers but not yet widely used. They provide a standards-based way of achieving similar results to things like VueJS components.

You cannot use an import statement in the browser unless you are using web components. You HAVE to run a build step that converts them to something that a browser understands. This is also true when using them with VueJS.

I think what's I'm bumping against is that the build-less mode is great for small demos but really doesn't scale

Well, I think that is debatable. However, using front-end libraries without a build step doesn't scale well, that is true. Even for VueJS which is far and away one of the most versatile of the frameworks.

Just now, I needed to fix some bugs in vue-svg-gauge that the author evidently is not fixing.

Yes, I noticed that there are some failings in that component for sure.

trying to avoid having to go through the whole process of figuring out which build system is the best here, how to use it, etc. I've done that in the past but every 2 years it all changes, so very frustrating...

I sympathise for sure. I am not a regular developer let alone a JavaScript one. JS happens to be the language I chose to use most because I can use it for both the front-end and back-end. It is HORRIBLE in many places. And seems to be going through the classic issue of getting worse and more complex not better. To the point where I'm regularly considering other languages again.

I mainly do programming as a creative outlet. My professional work only occasionally involves programming and that usually in PowerQuery, PowerShell or VBA.

If you need a build step, the most commonly supported one for JS/Vue right now is webpack. Snowpack also seems good though I've not used it in anger yet.

[4b11b4]

@tve Did you ever get beyond the initial examples, setup a build step, and import statements as you like?

[tve]

Yes & no. I ended up using socket.io stand-alone, which ended up being fewer lines of code for me.

[TotallyInformation]

Just a note to say that I've been messing with a build step again - using Snowpack which I find vastly better than other build tools. I've also now worked out how to use the build tools own dev server with uibuilder complete with live reload. Previously I'd only managed to do that with Svelte. I updated the tech docs with this info but only in the vNext branch so if you've time, please have a go with that branch. It is a bit of a pain because you have to change your html urls and add a couple of parameters to the uibuilder.start() function but it certainly works fine. I'll build an example template when I get some time.

I also plan to revisit the Snowpack config because I think that I could arrange the front-end code so that the Snowpack build and dev processes deal with the code differences. I also think there are some ways that Snowpack could be integrated with uibuilder itself such that it provided a dynamic rebuild process within uibuilder.

Just so that you know, Snowpack has a plugin for Vue which gives you an almost configureless build process. Here is an example config file that you would have in the root folder of your front-end code.

// Snowpack Configuration File
// See all supported options: https://www.snowpack.dev/reference/configuration

/** @type {import("snowpack").SnowpackUserConfig } */
module.exports = {
  mount: {
        // Use the ./src folder for source files
        'src': '/'
  },
  // Set extra environment variables for build-time replacement in code
  env: {
    // __SNOWPACK_ENV__.MODE & __SNOWPACK_ENV__.NODE_ENV are both set to process.env.NODE_ENV
    // All other vars HAVE to start with "SNOWPACK_PUBLIC_"
    // Use in code as "__SNOWPACK_ENV__.MODE"
    // or destructured as "const {MODE} = __SNOWPACK_ENV__;"
    // In HMTL, use as "%MODE%"
  }
  plugins: [
    // "@morgul/snowpack-plugin-vue2", // Vue2. https://github.com/Morgul/snowpack-plugin-vue2
    // ["@snowpack/plugin-optimize", { /* options */ }], // Optimise unbundled assets https://www.npmjs.com/package/@snowpack/plugin-optimize
    // ['snowpack-plugin-replace', { /* options */ }],   // Replace Str/regex. https://www.npmjs.com/package/snowpack-plugin-content-replace
    // ['snowpack-plugin-content-replace', { /* options */ }], //Replace strings in output files. https://www.npmjs.com/package/snowpack-plugin-content-replace
    // Plugins for conv to JS or html ...
  ],
  packageOptions: {
    /* ... */
  },
  // Configure the dev server
  devOptions: {
    //openUrl: 'nr' 
  },
  buildOptions: {
    // Use the ./dist folder for build files
    'out': 'dist',
    //watch: true, // Can be used to auto-rebuild the dist folder if not using snowpack dev server
  },
  module: {
    //
  },
};

As you can see, you only really need a couple of lines of configuration, the rest are my comments and reminders.

[ul-gh]

Hi,

+1 for using/supporting ESM module format. This is not an upcoming standard, this is the standard.

Browser support without any build tools seems to be the lesser problem, as it works out-of-the-box on all current browsers:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import?retiredLocale=de#browser_compatibility

However, if you use third-party frameworks or modules, the problem is that not all of those come with a ESM type distributable (or bundled) version that runs in the browser.

For ESM modules to work out-of-the-box in the browser, the imports must use real existing (relative) path names including the ".js" file suffix, that is not the case if you use a build system where the imported dependencies are resolved by the system. That is often forgotten and it is a nuisance at least.

If you design your own components however, I don't see a reason why not to design this from the ground up using ESM modules.

[TotallyInformation]

This is not an upcoming standard, this is the standard.

Well, that is an arguable point at this time. The whole thing is an absolute mess and still very hard to transition complex code from one standard to the other. Without the help of the esbuild tool, I couldn't have done what I have with the new uibuilder client library. Which is to create a core code version and output ESM and IIFE versions from the same code-base.

Browser support without any build tools seems to be the lesser problem, as it works out-of-the-box on all current browsers:

Unfortunately, not everyone is able to use current browsers all the time. This is especially true for IoT where people may be reusing old iPads for interactive displays for example. It was introduced to Safari in 11.1, Firefox didn't support it until v67 in May 2019. So not always as simple as saying that "all" browsers support it.

The real issue with Vue examples on the internet is that they pretty much ALL assume a build step. As you've pointed out, some things are almost certainly needing to be altered to work with native import. In addition, native import does not work the same way as a build step import.

If you design your own components however, I don't see a reason why not to design this from the ground up using ESM modules.

That is one of the reasons behind the new client library versions that have been introduced with uibuilder v5. Using the ESM module version means that you get something a fair bit smaller and simpler. I've also demonstrated that it can be used with a build step or as a native module.

The older uibuilderfe.js library evolved over a long time with contributions from other people to make it compatible with multiple different use modes. However, those were now getting in the way.

Please remember though, that one of the main design philosophies behind uibuilder is that it is and will remain framework neutral. It is not tied to VueJS or any other framework. Indeed with recent advances in HTML and CSS, I've found that you can do a lot of things without any framework at all.

As we've seen with Angular (Dashboard) and Vue (the v2 to v3 debacle), being tied to a single framework always eventually means a very significant amount of rework. With a complex capability such as Dashboard, without the original author, this becomes almost impossible. One of my aims with uibuilder is to continue to improve the code and documentation to get to a point where anyone could maintain it.

I've already used uibuilder with at least 5 different frameworks including some that require build steps and others that do not. I will also continue to create some node-red nodes to enable non-coders to build UI's. My aim there is to eventually be able to reproduce everything that Dashboard can do without code - however, I'm not a fast coder like @tve is ;-). At the same time, there will be multiple options for people who prefer to code and those who prefer to use data and configuration to produce UI's. The configuration-driven version already works pretty well in fact.

---

Anyway, to wrap up, uibuilder has already moved on quite a bit since this discussion started. The new client libraries enable the use of build and native use of static imports, I've built some example HTML native components, the config-driven capability is live, etc.

So I am certainly not ignoring modern web development ideas and tooling.

Great discussion, thanks for your input. Regards, Julian.