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.
Chris
Am 18.12.16, 09:44 schrieb "omup...@gmail.com im Auftrag von OmPrakash
Muppirala" <omup...@gmail.com im Auftrag von bigosma...@gmail.com>:
On Sat, Dec 17, 2016 at 11:41 PM, Alex Harui <aha...@adobe.com> wrote:
>
>
> On 12/16/16, 11:28 PM, "omup...@gmail.com on behalf of OmPrakash
> Muppirala" <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:
>
> >On Fri, Dec 16, 2016 at 9:45 PM, Alex Harui <aha...@adobe.com> wrote:
> >
> >>
> >>
> >> On 12/16/16, 7:05 PM, "omup...@gmail.com on behalf of OmPrakash
> >>Muppirala"
> >> <omup...@gmail.com on behalf of bigosma...@gmail.com> wrote:
> >>
> >> >On Dec 16, 2016 3:15 PM, "Alex Harui" <aha...@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
phantom.js)
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.
Thanks,
Om
> Thoughts?
> -Alex
>
>
