[erlang-questions] Stuff that breaks when you move it

[Dale Harvey]

it is not premature as it is one of the major bottlenecks when trying to
build fast loading websites, large enough that the yahoo performance team
specifically recommend you make css / js external (except for possibly the
home page)

http://developer.yahoo.com/performance/rules.html


2009/8/4 Joe Armstrong <erlang@REDACTED>

> On Mon, Aug 3, 2009 at 8:20 PM, Dave Pawson<dave.pawson@REDACTED> wrote:
> > 2009/8/3 Joe Armstrong <erlang@REDACTED>:
> >
> >> I consider them broken in the sense that they will not display the same
> >> thing if moved - I'm comparing them with PDF files which do  not break
> >> when moved. Now you can embed js, css and even jpgs into the html
> >> so that they do work if moved but nobody does this.
> >
> > Hopefully.
> > And for good reason Joe.
> > The 'cascade' provides for users to override CSS for such
> > as accessibility reasons.
> >
> > Embedded CSS (and js for that matter) should be history by now.
>
> M'lord I object, the witness is not a historian, the history of HTML
> and why is was a bad idea
> has not yet been written.
>
> Judge: Do you have any other comments? Try to keep them short, we will
> recess in
> twenty minutes.
>
> I will try, M'lord, if the court will permit ...
>
> Judge: get on with it ...
>
> Ladies and Gentelmen of the Jury,
>
> Image I have a a single web page with some js. I *never* intent to
> reuse the js in
> a second page. This is a one-off application.
>
> You are saying that I should store this in *two* pages - not one. This
> will have the
> following consequences:
>
>    - One day I will move one of the files but not the other (I'll
> lose the js, for example)
>    - the two files will live lives of their own and I'll get into
> version nightmares
>    - fetching the file has not got transaction semantics. I might get
> the HTML and then
>      get a link failure before fetching the js. I'd like to "either
> fetch both and it works"
>       or "fetch nothing" - the thing I use (firefox) doesn't have
> transaction semantics.
>
> << suppose the HTML always assumes the js will be downloaded -
>       the HTML prints some static content, then calls the JS - but
> the JS is not loaded
>       the net consequence of this is that some text is displayed and
> this  has disasterous
>       consequnces, somebody dies or something. This is because the JS
> was not executed.
>
>       Learned council can check if this has actually happened >>
>
>    To avoid these things I have to set up a revision control system
> to make sure the parts
> cannot be separated - I have to change web browsers for transaction
> semantics.
> pending this we should ask for a court injunction to stop all browsers.
>
>     My solution is to put the js in the file. With one file all the
> above problems disappear.
>
>      It's a fundamental law of physics - if you have two things in
> two different places
> it's impossible to agree if they are in a consistent state - it's
> mathematically impossible
> (see http://en.wikipedia.org/wiki/Two_Generals'_Problem<http://en.wikipedia.org/wiki/Two_Generals%27_Problem>
> ).
>
>    There are *pragmatic* benefits of including css, js files - but
> this is a premature optimization
> and the net effect of include files can be achieved by a different
> (and sound) mechanism
>
>    I rest my case M' lord.
>
> Cheers
>
> /Joe
>
>
>
> > regards
> >
> >
> >
> >
> >
> >
> > --
> > Dave Pawson
> > XSLT XSL-FO FAQ.
> > Docbook FAQ.
> > http://www.dpawson.co.uk
> >
>
> ________________________________________________________________
> erlang-questions mailing list. See http://www.erlang.org/faq.html
> erlang-questions (at) erlang.org
>
>