When a Senior Automation Software Engineer meets front-end web technologies

TL;DR:

Automation Software Engineers should stay away from web front-ends :-) But newbies can use this as a light-weight introduction to modern front-end development.

The context

I've worked as a software engineer for more than a decade in the automation field, mostly for machine vision applications. I've strong skills in Algebra, Machine Vision, Matlab, good knowledge of c++ and back-end stuff you can put in an automation software. AKA: When I see a CSS I fly away scared

In recent days some potential customers shown interest in automation applications with web front-ends. They want a web SPA (even if they don't know what a SPA is), so that they can manage their machines with different devices.

Therefore I've started my journey trying to find a good fit for my needs. And it turned out as an assembly journey, where I've tried hard to build my dev env and find the right toolbox for my needs and, most important, my level of skills!

I want it all and I want it now!

So as a Senior Automation Software Engineer my few GUI are developed with classic tools. Nowdays unfortunately on .NET Framework and Windows (I prefer QT and Linux) and my average GUI is named a "Human Machine Interface" and looks like this:

Yeah, thanks: no false humility here. In my 10+ years in front of a pc I've acquired an over-average UX compentence.

Still, I've grown accustomed with Graphical Designers (Visual Studio anyone?), XML/XAML, data bind and ready-to-use widgets. Let alone a proper IDE with an integrated graphical debugger.

So I've started my quest for the same tools in webdev. I just want to design a few panels not the next consumer-grade killer-app... It should be easy!

Did I tell you I'm lazy?

Lazy Step 1: I've not dedicated my time to discover a ton of secret jems. I've started following the wave: the IDE+debugger has to be Visual Studio Code (VSC) with a couple of plugins and with the Chrome debugger or the Firef.. no: with Chrome. Period.

Lazy Step 2: what integrations VSC has and what is documented on their site about front-end frameworks/libs/stuff? Easy:

• Angular
• Vue
• React
• Ember
• Next-cool-thing-with-a-6-months-life-and-yet-available-in-VSC-next

Where's the toolchain?

Really: gimme a toolchain for the fox sake!

Isn't here a javascript toolchain? Hell even c has one (compiler, linker, make, blabla). No wait: you can use node.js for this.

NODEJS? N.O.D.E. JS.? The serverside javascript interpreter froked from Chromium? Whaaaaaaat?

Yes. In these years, while I was trying to let a machine train a damned bunch of neural networks, some smart guys have discovered that they can use javascript to build a javascript toolchain. In the end c compilers are written in c, so what's wrong?

And so your hero started installing node.js. And npm. And upgraded npm. All of the previous frameworks/libs/stuff have the proper toolchain ready to be setup and waiting for you in the npm package registry: no mind crushing courses on webpack, webpick, babel, gomorra, ES2015, ES3048 etc... A linter is in place too and everything is just an npm install away (and a * create application_name away!)

Cool! oh, wait what's this node_modules folder?

Let's start coding!

Now that everything is in place I can happily enjoy my IDE with powerful debugging capabilities and a nice debug/release cycle thanks to the huge scaffolding done by the cli of the case but... the debugger simply ignores my break points. It turned out that while VSC has a ton of debugging capabilities you have to set them into the ./.vscode/launch.js file (path relative to your app folder). Every tool has it's own dedicated page for this topic and after a 30 min. digging on the web I've found the right config for the launch.js file. So I've started to happily code front-ends like I did with backends in the early 2000 :P

Where's the widget set?

OK, so you need to install another set of node modules but all the previous frameworks/libs have a ton of fresh widgets ready to be used... Bootstrap, Material Design based, Bulma... wait Bulma, seriously?! Ah, who cares, I've just installed my new 1TB nvm disk for node module hosting, just install it and shut up!

Now tell me, what was that joke? Ah yes, JQuery is such a heavy lib you rather want to avoid it... err... did you see the weight of a widget set? What? Should I reimplement it from scratch? Seriously? Naaaa....

Where to start?

So I had 3 possibilities here actually: I've dropped Ember.js as the entire ecosystem seems rotating around Vue, React, Angular. Sorry Ember I own you a beer.
Then I've tried to stay as mainstream as possible for my early tests, so I've opted for bootstrap and material design stuff. Sorry Bulma: I'm too scared of Vegeta. In the end I've found myself pocking with 6 combinations of tools:

• vue+bootstrap
• vue+material
• react+bootstrap
• react+material
• angular+bootstrap
• angular+material

And what did I learn?

Well, coming from a backend/automation background I've evaluated the 6 possibilites as a whol: it was like almost using 6 different frameworks because each widget set library added its own logic to the mix.

I've discovered that Angular is by all means the closest thing to server side programming. At least it felt really close to python/c# and the so: async events, decorators, split your widget into 3 different files: html, css, logic.
Angular seemed also the most formal of the three (a lot of docs on concepts and theory) and the most "corporate": fixed release cycles, regular cadence... Still for my small needs it also seemed too big. But -as expected- its material design implementation was great.

React was the most close to pure js to my taste. I've cheated in the intro: I've developed a couple of web apps in the past by using uwsgi+Flask+Python. Bootstrap was used for the style and JQuery was the only helper to build the app. The logic was pure js.
So when I say React felt as close as js as possible I refer to that small experience of mine. React JSX is also the most amazing thing I've tried in the last years: elegant, effective. It seems the best way to get rid of the mutilated logic of templates. I haven't felt so productive with a new tech since the year I discovered Python.
I was ready to fall in love with React but then I stackoverflowed for a number of questions and all of my search paths ended into the same place: React State Management. Really too many things to learn for a simple UI. And also I hate functional programming a lot.

Vue... well I overlooked at vue in the beginning. It seemed like a chinese soup of Angular, React, somethingstrange(TM) and the so. And it is! The greatest mix of stuff ever seen. All that ugly directives in templates, a million ways to say the same thing (:, @, v-on, v-bind, v-ery-strange), it even suggests you must use a state management library which seems a clone of Redux (Vuex? Really?).

(ok the web lacks a good vue.js meme...)

But it also has .vue files where simple html, css and js stay well tight and isolated for each component. You can plug JSX in the mix. It is the most practical solution I've found and in the end of the day I already felt familiar with a number of things read in the docs.

Ok, so?!

So I've choosen Vue as my first entry in the front-end world. Along with Bootstrap (the bootstrap-vue docs are simply amazing). Not because it is superior in something, but because it is the most "forgiving" piece of tech, the easier to work with while making a bit of experience in this new world. A really good entry point for someone used to algebra and machine vision.

OK, who cares?!

Oh. I really don't know... but you have read this all so, Thanks for reading :)
And remember: all meme belongs to their authors.