Vue.js logo

HTML Panel Tips #20: Javascript Frameworks

Davide Barranca —  — 3 Comments

Javascript definitely has a problem: too many frameworks! But as my Color Correction maestro Dan Margulis would put it: “the opposite problem might be much worse”. I’ve tackled the issue of JS frameworks in a dedicated chapter of my Photoshop HTML Panels Development course, but I’d like to add some new thoughts here as well.

This is an atypical Tip: the topic needs more than a quick coverage so bear with me and read along. Also, note that I’m not, strictly speaking, a front-end JS expert: I know how to put together some stuff, but I’m not really into Webpack, Babel, EcmaScript 2015, etc. so I’ve a pragmatic approach.

Coming from Flash Panels and the Olav Kvern school of blogposts, I’ve been using MVC patterns in ActionScript; like many others, I’ve found myself stuck in a dead end when wind changed and turned to HTML. As Matthias Petter Johansson predicts in an entertaining video appropriately called Too many tools and frameworks I chose my framework based on the combination of Popularity (how much it is widespread and adopted) and Authority (who’s build it) – you can’t fail this way, can you? So I went with Google AngularJS.

AngularJS

Being a self-taught JS developer, the framework learning curve was quite steep: so I bought courses, books etc. and started climbing mount Angular. I’ve used it in some of my commercial products and, as I’ve mentioned, I’ve also built a dedicated demo panel in AngularJS for my Photoshop HTML Panels Development course. Per se, that Panel is not rocket science: it scans your PS open document and seeks for Text layers, retrieving the text content and letting you update it. It features three tabs (just a pretext to use routing) and looks like that:

AngularPanel

Yet I’ve built it in AngularJS trying to use all the best practices I knew: separation of concerns, modularity, you name it. I ended up with a code by all means exaggerated for that little panel, but which architecture can scale and support much more complex and elaborated projects. You can have a look at the dependencies schema used in this image.

schema

If you’re familiar with AngularJS you can understand what’s in there – I won’t get through it in this very post: the full Panel’s code, with detailed explanations, is available for download alongside in a 28 custom made panels bundle with the Panels course – you can borrow it and use it in your own projects if you want.

Now, after having written that chapter, I ended up using the very same architecture in an actual, commercial product: a contract job for a Panel that looks apparently simple (but it’s not 🙂 ) Compared to other jobs I did in the past, this one features a great amount of modularity: possibly it wasn’t totally needed when I build it, but being a contract job I’ve preferred to overdo when coding it, and then ensure hopefully easier updates in the future.

As a compulsive new technologies addicted, I have now to face the advent of AngularJS v2, which scrambles all the rules of v1 and is an entirely different beast. Mind you, I went with Angular from the beginning mostly because I like learning new stuff, and for knowing a framework such as AngularJS might be useful for my career apart from HTML Panels (wishful thinking).

Mind you, I can stay with v1 for a long long time! Stuff evolves so rapidly in JS land that by the time Angular v1 is ultimately unsupported, new players will have hit the field: so basically… why bother now (besides, Adobe isn’t the fastest company in updating SDK). Also, I’m not a full-time developer and another steep learning curve will eat time that (a) I don’t have, and (b) that I can spend more profitably, i.e. writing another book. Angular v2 is better experienced using TypeScript – I can barely stand CoffeeScript as a language to compile to JS, I’m sorry but another strongly typed language is not in my plans.

So… I’ve taken the chance to get accustomed to a valid alternative (at least for HTML Panels) that I’d like to suggest you.

VueJS

Let’s start with downsides: it isn’t as widespread as AngularJS or the other framework that everybody’s excited about (React – which frankly I don’t know, but the article “Your Timeline for Learning React” is enough to make me skip it altogether – if you really think I should get into React instead, please let me know in the comments the reason), nonetheless Vue.js has some respectable 20K stars on Github.

Another concern may be that Vue.js is a personal project: yes, it’s mainly built by Evan You, not an enterprise backed developers team.

If you can live with that… Vue.js has:

  • an amazing community: apparently it’s very popular among Laravel developers
  • very good documentation: IMHO uber-important factor when choosing a framework
  • reactive data binding: rendered templates are always up-to-date
  • components
  • routing

