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 > >
