I'm experimenting a bit with writing a plugin for Octoprint, and I'm wondering about how to handle the Javascript parts in a reasonable way. If this wasn't an Octoprint plugin I would start with Typescript and Webpack (or maybe Create React App directly) for this. But as far as I could see so far, that is quite far from what a typical plugin does.
I looked at a few plugins that looked like they use a bit more JS, and as far as I can tell they generally write the final JS by hand, nothing like Babel or Typescript is involved. I also couldn't find any mention of any typical part of a modern JS environment in this forum.
Has anyone tried to develop an Octoprint plugin that includes a typical modern JS workflow with Webpack and maybe even Typescript? The simplest integration of just taking the JS production build output and copying it is rather limited, so I'd be interested whether anyone has set up something like this properly before?
To the best of my knowledge, OctoPrint packs all the JavaScript and CSS. This is done at installation or perhaps at each startup. Jump into your Developer's Console in your browser and look at what is downloaded. Perhaps foosel or another coder who works on this could clarify.
For what it's worth, your idea of "modern JS workflow" is probably dated from someone else's point-of-view. I'm sure there are people who might complain that it's not using web assembly or something similar. I wouldn't call Typescript bleeding edge but it's not really seen as the majority technology on websites either.
For me, I love NodeJS. Many of my OctoPrint-related projects are built upon this platform.
This is mostly true for the everyday user. There are options in config.yaml that allow you to disable this combining and minifying of the files automatically.
Most of the plugins I have developed have incorporated other external js libraries (ie plotly), but as you mention they are probably not considered "modern day" to any extreme. From my understanding there is development planned to re-vamp the UI infrastructure and the current front runners for that are react and vue. Initial implementation would be using the UIPlugin mixin to allow the old interface and the new interface to live together, allowing for plugin authors to update their stuff.
Speaking of which, if you wanted to totally do your own "modern day" implementation this is where you could look, and completely make your own.
I am fond of NodeJS. I don't love React. I've seen enough Vue to like it but haven't worked with it personally yet. I created a "clean canvas" UI plugin for OCM but my contract was cut (Covid) before anything real came out of that.
I'm not completely convinced that overhauling the JavaScript and UI is needed. The serial-related re-vamp, sure.
Backing up to see the five-year plan, I imagine that hardware will continue to get beefier. A natural outcome of this will be more people expecting multiple printer instances on the same Pi. If I did want to embrace that, I think I would consider the practical aspects of making this easier, say, in two years. I'm not convinced that dockerizing each instance and having them coexist is necessarily the best approach (but I could be wrong).
Ah. What I think we probably need is better sandboxing for each bit of 3rd-party plugin JavaScript. If one is throwing an error, it shouldn't be able to take out the entire collection. For example, one plugin's JS error might prevent another plugin's Settings -> Save button to work. One can disable a single plugin and then restart to see the result (now). It might be nice for this to be a little more dynamic somehow. Or it would be nice to pinpoint the problematic plugin.
Just to clarify, in case there's any confusion. My aim wasn't to replace anything fundamental about the Octoprint frontend. Though that part is certainly also an interesting discussion.
There are a few things that you get from the typical JS development environment you'll find in new web applications right now. One is a proper module system, so you can just import your dependencies and manage them (there also is a certain amount of insanity in the JS ecosystem there, but that's quite far off-topic). The other major benefit is that you can use newer JS features without requiring extremely new browser versions. But in my case one of the primary reasons is that I want to reuse some code I already wrote in Typescript, so I need a compilation step in any case.
As for the discussion about overhauling the UI, I think one interesting benefit could be that in a more client-heavy version the server-side running on the relatively low-powered Pi might have to do less work. But a UI overhaul would be a huge project, and also almost certainly be a hard break for every plugin with a client-side part.