and much more, that I won’t cover here ’cause frankly I can’t understand it yet – I’ve just started approaching the framework… How sad is truth, isn’t it?!

Vue.js implements a MVVM (Model – View – ViewModel) pattern, which is considered a good choice for user interfaces (like… Panels!). One of the most understandable articles on MVVM is by Addy Osmani, and I don’t know why, this doesn’t surprise me. Let’s have a look at a dead simple example:

In this case, the View is the templating in the HTML, the Model is the model object (a regular, plain JS object) and the ViewModel is the Vue instance that binds the View (here the "app" element – think about it as the Vue’s version of Angular ng-app), and binds the Model.

Reactivity means that there’s no need to update the view if/when the model changes – as soon as model is updated, the view will reflect the new value. This leads to two-way data binding, such as:

Here you see v-model (equivalent to Angular ng-model) and the use of a JSON filter with $data. Refactoring the same example with modular ViewModel (usually called just vm) you can see that it’s really the data that drives everything, so if you need two Vue instances – and their parent – to share the same model, just share it by identity:

In the above example, the globalModel var contains reactive data that is used by both vmRadius and vmOpacity. Extending further the idea, each vm can bind model data that is both shared and private, like:

If you need it, you can always use a PubSub pattern with $on, $emit and $broadcast, similarly to Angular. Vue.js also has all the directive that you’re used to in Angular, so v-if, v-show, v-for, v-on, etc.

I haven’t talked about methods (i.e. functions that you define in the vm), but I’m not really writing a Vue tutorial here – the official documentation is remarkably good and there’s also this videoseries (mostly free) by the always great Jeffrey Way – let me just briefly mention components:

Everything I’ve shown here is really basic, there’s so much more to discover in Vue.js! Hopefully I’ve raised to your attention what seems to me a valuable alternative to more known and opinionated frameworks that, in the context of HTML Panels, for some among us are either overkill and/or difficult to master and maintain.


If you’re interested in this topic, please check my Photoshop HTML Panels Development course – a 285 pages PDF bundled with 28 custom made panels and 3 hours of HD videotutorials. Help me spreading the news, it will provide me with resources to write and share more content. Thank you!

Print Friendly
Share

3 responses to HTML Panel Tips #20: Javascript Frameworks

  1. great inputs , me facing issue in choosing either Angularjs2 or Extjs ?

    I was doing on CSSDK AS3 API previously .

    Now am confused in selecting framework for CEP Panels , I have tried with angularjs v1 & Extjs 6 , and was able to do few samples in interacting with Extended Script successfully .

    Again Extension Builder 3 comes in my mind , Angularjs 2 is in my mind, don’t i face trouble with typescript ?…it is still in beta and also heard about two versions of Angularjs Dart/Angular TypeScript java script.

    I believe i have to go with simple JS but in other side other team mates have plans to re-use components of Framework panels for both WEB based application and plugin .

    Any suggestion to fix with one good framework ?

    • Hi Charan,
      I’m really happy to have taken the Vue.js route. Angular 1 had tons of documentation, both original and from third parties (good thing): to my needs it was probably “too much featured” – but I’ve always used the parts that I needed only. If I were a web developer, already dealing with TypeScript, I would probably give Angular 2 a try. Now I tend to keep things simpler – I don’t like to use (nor I know) Babel, WebPack, TypeScript, i.e. technologies that requires extra steps to have things done: my own code isn’t that much fancy to need them, at least so far.
      Extension Builder 3 is, as we’d say in Italy, “dead and buried” so who cares. Vue.js is a very nice fit, and you start to find tuts online too. But definitely if you’re not the only developer, a team decision is needed: I would suggest to just pick the framework you’re already more familiar with – as I wrote, unless you start building stuff you can’t know what the actual needs are.

Trackbacks and Pingbacks:

  1. HTML Panel Tips #20: Javascript Frameworks – AngularJS News - June 10, 2016

    […] the full article, click here. @undavide: “#Adobe #Photoshop HTML Panel Tips #20: Javascript Frameworks, covering both […]

Leave a Reply

Text formatting is available via select .

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url=""> 

*
*