Harbs has to request the repos and mailing lists, and then Infra will hookup GitPubSub and we'll be able to set up royale.apache.org. And when we do, I suggest that we stick in some static pages just for now. I can do it, but will look ugly if I do, so best if someone else can do it.
But over time, IMO, we want to replace our static pages with dynamic pages and eventually a dynamic single-page "app". Our website is going to be designed to attract, inform and retain visitors, and I think it is well established that proper use of dynamic behavior can help achieve those goals better than a pile of static pages. I think of the difference between a static landing page where the visitor has to scan it looking for information, and a dynamic page that greets you with "How can I help you today?". I think we'd love it if we had a chat center open 24/7 for Royale "evangelism and support". Why can't we build out such a thing on the web? But instead of actual humans answering the visitor, intelligent code is answering instead. If you want to learn a new technology, do you want to read a book about it, or interact with a friendly expert? We do have to solve how Search Engines will find us, although I'm not sure I care about any other search engine other than Google. The nice thing is that SEO for dynamic apps have been a problem for years. This is not a problem that we have to solve by ourselves, instead we can expect that Google and a whole bunch of other folks are also working to solve it. Our part of the work may be as "simple" as making sure our screens render fast enough. The cool thing about Royale is that we have a compiler and that allows us to change the output without requiring the developer to change the source code. We can add stuff to the HTML wrapper, generate site maps, generate a search-friendly DOM and more. The framework can also help. If we have to run the JS in a fixed amount of time, we can alter what JS runs if we know we are being loaded by a headless search engine crawler. For example, we could add code that doesn't load mouse and keyboard beads. We could even skip layout if that makes a difference. The important part is that Google recognizes that dynamic web content is going to be a key part of the modern web and is dedicated to making it searchable. Articles like [1] that discuss the drawbacks of JS-based web sites are interesting, but for me, I don't worry about them too much. There is no perfect, no-trade-off environment. If your concern is performance, I'll bet I can go find an article that says that native code will be faster than the browser will ever be. There are probably articles about how content delivery via Browsers are not as good as providing Apps. Progressive Enhancement can help, but only if the basic content is known and can be enhanced. I expect there will be plenty of folks who will decide to use Browsers and a Framework and a structured language and dynamic content for many years to come. And another group interested in Apps. We just have to show them that we can be a valid choice, not necessarily the perfect choice. I think we can do that. My 2 cents, -Alex On 9/25/17, 10:56 PM, "yishayw" <yishayj...@hotmail.com> wrote: >Olaf Krueger wrote >> That said, I think you just need a couple of static HTML files to get it >> work. >> No complex controls or complex logic needed. >> For this use case I don't see the benefit of using Royale or other >>complex >> frameworks. > >To me it's easier to write in MXML than in HTML, especially if there are >good layouts. If there are recurring sections or pages that can be >abstracted to MXML tags that's an advantage too. > > >>>I found this [1] an interesting read on the >subject >> >> Mhhh.... maybe I got it wrong but it seems to me that a couple of >>points >> could be also true for Royale(JS). (If you basically share the ideas >>that >> are provided within this article) > >I was using [1] to get an intro to the challenges one faces when using a >client side framework to create a website. I'm interested to hear opinions >on whether Royale can meet these challenges. SEO, for example, has been >cited as a major disadvantage of using client side rendering. But reading >[2] it looks like there are ways around that. > >[1] >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.lease >web.com%2Flabs%2F2013%2F07%2F10-very-good-reasons-to-stop-using-javascript >%2F&data=02%7C01%7C%7Cf436fdd3645546bc931f08d504a3506f%7Cfa7b1b5a7b3443879 >4aed2c178decee1%7C0%7C0%7C636420021841903617&sdata=CZICAWNFI09bOpvaArv%2B1 >JRN1Pr%2F2Kp5m2EEkxcIeyQ%3D&reserved=0 >[2] >https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmoz.com%2 >Fblog%2Fjavascript-seo&data=02%7C01%7C%7Cf436fdd3645546bc931f08d504a3506f% >7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636420021841903617&sdata=zCf6 >XGSYguNycu3Hn5wAkLBNiSMnD6jh2TFN%2Br0AELI%3D&reserved=0 >[2] > > > >-- >Sent from: >https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fapache-fle >x-development.2333347.n4.nabble.com%2F&data=02%7C01%7C%7Cf436fdd3645546bc9 >31f08d504a3506f%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C6364200218419 >03617&sdata=WLnPNGJO9FkFTXco992sir4agqZ7XGbXAuj1Ozes5mE%3D&reserved=0
