currently I have also a general node which works with every web-component, which is great for testing. This just sends every incoming Node-RED (I finally remember writing it correctly :-)) message to the widget and in turn every message from the widget is just send at the output of the node.
I already make use of this, for example, I have two different button types which use the same node.
Just like uibuilder does.
with the difference that the communication is between a specific node instance and a specific web-component instance.
But anyway, I feel like now at least five people are talking here, promoting their own ideas, and in the end will continue on their own stuff.
I just want to make sure that no one feels bad about anything I have written, I think the Node-RED community is maybe the best open-source community I have every participated with. So hopefully no one is offended by the dispute about a dashboard concept. I somehow feel a little bit bad that I have participated in this topic much
Or does anyone see a way how we could share forces here?
I think that the main concern I have is fragmentation.
I don't see a problem with people building tools based on their favourite framework, that's inevitable. As soon as you go beyond the basics, you will want to be using familiar tooling.
But it becomes more of an issue if everyone is building slightly different versions of something very similar and working in slightly different ways.
So what might be a really good idea would be for us to identify and write down some basic design patterns?
My 2 cents. What I have seen so far is that we need components that we can add to a framework that the user can edit. If we can define those widgets in a common way then they could slot into several frameworks (I'm not going to say "write once"... ooops).
So far lit-html - https://lit-html.polymer-project.org/guide - has been mentioned several times by different people so that may be the common thread to pull on. Certainly it seems small enough to not be a burden to add even as an experiment. I've not had a chance to play beyond the "hello world" stage - so if anyone one wanted to help add it to existing dashboard that would be great 
While both @cinhcet and @hobbyquaker are both looking at Polymer I don't think that is a requirement for using lit-html so other frameworks can still play. Or at least I hope so. As lit-html seems fairly close to web-standards rather than being tied to a particular framework (ie is pure javascript and doesn't need "building"), it doesn't prescribe certain tools and narrow the audience too much.
As @andrei-tatar says there would need to be a "standard" set of properties and events - aka the API - and as with all APIs it would evolve - but hopefully we can get some common basics in place.
If anyone wants to actually document some of these as a possible design idea - feel free to use the existing dashboard wiki - https://github.com/node-red/node-red-dashboard/wiki/Thoughts-about-a-dashboard-V-next - Though I'm happy to keep the discussion here.
There's also Svelte (https://svelte.technology/guide) and at least a dozen others... 
Each of them could be easily integrated via a plugin (including the old style angular js one).
We just need a common infrastructure that facilitates all this easily.
This is the key for me. A standard schema for data exchange.
Events needs a little more explanation I think. What do we mean by events here?
Most of the frameworks have specific framework event handling which fall into (as far as I can tell) around 2-3 camps. I think that Vue and REACT have slightly different event processes. Angular, I think might be somewhat different again.
Then we have the HTML events (click, blur, change, etc).
And we have the communications events such as new message received. These may be handled specifically (e.g. uibuilderfe creates a simple event handler for these). Or they might be handled by the framework.
This is definately somewhere that we need to start with a common language/glossary.
In order to make a widget agnostic of where and how it runs (or what's written in), we can use custom web elements with custom properties/events. Pretty much all frameworks can translate their components in custom web elements.
The widget shouldn't care where the msg comes from or how it's sent.
So the widget API would be composed of custom properties/events on custom elements.
Docs:
Indeed. We really want the msg to be wrapped in a simple event handler so that it is easily linked to any framework without any need for complex JavaScript of our own. We also want to expose a simple function to allow a msg to be sent back to Node-RED. We also want it to hide the complexity of both the front-end socket handling and the back-end socket handling. With this as a "core", people could write any component handler as they don't need to worry about the communications side of things.
Beyond the communications, the next thing that would enable a flexible approach would be to define common component types, giving them common names, properties and event names.
Now you would have a single, reusable core and multiple component libraries (using your favourite framework) with common identifiers and data schema's). Making it easy to swap out frameworks or to work on a different framework as needed.
You could even have a standardised set of nodes capable of switching frameworks easily. Simply by dynamically building a list of installed frameworks.
Svelte: "Svelte converts your app into ideal JavaScript at build time , rather than interpreting your application code at run time . This means you don't pay the performance cost of the framework's abstractions, and you don't incur a penalty when your app first loads."
I don't like this personally, it restricts you/forces you to have a build step. While it is true that this can be more efficient at runtime, in many cases, the real-world difference is negligible for small web apps. However, there may be many cases - rapid prototyping for example - where you really don't want the constant overhead of a build step.
This is the advantage of something like VueJS which lets you load a version of the library that includes the compiler and compiles on the fly.
vue-custom-element
Now that is an interesting looking tool and I will try that out. Though I'm not entirely clear what it gives you that the current version of Vue doesn't already do if you include the compiler. But I'll have a look. I like the fact that you can use it not just with Vue but it lets you load other frameworks components too. I also like the polyfill for greater browser support.
The lazy loading function may be useful.
You don't actually need a build step. You can ship over npm an already built widget. You can also load the svelte compiler in the browser of course. Either way, the idea is that you can do it any way you want and the dashboard won't care... Even write your pure vanillajs web components. 
Lazy loading I would say it's mandatory. A widget's code (either compiled or not) shouldn't be loaded until it's actually used (especially if it's runtime compiled). Same for the data for that widget. No data/events should flow for that widget until it's in view. I currently hate this on the current dashboard: I have a tab with somewhere around 6 charts and it takes good seconds to load the tab even if the charts aren't in view and I don't even scroll down to them. 
I was also thinking the editor integrated in the dashboard should be a complete, separate lazy bundle since you don't edit the dashboard that often.
The dashboard backend should also employ some good caching policies and strategies.
This all should result in a very fast and snappy app
OK, useful to know. I've not come across that library before. But of course I understand you can ship pre-built components, I was more thinking about the component dev stage. As you can also ship the compiler to the browser then that is the same as Vue and most of the other frameworks (Riot, Moon, etc.). Thanks for the information on this, very useful.
Indeed and if that is enabled by vue-custom-element without ES6/Webpack build then that would certainly be valuable. You can do the lazy loading code by hand of course but who wants to mess with that!
In my view, builds should always be optional.
Incidentally, and apologies to keep coming back to uibuilder - but npm installs and build stages are next on the list for uibuilder. To maintain maximum flexibility, uibuilder will look for a package.json in the folder structure containing your front-end files then look for a build script in that and execute it via npm. I will be extending the editor to allow editing of both the package.json and build configuration files in addition to the src files. This will allow the maximum flexibility, enable webpack/babel/etc but without forcing you down a specific set of tools. But I digress.
Agree. But I would point out that this won't, I don't think, necessarily be fixed by lazy loading or build steps. Some of this is the sheer size and complexity of Angular. On a mobile browser and even desktops, Angular often isn't that performant in my (limited) experience.
And of course, lazy loading, especially with charts and their need for historic data, can take itself an appreciable amount of time and may add complexity in trying to get the full dataset.
The efficiency and size of the admin ui is certainly something that probably needs keeping an eye on at least and I'm sure Nick and Dave and others are doing so. It would certainly be nice to keep it trim.
Indeed. We are all looking for this.
Sorry to hog the conversation - but I just came across this site which seems of interest to those of us looking at trying to ensure whatever we build will make use of emerging standards:
Svelt, Vue, Angular all come out 100%. REACT and Polymer don't quite.
Not sure how good the measures are though - perhaps those more experienced are able to comment.
CSS from the start would be super awesome for me. I see that it "...should be easy", and I agree. I'd like to mixin some CSS defined outside of individual projects so when switching between projects (often with similarly named subflows and functions) I don't need to inspect too closely.
I'm already a fan of changing the header per project dashboard, but even that can be done with CSS these days. SASS or CSS3 variables (https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_custom_properties) would be great!
I also want to support Regex searches on the left nav.
But, if I were a project owner and wanted immediate impact I would say the CSS control/ability to install themes would be great. I'd vote we apply that to the existing, learn any lessons, apply those to any rewrite.
Is anybody already looking at the CSS/theme thing?
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarksā¢ or registeredĀ® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy