flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [FLEXJS] ASDoc App
Date Sun, 18 Dec 2016 13:27:52 GMT
To add my oppinion to this topic:

I too think it’s a great idea to have some cool FlexJS tool to display our documentation.
No doubt about that.

But on the other side I think there are well established standards and there is great benefit
in supporting these too.
Google doesn’t index JS applications, how would Google pick up our documentation? I think
HTML is best for that usecase.
Displaying help in IDEs ususally works by looking for a file with the same name and relative
path as the class being displayed (but replacing the file ending with html). These IDEs will
not be able to display our API documentation without updating the IDE. And for one of our
major IDEs, I deffinitely know that hell will freeze first before they come with an update.

One company that usually tends to say „fu** standards, we’ll just do it differently, because
we can and people will still buy our stuff because we’re so toally awesome“ is deffinitely
Apple and that’s what I hate Apple for. Well at least with the new MBP they finally managed
to push this a little too far. I’m really hoping that the market will take care of them
paying for that ;-)

I’m not suggesting to not do the APP version, I’m talking about having both. And I’m
gonna do the static path. And I deffinitely don’t think this is a „waste of time“. You
(Alex) have stated several times, that you will favour new Features over stability and other
things. That’s a valid way to see things, but I have been working for enterprizses fort
he last ... gee 17 years and I know that they like features, but even more they like stability,
reliability, standards etc. That’s why I’m constantly pulling to get/keep a bit of these
ideas in FlexJS. Without us paying attention to these aspects of software development, FlexJS
will probably only become the new cool tool for code-hipsters, but will never do the jump
into the large enterprizes, which I am hoping on being able to do Flex stuff for in the future.
I want FlexJS to be a serious alternative.


Am 18.12.16, 09:44 schrieb "omuppi1@gmail.com im Auftrag von OmPrakash Muppirala" <omuppi1@gmail.com
im Auftrag von bigosmallm@gmail.com>:

    On Sat, Dec 17, 2016 at 11:41 PM, Alex Harui <aharui@adobe.com> wrote:
    > On 12/16/16, 11:28 PM, "omuppi1@gmail.com on behalf of OmPrakash
    > Muppirala" <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
    > >On Fri, Dec 16, 2016 at 9:45 PM, Alex Harui <aharui@adobe.com> wrote:
    > >
    > >>
    > >>
    > >> On 12/16/16, 7:05 PM, "omuppi1@gmail.com on behalf of OmPrakash
    > >>Muppirala"
    > >> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
    > >>
    > >> >On Dec 16, 2016 3:15 PM, "Alex Harui" <aharui@adobe.com> wrote:
    > >> >
    > >> >Or could our framework dump out the resulting DOM and generate the
    > >>static
    > >> >HTML that way?
    > >> >
    > >> >
    > >> >You are probably the only person who could build and maintain this :-)
    > >> >I would say,  XSLT sounds easier than this.
    > >> >
    > >>
    > >> Maybe I'm not understanding something, but IMO, XSLT is an alternative
    > >>for
    > >> ASDoc, but isn't an alternative for all other FlexJS applications.
    > >
    > >
    > >XSLT is a tool/language to modify the generated AsDoc into HTML.  As I
    > >said
    > >earlier, we could also build the docs as an interactive web app.  One does
    > >not have to necessarily replace another.
    > >
    > Maybe I'm too idealistic, but IMO, since we are project for RIAs, it bugs
    > me every time our web presence displays data without using Flex or FlexJS.
    I think static sites have their place.  As much as I love to build RIAs, I
    feel that there are times when static sites simply work better.  I think
    documentation is one such case.
    >  That's why Peter is trying to build out the team page as a FlexJS app.
    This is a great usecase for a RIA, no doubt.
    > So my line of thinking is: folks have limited time to contribute, so
    > spending that limited resource on static site generation of data is a bit
    > contradictory.
    Don't we already generate HTML from asdocs?  What more do you think we need
    to do on this.  Other than maintenance?  How often did the code for
    building HTML ASDocs for the Flex project change?
    >   We should spend that limited time on making sure that
    > FlexJS apps don't have limitations that make even us choose not to use our
    > own product.
    You lost me there.  The limitation you are talking about is not with
    FlexJS.  Apps built with Angular, React, JQuery, all have the same
    limitation.  I don't anyone is going to not chose FlexJS because of this.
    > >
    > >>   Is the
    > >> only way FlexJS apps can work with search engines going to be to use
    > >> PhantomJS or can we and should make something better?
    > >>
    > >> Thinking about static generation from a FlexJS app, it seems to be there
    > >> are several pieces:
    > >> 1) when is all data loaded and JS run so we can start the dump?
    > >> 2) the dump is a simple DOM tree walk
    > >> 3) how do we save the dump?
    > >>
    > >
    > >I don't understand your proposal.  We have javascript, css and json as
    > >separate entities.  You need to have a (headless) browser running the code
    > >and consuming the json to generate the HTML.  Are you proposing that a DOM
    > >is created without a browser?
    > Sort of.  This is a totally new idea to me, so I haven't spent too much
    > time thinking about it, but last night I had the idea of using AIR.  Maybe
    > we can build an AIR app that loads the output from FlexJS, and basically
    > crawls it, but saves out the DOM tree as HTML.  Of course, I could just be
    > dreaming...
    You described the easy part.  IMO the harder questions are:
    1.  How do we serve the HTML to search engines?
    2.  Do we generate it on someone's local machine and upload to a
    webserver?  Or do we do it as a cron job on some server?
    3.  If it is a cron job, we need to do it on a windows machine (much like
    our Mustella server)  In that case, how often do we generate the HTML
    files?  What about the CPU, bandwidth utilizations?
    4.  Or do we run a parallel server that loads the content on demand (like
    5.  Is our solution going to be turnkey?  i.e. can a user reuse our
    solution to their web application?  Would that mean forcing AIR on them?
    That would be a hard sell, especially since it cannot be run on a
    non-Windows server.
    6.  Very few people use Windows servers to serve web content.  Most of them
    are variations of Linux.  There is no way any AIR app can run reliably on a
    given variation of Linux.
    Thinking more about this problem if anything I would say lets make FlexJS
    work seamlessly with phantom.js as others are already using it.  This makes
    switching frameworks easier.  Just my 2 cents.
    PS: My goal for FlexJS is to make it more acceptable to for the Javascript
    community, not necessarily just catering to the existing Flex community.
    That means that bringing FlexJS to npm, implementing MDL, integration with
    phantom.js, etc.
    JS developers are already looking at Typescript and Coffeescript.
    ActionScript is not too different from all this.  Adding MXML to the mix, I
    think FlexJS is leaps and bounds ahead of existing JS frameworks.
    > Thoughts?
    > -Alex

View raw message