Re: [Discuss] Pros and Cons of Using Royale to Build Websites

[yishayw <yi...@hotmail.com>]

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://www.leaseweb.com/labs/2013/07/10-very-good-reasons-to-stop-using-javascript/
[2] https://moz.com/blog/javascript-seo
[2]  



--
Sent from: http://apache-flex-development.2333347.n4.nabble.com/

Re: [Discuss] Pros and Cons of Using Royale to Build Websites

[Alex Harui <ah...@adobe.com.INVALID>]

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" <yi...@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

Re: [Discuss] Pros and Cons of Using Royale to Build Websites

[Carlos Rovira <ca...@codeoscopic.com>]

Hi,

when I tried to replicate an MDL web page example (from MDL official
samples). I found I was at maybe 90% to get the same results with our
Royale MDL library, the problems at that time was from CSS processed by
Royale that was not prepared for all uses cases. About the CSS problems,
most of them was complex CSS selectors that was not considerer by Royale
compiler.

There's an MDLBlogExample I committed at that time where you can see the
results. I think to get full HTML/CSS web site layouts mainly CSS bugs
should be removed. Don't know if in this months someone has fixed some of
the issues.



2017-09-26 7:56 GMT+02:00 yishayw <yi...@hotmail.com>:

> 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://www.leaseweb.com/labs/2013/07/10-very-good-reasons-
> to-stop-using-javascript/
> [2] https://moz.com/blog/javascript-seo
> [2]
>
>
>
> --
> Sent from: http://apache-flex-development.2333347.n4.nabble.com/
>



-- 

<http://www.codeoscopic.com>

Carlos Rovira

Director General

M: +34 607 22 60 05

http://www.codeoscopic.com

http://www.avant2.es


Conocenos en 1 minuto! <https://youtu.be/P2IEAYDG5HU>


Este mensaje se dirige exclusivamente a su destinatario y puede contener
información privilegiada o confidencial. Si ha recibido este mensaje por
error, le rogamos que nos lo comunique inmediatamente por esta misma vía y
proceda a su destrucción.

De la vigente Ley Orgánica de Protección de Datos (15/1999), le comunicamos
que sus datos forman parte de un fichero cuyo responsable es CODEOSCOPIC
S.A. La finalidad de dicho tratamiento es facilitar la prestación del
servicio o información solicitados, teniendo usted derecho de acceso,
rectificación, cancelación y oposición de sus datos dirigiéndose a nuestras
oficinas c/ Paseo de la Habana 9-11, 28036, Madrid con la documentación
necesaria.