I can definitely recommend some sort of build pipeline tailored to the final delivery platform(s). Gulp is a great start, but there are also other options. Having a node based build system is very comfortable - but setting it up can be a great deal of work.

We (at KINOÏT) use the quasar framework, which is a wrapping environment around vue.js that includes ES6 linting and webpack - which enables you to do really rapid UI iteration and write cleaner code.

At the beginning we wanted to do something with plain JS, but as it is more comfortable for user to have single-page app, the need for more advanced things arose.

Another thing you should be aware of, when doing UI for the camera, that the communication should be as light as possible, because of embedded CPU (or to be precise MCU).

Also a lack of people with knowledge of newest technology is a factor.

What would you suggest as base environment to implement the UI? Read lately that Bower was deprecated and yarn should be used, for example.

Before I can really answer that, I would need a really quick 3 sentence explanation of EXACTLY when the users see this interface and on what screens - or even better, a link to the spec page.

Generally speaking: Jquery and php are two complementary types of tech that had their time in the sun, but they have been superseded to a great deal with javascript templating frameworks like angular, react and vue. I won't go into the details, but their existence had a lot to do with the centralised web. Just fyi: Jquery is a relatively large and at times inefficient library that is full of convenience and expects to be able to use a lot of system resources. For comparison:

jQuery 2.1.3 minified: 82.34 KB
Vue 2.4.2 minified: 20.9 KB

Let me know what you need the browser for, and I can give you some suggestions.

The general idea is to use a smartphone (but later also tablet or laptop) to control the camera. Sebastian did some mock-ups of the UI before (current implementation is a bit different) -> https://wiki.apertus.org/index.php/Wifi_Remote

So the UI should be as lightweight as possible. JQuery was chosen by me at the beginning for the prototype, but later i've discovered that HTML5 already has many features of it. Would ditch it and use something different and small for AJAX (REST request) and data-binding (currently JQuery.my).

Gulp was chosen for processing pipeline ot uglify and minify the final output. Uglify will be used, in case it gives any performance advantage.

Ok. I would highly recommend taking a look at vue.js - its templating features are exactly what is needed here - it has your "ajax" and data-bindings. It is also very lightweight.

The typical paradigm is to design your single-page app so that it only pulls the hmtl/js/css resources on load, and then only communicates with the apertus (server) in order to get / post to the api endpoints. That way you also reduce overall load by removing the php thread - which will make the entire surface of the application seem snappier. You can still have different routes, but these are managed by the client.

The only concern that I still have is making sure that the client cannot be hijacked and that the active session cannot be taken over by other webclients once a connection is established. Do you have a defined method or process for user-validation? Maybe there is a way for the AXIOM's display to temporarily show a one-time login code like the ones used in 2FA... That could be used as a lock so that only one controller can be used at a time.

Is there a staging repo (other than the monolithic github repository) that I could take a look at?

And if this seems like a lot to digest, next week I can set aside an afternoon to help you create the tooling and tune the build process in a separate git repo - then you just need to park the submodule in your main repo and you'll be good to go.

One other thing about the designs you linked to, a website in a browser will pretty much always have the OS chrome and Browser chrome at the top. In landscape mode there is a lot of real-estate that goes away. There's probably a way to do that with html5 fullscreen - but that is a part of the spec that browsers / os's have never really gotten right. It will need some testing and tweaking.

Cordova?

Heard of vue.js before, but haven't used it. What PHP thread do you mean? Currently we do not involve PHP at all for that part of the software. There is a C++ daemon and REST server (also a Go version exists, but not maintained currently) which are used to communicate forth and back.

Session management was already on my mind, but we haven't discussed it fully yet. Although we had a talk about restoring settings from local browser storage. AXIOM has no display by default, that's why smartphone control was started.

No other repository is available yet, as the daemon was started in the beta-software repo and just recently Sebastian took on to extend the UI part (previously there was just a basic one to test REST communication).

Cordova is mostly used for accessing information on device, but i don't think that we required it for remote controlling the camera.

cordova would be a build step to make native apps that run within a "webview" container on a mobile device.

restoring settings from the local.storage is a good idea.

now i understand what the php files were doing here:
https://github.com/apertus-open-source-cinema/beta-software/tree/master/software/http

