> On Aug 7, 2017, at 2:03 AM, gkk gb <modjkl...@comcast.net> wrote: > > With flash plugin going away, I'll need to port my Flex application to either > Air or FlexJS sometime in the next year or two. I have a couple initial > questions... > > > Q1. My scientific web app is very data centric, with lots of charts. In > particular, I depend heavily on log charts. Does FlexJS support logarithmic > axes? I couldn't find it in the documentation.
Charts are currently not an area where work has been done in FlexJS. I see two options here: 1. If you find JS chart components which do what you want, you can probably use them in your project with a thin wrapper. We did this with a color picker. 2. If you have classic Flex chart components, they can likely be migrated to FlexJS. There are many similar drawing commands. > > Q2. For new projects, could someone help me understand the key advantage(s) > FlexJS has in the market compared to other technologies such as AngularJS, > ExtJS, etc.? For example, if you're quoting a project to a client, what type > of project is in the sweet spot for using FlexJS rather than the status quo > (whatever that is)? The sweet spot for FlexJS is pretty much the same sweet spot that Flash had. If you have a single-page web app and you are familiar with Flex and Flash, I think you would find FlexJS many times more productive than any of the popular JS frameworks out there. Before I started with FlexJS, I did quite a bit of work trying to make Angular work for me. I found it to be a horrible experience. It’s very unintuitive, hard to organize, slow, very easy to cause minification bugs, minification was difficult. etc. React is probably the most popular JS framework today although Vue.js is giving it a run for the money. Both push declarative code like we have with MXML, but my personal opinion is that their approaches are more hacky and error prone. No matter which framework you pick (other than FlexJS), you will be required to deal with deciding what version of JS you write (or TypeScript). Unless you write in vanilla JS, you will need to pick a compiler (i.e. Webpack or Babel). You will need to deal with all the idiosyncrasies of transpiling and minification. You will probably need to find components that fit your needs and get that to work. You’ll need to write HTML and CSS directly in addition to your JS code. The beauty of FlexJS, is that all of that is taken care of you by the compiler. For the most part, you don’t need to know the intricacies (weirdness?) of css. You don’t need to figure out exactly which HTML elements and attributes you need. You don’t need to worry about how to load myriad HTML, CSS and JS files. You don’t need to worry about combining, trimming and minifying all your dependencies. etc. > Q3. What is the goal of FlexJS release 1.0, and when will it likely occur? Is > it expected to be enough to develop a basic, real, app that is > robust/bug-free? We’re working towards 1.0. Exactly which feature warrent being called “1.0” is a matter of discussion. As far as being enough to build a basic real app? It’s there already. I have a number of apps I built using FlexJS. Some are panels for InDesign which are already being used by my clients. Another is a VERY complex web app which will be going into production soon. It’s a bit bleeding edge, but I’m definitely way more productive than I would be in any of the standard JS frameworks. > Q4. Compared to other HTML technologies, will there will a lot of maintenance > of FlexJS code when browsers get updated, for example, that break previous > code, in the same way that JS/HTML development has today? Flex/Flash plug-in > spoiled me in that regard (maintenance free). Now that the shoe will be on > the other foot, so I wonder what to expect in terms of maintenance; will it > be a matter of filing a JIRA bug for example?. We try very hard to abstract away browser inconsistencies. I think it’s pretty good, although there are probably some edge cases. This is a problem inherent in JS development, but FlexJS is likely better than most. Harbs