Ah, you want to use it like the R&D at my company. They have also implemented an Android application in that way. But a simple WebView app for Android would be sufficient, in my opinion, maybe with settigns for IP address of the camera. Done that already at work, as we had no requirement for Cordova for customer project.

Edit: Cordova for iPhone would possibly be easier, don't have much experience with iOS.

Edit 2: Now i remember that R&D also used Cordova for iPhone version of the app.

We are using in a framework for vue.js called quasar. With one code base we deliver a single-page website, electron native apps for windows, mac and linux and also use cordova for making android and iOS apps. It may be a bit of overkill for your use-case, but if you plan to deliver for more than just phones, maybe it makes sense to tool up at the beginning. That was our decision - and I can say we do not regret investing some extra time early.

What is your experience with the performance? What about application size?

Looking forward to setup some advanced setup, instead of current more simpler one. But i really like live server at the moment, also playing around with node.js for PCB inspection prototype. Avoided it for years, but it is useful as hell.

The performance for our webapp is excellent - even on mobile. We are using lots of components, routes, icon-fonts, 8 translations and roboto font though. I think for apertus it could be really slim. According to the design mock up you need:

• push button component
• tabs
• 5 routes
• api get / post
• detail view
• maybe a modal
• a scroller feature for shutter speed / iso (which could probably use a repurposed timepicker)

With a clever cache.manifest file the assets would only ever need to be loaded once.

Maybe its a good idea to implement some kind of websocket to allow the server to push information like "SSD 99% full"... just thinking out loud here.

Sounds cool :).
I think we dont need to optimize for speed so caching is not really important (for now).

What PHP thread do you mean?

There was some PHP involved in the axiom alpha web gui. It is going to be replaced by your effords @BAndiT1983 :)

Maybe its a good idea to implement some kind of websocket

I think websockets would be great for our purposes, too. However, building a REST api would be priority for me for now, because we could also poll the data and having a REST Api more universal. Later, we can also build a mapping of the api to websockets.

website in a browser will pretty much always have the OS chrome and Browser chrome at the top

because of this, i think portrait is much nicer (compare https://anuejn.github.io/axiom_touch_mock/). However it is possible to have full screen websites (at least with chrome on android)

Personally I would vote for React + Parcel, because it is easy to get started with (zero config) and quite powerfull. Moreover, i like jsx (but thats a question of taste)

Fetch API or Axios were considered to replace AJAX stuff from JQuery. Some tests done, but not added to the main code.

At the moment i'm playing around with socket.io for PCB inspection, so the webpage gets instant feedback when the images were processed. Maybe there is a possibility to use it without node.js or an alternative. Also something like knockout.js for 2-way data-binding would be nice. Do the frameworks, you guys have mentioned, already provide such stuff? Or should we take this extra libs?

if you are already using node.js for socket.io it is perfect because it is a breeze to bind two-way into vue.js...

AND ... you can get rid of the custom C++ code cruft for simple api responses.

I think there is a misunderstanding. Node.js is used by me for current tests of PCB inspection, if this software will be used, then on a normal server. The camera has an embedded processor, so we won't use Node.js there. Won't ditch C++ also, because of performance, small footprint and rather simple daemon implementation.

Basic infos about it are here: https://wiki.apertus.org/index.php/Control_Deamon

Gotcha.

@sebastian, here is the test archive, cannot send it per mail:

Shall I turn this into a git project with test runner, build instructions and switch out jquery for vue.js?

Try it. JQuery is not a problem to remove, as it was used more for AJAX requests at the beginning. Does vue.js suppport two-way data binding? What about templating feature, by separating chunks into other html files?

Yes, two way is built in and templating is why I suggested it in the first place.

Local storage data binding through vue.js would be great to have a central place. Seen that there is a npm package for that.

i would suggest using vuex to store the "mutations" within the browser - but be careful with the latest NPM - they botched the release and it is chowning system critical folders - essentially bricking the device. It is only a temporary problem though.

Another great thing is the VUE developer tools plugin for chrome and firefox. It's amazing.

NPM is just for the build with gulp or whatever. Device would get slim version of the page, pre-processed by NPM, less, uglified (if performance would be better) and minified.

Using VSCode for most stuff. Has a lot of plugins for many tasks.