[Lift] Re: Lift deal breakers
I agree with Chas but unfortunately it sounds like a lot of work to
change. I would be happy if Lift used JQuery for this but then it
would be tied to a specific library. I wouldn't mind but I can see
why Lift folks would.
On Sep 13, 6:00 pm, Charles F. Munat c...@munat.com wrote:
marius d. wrote:
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
This is not what I had in mind at all. You still have the event handler
in the HTML. The idea, I thought, was to attach the event handler from
an external file using the id (or class) of the button element.
Maybe I'm living on a different planet (a distinct possibility and one
I've been giving much thought to recently), but virtually every JS
programmer I know considers this a best practice, and it has been
considered so for many years.
Frankly, and maybe I'm just a bit dull, but I can't conceive of what the
advantage to the above change might be. What am I missing?
Chas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
On Sep 14, 3:43 am, marius d. marius.dan...@gmail.com wrote:
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;}
...
/script
With this approach you still have an onclick event binded to the dom
element (in this case button) with html and this is bad practice for
javascript development. Additionally you create another function
called liftAjax at the window scope witch is again bad practice!
What I described on my previous post is that good javascript
development practice means that there should be nothing that has to do
with javascript except script tags inside the html. Now If you can to
get as less script tags as possible inside html is also better.
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03 pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two
reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. This means the browser be will forced to make
an addition HTTP request to the server to render each page. This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
This is partially true. If you have a page that can be cached except
some javascript for example it is better to have the javascript as an
external file. If not you could ad the dynamically created javascript
inside the html body but it is still better to load it at the end of
your html document.
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
In my opinion what should be a high priority in this thread is to
strip the javascript of the html elements and bind the javascript
events from within one javascript snippet written at the end of the
html page or as an exernal js file and only if the user wants to.
That is my 2 cents!
Yoryos
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
On Sep 14, 7:35 am, Charles F. Munat c...@munat.com wrote: But we've got a desideratum, anyway. Maybe down the road someone will have time to look at it. Thanks for the clarification! And also enable somebody (myself) take a pause and (re-)learn/ understand many important concepts in the way. Thank you very much everybody! Cheers, Indrajit --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
On Sat, Sep 12, 2009 at 11:48 AM, Charles F. Munat c...@munat.com wrote: I, too, would like to be able to move the liftAjax script call to the bottom of the page. Open a ticket and I'll see what I can do... it shouldn't be too hard Chas. Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
On Sat, Sep 12, 2009 at 7:21 AM, Indrajit Raychaudhuri indraj...@gmail.comwrote: On Sep 12, 7:02 pm, marius d. marius.dan...@gmail.com wrote: On Sep 12, 8:34 am, Indrajit Raychaudhuri indraj...@gmail.com wrote: Even if we assumed that Lift managed to do all the hard work, we still have a contradictory situation: the body/ being completely devoid of scripts but still have 'JS loaded at the end of the page'. It still has to be before the close of body tag and thereby sneaking into the body/. Worse, it's going to be incredibly difficult to implement a rich client interface (Cappuccino, Dojo, Sproutcore etc. - those who want to take complete control over the DOM) without the developer constantly having to prevent Lift and the UI framework not wrestle and step into the each other. A web *application* (like CMS) can get away with that, but not a *framework* (like Lift). What control of Lift over the DOM are you talking about. Lift's generated scripts in HTML is minimal, and it is about Comet mostly. Lift scripts do not really stay in other frameworks way. If you have a concrete example where Lift's stays in the way of integrating other tools please be specific about the problem and we'll see what/if we can do something about it. What is the exact wrestle here? My comment was in addition to your point: If we'd still want this style but be JS library agnostic we'd have to do our own DOM manipulation etc which just adds more overhead without any practical gain. Currently, Lift *doesn't* do any DOM manipulation at all, just generates valid XHTML content and thus *doesn't* stay in the way of integration, which is a healthy thing. And that was my point. Just to underscore this point, I did Cappuccino integration in 1 day (and that included learning Cap, figuring out how to serve the .j and .sj files via Lift with the right mime type, etc.) Cheers, Indrajit And I am given to understand spiders are nowadays smart to recognize dom events handlers (e.g., onclick) and decide what to do when it encounters them. Oh, and while at that, 'view source' a GWT based application and help youself have a perspective :) Cheers, Indrajit On Sep 12, 5:07 pm, marius d. marius.dan...@gmail.com wrote: +1 Andrew. Regarding the rule - absolutely no javascript in the markup doesn't make a lot of sense. Some of the Lift's generated javascript for comet/ ajax calls is put inline at the end of the page. I see no practical reason not to do that. On the other hand putting liftAjax.js on the top of the page is not bad either. IN certain situations users may need this loaded prior their own js code. Besides I really doubt that putting it at the end of the page would really make any practical difference. Not putting lift's JS callas such as Ajax at onclick events like that can become quite lucrative from framework perspective because: 1. Lift would have to queue all these events and add them to a JS sequence and add this js to the served page. 2. that would create a dependency to JQuery events style that would have to be changed when YUI is in place or potentially other framework. If we'd still want this style but be JS library agnostic we'd have to do our own DOM manipulation etc which just adds more overhead without any practical gain. Br's, Marius On Sep 11, 10:18 pm, Andrew Scherpbier and...@scherpbier.org wrote: Dustin Whitney wrote:Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html:buttononclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/buttonThat onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. (I presume here SEO == Search Engine Optimization.) If you are going to use AJAX in your website, you have to use Javascript, right? If you don't want to use AJAX with lift, don't... Just use standard forms and links. (Also turn off client-side garbage collection and any comet stuff in Boot.scala...) So assuming you actually want an ajaxButton, the onclick needs to get in there somehow. The only other way would be to have lift create some javascript that modifies the DOM to somehow add that onclick. I think that would be much harder to read! For the SEO stuff, are you assuming deep traversal (clicking through forms) into your webapp by spiders? I don't know of any spiders that do that very well. Anyway, if that's what you want, then I wouldn't use AJAX for anything. A neat trick to let spiders get to all your public pages if your site has a complex form/ajax based navigation system is to use a site map and make sure all your main URLS are simple, non-form URLs.
[Lift] Re: Lift deal breakers
On Mon, Sep 14, 2009 at 12:51 AM, valotas valo...@gmail.com wrote:
On Sep 14, 3:43 am, marius d. marius.dan...@gmail.com wrote:
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;}
...
/script
With this approach you still have an onclick event binded to the dom
element (in this case button) with html and this is bad practice for
javascript development. Additionally you create another function
called liftAjax at the window scope witch is again bad practice!
What I described on my previous post is that good javascript
development practice
Why? It seems to me, and I'm open to some studies or other descriptions as
to why this is best practice, that designers are dealing with Lift templates
before the JavaScript is inserted, so they don't see the JavaScript and they
don't have to worry about it. How the logic of the JavaScript gets attached
to the rendered page is immaterial except for (1) automated scanners of a
given page or (2) debugging the page. In terms of the first point, yeah,
it's an issue. In terms of the latter, I find it much easier to use Firebug
to attach to a script that I can see rather than some script that's attached
programmatically to the DOM element.
I'm open to understanding a different workflow.
means that there should be nothing that has to do
with javascript except script tags inside the html. Now If you can to
get as less script tags as possible inside html is also better.
Unfortunately, if you've got a dynamically generated HTML page, you can't
have a statically generated Script page. So, you either have (1) a page
that contains HTML with scripts at the bottom or (2) an HTML page that
references a dynamically generated JavaScript file. The latter is a lose
because you've got 2 http requests rather than 1 and the complexity of
remembering what the JavaScript page looks like is non-trivial.
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03 pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two
reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. This means the browser be will forced to make
an addition HTTP request to the server to render each page. This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
This is partially true. If you have a page that can be cached except
some javascript for example it is better to have the javascript as an
external file. If not you could ad the dynamically created javascript
inside the html body but it is still better to load it at the end of
your html document.
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com
wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
[Lift] Re: Lift deal breakers
Nothing in Lift the way it exists today would preclude such a setup. Just as I was able to integrate with Cappuccino (which is all JS-generated view), it's dead simple to integrate with any other non-markup framework. The thing that triggered this thread was Lift's insertion of JavaScript into attributes of tags. I can see an alternative mechanism much like what we do with Lift's comet:when attribute (which is used during the intermediate mark-up but is no longer rendered out to the browser. We could then render clean HTML and attach events in JavaScript rendered at the bottom of the page. More generally, Lift's mechanism for JavaScript support is *not* required. You could build your own mechanism that would generate clean mark-up, render JavaScript at the end of the page which would attach to DOM events. Everybody has access to Lift's GUID - Function binding. You can use it just like it's used in SHtml, but generate your own mark-up. On Sun, Sep 13, 2009 at 6:41 PM, Josh Suereth joshua.suer...@gmail.comwrote: This is how we do JavaScript/ExtJS development at my work place, except with a twist. We actually have a javascript-only project for a our javascript library. We use the maven-javascript-tools plugins to create a javascript project that relies on others (in our case, things like Simile Timeline and ExtJS). We then compile/minify the javascript into an 'artifact' that gets used by our main webapp, where the alchim yui-compressor takes all the CSS/Javascript and bundles as much of it as possible into a single huge JS file. The library project can make use of JSUnit tests (slow-to-run, recommend for integration tests only), and has its own stubbed out controllers and jetty for testing. It's a very interesting setup, but I'm very happy with it. We have very modular JS code, and very very very very very very little JSP/HTML code (we didn't select lift at work). If I were to start using Lift for my backend to ExtJS I would need support for a similar setup (i.e. expect little or no HTML generated outside of the Javascript). Also, the ability to cache dynamically created pages works great for our product in production, however, we're only dynamically creating a javasript file containing very static resources (externalized string library for use when rendering in javascript. This ensures our Javascript and Java externalization works similarly.) I highly recommend the approach if using something like ExtJS, however for lift's templates I'd agree that a page-unique-id would be required for every synthetically created js file so that caching works appropriately. You can also force the browser to check if something's changed. We have a development hack that checks class-load time of the synthetic-js-generator and ensures the cached copy is up-to-date from that time. This means jetty-reloads will reload the class and ensure the next refresh pulls a new version. It's a bit tricky to get set up at first, but worked great! Hopefully this input is helpful! - Josh On Sun, Sep 13, 2009 at 8:48 PM, Charles F. Munat c...@munat.com wrote: I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there. Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each
[Lift] Re: Lift deal breakers
Just wading into the fray here... Looking at people who have responded to this thread, they are mainly people i've not seen on the list before (sorry if your regulars perhaps i should pay more attention!) and that indicates to me that general users dont want *any* js in page (either in the head, the footer, or attributes) and this should be the default, not the exceptional case. Personally, this stuff used to really bother me when doing front end work. Luckily that is hardly ever now, but i see the point being made and would like to add my vote to free-ing the markup of inline JS. Thoughts? Cheers, Tim More generally, Lift's mechanism for JavaScript support is *not* required. You could build your own mechanism that would generate clean mark-up, render JavaScript at the end of the page which would attach to DOM events. Everybody has access to Lift's GUID - Function binding. You can use it just like it's used in SHtml, but generate your own mark-up. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
On Mon, Sep 14, 2009 at 8:20 PM, Timothy Perrett timo...@getintheloop.euwrote: Just wading into the fray here... Looking at people who have responded to this thread, they are mainly people i've not seen on the list before (sorry if your regulars perhaps i should pay more attention!) and that indicates to me that general users dont want *any* js in page (either in the head, the footer, or attributes) and this should be the default, not the exceptional case. Personally, this stuff used to really bother me when doing front end work. Luckily that is hardly ever now, but i see the point being made and would like to add my vote to free-ing the markup of inline JS. Thoughts? I'd agree to this sentiment if it were not for DPPs excellent point that we're talking about the markup Lift spits out, not the markup that lift consumes. I am too fond of graceful degradation, but publishing JS in a separate call would be exotic to code at best. The golden middle road perhaps is, to bake the JS into the bottom of the page. HOWEVER, it is important to know that direct JS callbacks (i.e. onclick=foo()) outperforms _any_ other approach. Cheers, Tim More generally, Lift's mechanism for JavaScript support is *not* required. You could build your own mechanism that would generate clean mark-up, render JavaScript at the end of the page which would attach to DOM events. Everybody has access to Lift's GUID - Function binding. You can use it just like it's used in SHtml, but generate your own mark-up. -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
Done David Pollak wrote: On Sat, Sep 12, 2009 at 11:48 AM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: I, too, would like to be able to move the liftAjax script call to the bottom of the page. Open a ticket and I'll see what I can do... it shouldn't be too hard Chas. Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin -- Lift, the simply functional web framework http://liftweb.net Beginning Scala http://www.apress.com/book/view/1430219890 Follow me: http://twitter.com/dpp Git some: http://github.com/dpp --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
On Mon, Sep 14, 2009 at 9:29 PM, Charles F. Munat c...@munat.com wrote: When you say that direct JS callbacks (i.e. onclick=foo()) outperforms _any_ other approach what is the source for your assertion? And what do you mean by outperforms? What are the criteria? Are you talking about speed? Yes, page load time speed. (since the callback is loaded in relativity to its owner (no lookups needed etc). I did a quick search but the source of my info was nowhere to be found. I did a rather extensive research a year back or so, inline-callback vs. event delegation vs. end-of-page initialization. I guess all depends on what performance you're looking for and how JS heavy your app is. For me, with a _very_ high performance (speed) requirement, it's vital that one doesn't do any un-cacheable, avoidable requests. But as I said, perhaps a good trade-off is to put the JS init at the end of the page. If so, what is the magnitude of the difference? Is it significant? Without this information it is difficult to guess which approach would be better. Is moving the attaching of event handlers to a separate JS file going to significantly slow down my page? Then maybe it's not worth it. But if the difference is negligible, then keeping concerns separate is worth it to me. It's dangerous to say that A outperforms B without understanding exactly what that means. For me, separation of concerns outperforms mixing concerns in terms of development ease, reuse, and graceful degradation. Some of this may not apply to automatically generated code, of course. Chas. Viktor Klang wrote: On Mon, Sep 14, 2009 at 8:20 PM, Timothy Perrett timo...@getintheloop.eu wrote: Just wading into the fray here... Looking at people who have responded to this thread, they are mainly people i've not seen on the list before (sorry if your regulars perhaps i should pay more attention!) and that indicates to me that general users dont want *any* js in page (either in the head, the footer, or attributes) and this should be the default, not the exceptional case. Personally, this stuff used to really bother me when doing front end work. Luckily that is hardly ever now, but i see the point being made and would like to add my vote to free-ing the markup of inline JS. Thoughts? I'd agree to this sentiment if it were not for DPPs excellent point that we're talking about the markup Lift spits out, not the markup that lift consumes. I am too fond of graceful degradation, but publishing JS in a separate call would be exotic to code at best. The golden middle road perhaps is, to bake the JS into the bottom of the page. HOWEVER, it is important to know that direct JS callbacks (i.e. onclick=foo()) outperforms _any_ other approach. Cheers, Tim More generally, Lift's mechanism for JavaScript support is *not* required. You could build your own mechanism that would generate clean mark-up, render JavaScript at the end of the page which would attach to DOM events. Everybody has access to Lift's GUID - Function binding. You can use it just like it's used in SHtml, but generate your own mark-up. -- Viktor Klang Blog: klangism.blogspot.com http://klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com http://liftweb.com AKKA Committer - akkasource.org http://akkasource.org Cassidy - github.com/viktorklang/Cassidy.git http://github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub -- Viktor Klang Blog: klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com AKKA Committer - akkasource.org Cassidy - github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
My sites are low traffic mostly, so a fraction of a second isn't that important to me, but I can see how it might be to you. (Which is not to say that I don't try to minimize hits to the database, combine files, minify, etc., all of which are fractional-second improvements, usually.) I don't use the Lift JSON stuff much, so it doesn't really affect me anyway. If I find anything about actual speed differences, I'll let you know. Chas. Viktor Klang wrote: On Mon, Sep 14, 2009 at 9:29 PM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: When you say that direct JS callbacks (i.e. onclick=foo()) outperforms _any_ other approach what is the source for your assertion? And what do you mean by outperforms? What are the criteria? Are you talking about speed? Yes, page load time speed. (since the callback is loaded in relativity to its owner (no lookups needed etc). I did a quick search but the source of my info was nowhere to be found. I did a rather extensive research a year back or so, inline-callback vs. event delegation vs. end-of-page initialization. I guess all depends on what performance you're looking for and how JS heavy your app is. For me, with a _very_ high performance (speed) requirement, it's vital that one doesn't do any un-cacheable, avoidable requests. But as I said, perhaps a good trade-off is to put the JS init at the end of the page. If so, what is the magnitude of the difference? Is it significant? Without this information it is difficult to guess which approach would be better. Is moving the attaching of event handlers to a separate JS file going to significantly slow down my page? Then maybe it's not worth it. But if the difference is negligible, then keeping concerns separate is worth it to me. It's dangerous to say that A outperforms B without understanding exactly what that means. For me, separation of concerns outperforms mixing concerns in terms of development ease, reuse, and graceful degradation. Some of this may not apply to automatically generated code, of course. Chas. Viktor Klang wrote: On Mon, Sep 14, 2009 at 8:20 PM, Timothy Perrett timo...@getintheloop.eu wrote: Just wading into the fray here... Looking at people who have responded to this thread, they are mainly people i've not seen on the list before (sorry if your regulars perhaps i should pay more attention!) and that indicates to me that general users dont want *any* js in page (either in the head, the footer, or attributes) and this should be the default, not the exceptional case. Personally, this stuff used to really bother me when doing front end work. Luckily that is hardly ever now, but i see the point being made and would like to add my vote to free-ing the markup of inline JS. Thoughts? I'd agree to this sentiment if it were not for DPPs excellent point that we're talking about the markup Lift spits out, not the markup that lift consumes. I am too fond of graceful degradation, but publishing JS in a separate call would be exotic to code at best. The golden middle road perhaps is, to bake the JS into the bottom of the page. HOWEVER, it is important to know that direct JS callbacks (i.e. onclick=foo()) outperforms _any_ other approach. Cheers, Tim More generally, Lift's mechanism for JavaScript support is *not* required. You could build your own mechanism that would generate clean mark-up, render JavaScript at the end of the page which would attach to DOM events. Everybody has access to Lift's GUID - Function binding. You can use it just like it's used in SHtml, but generate your own mark-up. -- Viktor Klang Blog: klangism.blogspot.com http://klangism.blogspot.com http://klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com http://liftweb.com http://liftweb.com AKKA Committer - akkasource.org http://akkasource.org http://akkasource.org Cassidy - github.com/viktorklang/Cassidy.git http://github.com/viktorklang/Cassidy.git http://github.com/viktorklang/Cassidy.git SoftPub founder: http://groups.google.com/group/softpub -- Viktor Klang Blog: klangism.blogspot.com http://klangism.blogspot.com Twttr: viktorklang Lift Committer - liftweb.com http://liftweb.com AKKA Committer - akkasource.org
[Lift] Re: Lift deal breakers
I also think that javascript should go just before the boby's closing
tag. The main reason: Yahoo's YSlow and Google's Page speed both
telling you that is better to have as less scripts as possible and all
of them placed at the end of the page. The optimal would be one
javascript at the end of the page no matter how big it is as it would
be cached by any modern browser and it will be used from the local
cache on other requests from the same domain.
Of course optimal is not always what you can get. Assuming that you
have many javascript files it is also better to have them at the
bottom of the page. You will see a major performance boost because
browsers pause the rendering of the page in order to download
javascript. That is because javascript code could contain a
document.write witch means that it will change the dom of the page and
this is something that the browser will not be able to know in advance
in order to continue the parsing of the page. Moving javascript at the
bottom of the page will not decrease the page loading time BUT will
give the user something to see (the whole page) making him thing that
the page loads faster. Of course the browser will still have to get
the javascript and eval it.
As for unobtrusive, jquery (and the most js frameworks) provides a
solution binding an event on an html element after the page has been
loaded. So instead of having somthing like:
button onclick=liftAjax.lift_ajaxHandler
(quot;F1029758482780OTA=truequot;,
null, null, null); return false;Press me/button
you could have something like:
button id=liftajax_{some_generated_id}Press me/button
and at the end of the page add the javascript:
text type=text/javascript
$(function() {
$(#liftajax_{some_generated_id}).click(function()
{the_lift_ajaxHandler_call_here()})
})
/script
If the ajax handle call is basically the same for most of the elements
you could instead of adding an id, add a class to the the button for
example:
button class=liftajaxPress me/button
and then at the end of the page add:
text type=text/javascript
$(function() {
$(.liftajax).click(function() {the_lift_ajaxHandler_call_here()})
})
/script
I personally use jQuery but the above can be done without the help of
any javascript framework. And to make things much more better you
could have all the handler scripts in a separete dynamicaly created
file and the at the end of the html have something like:
script type=text/javscript src=/path/to/the/dynamicaly/created/js/
with/a/random/id/to/prevent/caching/script
One reason for keeping me away from using lift for a project is this
mess with javascript. I mean, I first want plain html and nothing
else. If I get the html to work for me the I just add the javascript I
want or let the framework add it, but that should be done in an
elegant way in order to be able to switch it off or on or completely
replace it with my own. I don't want any framework to add by default
the javascript for me because it makes things harder to understand and
this is something bad for someone new to it.
I would be glad to help in this matter in any way possible.
Sorry for my English,
it's not my mother language!
Yoryos
On Sep 13, 6:35 am, marius d. marius.dan...@gmail.com wrote:
Technically it could (as I implied above) but this can be lucrative
and IMHO the benefits are simply not that big. I'm not saying that
things are nailed down but I'd love to see a list of practical
benefits for Lift to not add event handlers such as on click to the
elements but rather programatically using synthetic (lift generated)
JS functions that would add events (i.e. JQuery, YUI ways).
Br's,
Marius
On Sep 12, 9:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Maybe adding javascript event handlers could be delegated to something that
depends on which library is being used?
-
Kevin Wrightkev.lee.wri...@googlemail.com wrote:
Moving the script import shouldn't be too difficult, we have the lift:tail
element and tail merge (which acts exactly the same as head merge) for just
this sort of problem.
On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney
dustin.whit...@gmail.comwrote:
One nice thing about jquery's events, if done wisely, is they are applied
after the DOM is loaded. With an onclick a button can be clicked and some
ajax call is fired that returns and tries to modify a part of the DOM that
hasn't been loaded. This is especially true if you have lots of
javascript
includes at the top of the page. I have waded my way through many wonky
javascript bugs like this. They don't happen in your local environment
because they load so quickly, but when pushed to production, problems
ensue. Maybe there is a hook in the lift ajax js that waits to fire the
call until after the DOM is loaded?
-D
On Sat, Sep 12, 2009 at 2:48 PM, Charles F. Munat c...@munat.com wrote:
I, too, would like to be able to move the liftAjax script call to
[Lift] Re: Lift deal breakers
On Sep 13, 11:33 am, valotas valo...@gmail.com wrote:
I also think that javascript should go just before the boby's closing
tag. The main reason: Yahoo's YSlow and Google's Page speed both
telling you that is better to have as less scripts as possible and all
of them placed at the end of the page. The optimal would be one
javascript at the end of the page no matter how big it is as it would
be cached by any modern browser and it will be used from the local
cache on other requests from the same domain.
Of course optimal is not always what you can get. Assuming that you
have many javascript files it is also better to have them at the
bottom of the page. You will see a major performance boost because
browsers pause the rendering of the page in order to download
javascript. That is because javascript code could contain a
document.write witch means that it will change the dom of the page and
this is something that the browser will not be able to know in advance
in order to continue the parsing of the page. Moving javascript at the
bottom of the page will not decrease the page loading time BUT will
give the user something to see (the whole page) making him thing that
the page loads faster. Of course the browser will still have to get
the javascript and eval it.
As for unobtrusive, jquery (and the most js frameworks) provides a
solution binding an event on an html element after the page has been
loaded. So instead of having somthing like:
button onclick=liftAjax.lift_ajaxHandler
(quot;F1029758482780OTA=truequot;,
null, null, null); return false;Press me/button
you could have something like:
button id=liftajax_{some_generated_id}Press me/button
and at the end of the page add the javascript:
text type=text/javascript
$(function() {
$(#liftajax_{some_generated_id}).click(function()
{the_lift_ajaxHandler_call_here()})})
/script
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
If the ajax handle call is basically the same for most of the elements
you could instead of adding an id, add a class to the the button for
example:
button class=liftajaxPress me/button
and then at the end of the page add:
text type=text/javascript
$(function() {
$(.liftajax).click(function() {the_lift_ajaxHandler_call_here()})})
Two reason why I don't prefer this:
1. Lots of selectors could slow things down
2. Other JS frameworks may not have nice selectors as JQuery
/script
I personally use jQuery but the above can be done without the help of
any javascript framework. And to make things much more better you
could have all the handler scripts in a separete dynamicaly created
file and the at the end of the html have something like:
script type=text/javscript src=/path/to/the/dynamicaly/created/js/
with/a/random/id/to/prevent/caching/script
One reason for keeping me away from using lift for a project is this
mess with javascript. I mean, I first want plain html and nothing
else. If I get the html to work for me the I just add the javascript I
want or let the framework add it, but that should be done in an
elegant way in order to be able to switch it off or on or completely
replace it with my own. I don't want any framework to add by default
the javascript for me because it makes things harder to understand and
this is something bad for someone new to it.
I would be glad to help in this matter in any way possible.
Sorry for my English,
it's not my mother language!
I think this is a great post !
Yoryos
On Sep 13, 6:35 am, marius d. marius.dan...@gmail.com wrote:
Technically it could (as I implied above) but this can be lucrative
and IMHO the benefits are simply not that big. I'm not saying that
things are nailed down but I'd love to see a list of practical
benefits for Lift to not add event handlers such as on click to the
elements but rather programatically using synthetic (lift generated)
JS functions that would add events (i.e. JQuery, YUI ways).
Br's,
Marius
On Sep 12, 9:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote:
Maybe adding javascript event handlers could be delegated to something
that depends on which library is being used?
-
Kevin Wrightkev.lee.wri...@googlemail.com wrote:
Moving the script import shouldn't be too difficult, we have the
lift:tail
element and tail merge (which acts exactly the same as head merge) for
just
this sort of problem.
On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney
dustin.whit...@gmail.comwrote:
One nice thing about jquery's events, if done wisely, is they are
applied
after the DOM is loaded. With an onclick a button can be clicked and
some
ajax call is fired that returns and tries to modify a part of the DOM
that
hasn't been loaded. This is especially true if you have lots
[Lift] Re: Lift deal breakers
A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
+1 I would much prefer it if all JS were in external files (synthetic as necessary) and simply attached to the DOM via ids or classes. I have been building my sites this way for years, and I find it the best practice for reasons already put forth in this discussion. Chas. Timothy Perrett wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
If I understand everything correctly, the proposal is to dynamically create a js file for each page request to add event handlers? If this is true, then I'm against the proposal for the following two reasons: 1. Every page will load slower Since the js file is dynamically create on each request, the js file will be un-cacheable. This means the browser be will forced to make an addition HTTP request to the server to render each page. This adds roughly 150ms to the page load time (50ms to 200ms for network lag, 50ms for download, 10ms for js execution). 2. Each page will be more fragile Requiring the synthetic js file will add another point of failure. Even now-a-days with the ubiquity of broadband, connects still get lost and files still get corrupted. It's true that most modern web pages already depend a number of external JS and CSS files, but typically these files are static and easily cached. Just adding my 2 cents. -Xavi On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote: I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
You mean cached by the browser? Isn't that a matter of setting headers, since it won't change in the session--or will it? Can one app switch dynamically from JQuery to YUI? - Xavi Ramirezxavi@gmail.com wrote: If I understand everything correctly, the proposal is to dynamically create a js file for each page request to add event handlers? If this is true, then I'm against the proposal for the following two reasons: 1. Every page will load slower Since the js file is dynamically create on each request, the js file will be un-cacheable. This means the browser be will forced to make an addition HTTP request to the server to render each page. This adds roughly 150ms to the page load time (50ms to 200ms for network lag, 50ms for download, 10ms for js execution). 2. Each page will be more fragile Requiring the synthetic js file will add another point of failure. Even now-a-days with the ubiquity of broadband, connects still get lost and files still get corrupted. It's true that most modern web pages already depend a number of external JS and CSS files, but typically these files are static and easily cached. Just adding my 2 cents. -Xavi On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote: I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59?pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
/script
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03 pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. This means the browser be will forced to make
an addition HTTP request to the server to render each page. This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there. Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each page (cacheable, too). And I get my dynamically-generated, changing JS (if any) in a final gzipped file. My page is clean, all the scripts load in the proper order at the end, and everything is gzipped and, where applicable, cacheable for the best speed. We've just eliminated several points of failure, as I see it. Note also that since I use Ext JS, some of my JS files are very long and complex. I'm building a rich client, after all. I want to separate these scripts out into simple modules to make it easier to code them. But when they are served, I want them combined together in the proper order into one file. Another benefit of this system. On final option might be to indicate in the Lift tag whether the combined JS should be an external resource or inserted into the HTML page. Then you could insert the dynamic stuff into the page if you wanted to. (Of course, if nothing in the HTML changes, you've just prevented the caching of the HTML page, but it might be a useful option.) I wish I could offer to do this, but I'm desperately swamped at the moment (OK, forever). But this is what I would suggest as the best way to do things. Chas. Xavi Ramirez wrote: If I understand everything correctly, the proposal is to dynamically create a js file for each page request to add event handlers? If this is true, then I'm against the proposal for the following two reasons: 1. Every page will load slower Since the js file is dynamically create on each request, the js file will be un-cacheable. This means the browser be will forced to make an addition HTTP request to the server to render each page. This adds roughly 150ms to the page load time (50ms to 200ms for network lag, 50ms for download, 10ms for js execution). 2. Each page will be more fragile Requiring the synthetic js file will add another point of failure. Even now-a-days with the ubiquity of broadband, connects still get lost and files still get corrupted. It's true that most modern web pages already depend a number of external JS and CSS files, but typically these files are static and easily cached. Just adding my 2 cents. -Xavi On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote: I think so too. Does anyone have an opinion against this? I'll probably have some time this week or next weekend to work on it. Br's, Marius On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote: A synthetic file sounds good to me and would probably be preferable. Cheers, Tim On 13 Sep 2009, at 20:31, marius d. wrote: That looks a little cleaner but we'll have to look more into it if we'd want to go on this path. Perhaps accumulate those function into synthetic js file .. we'll see --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en
[Lift] Re: Lift deal breakers
Is the DOM approach ruled out? I.e., generate a short script tag that is
generated from the events needed to be listened for, which are delegated to a
javascript generator that depends on the library. The actual JS files would be
static.
Maybe I missed where this option was eliminated?
Also, what did you mean by lucrative?
-
marius d.marius.dan...@gmail.com wrote:
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
/script
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03?pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. ?This means the browser be will forced to make
an addition HTTP request to the server to render each page. ?This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59?pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
marius d. wrote:
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
This is not what I had in mind at all. You still have the event handler
in the HTML. The idea, I thought, was to attach the event handler from
an external file using the id (or class) of the button element.
Maybe I'm living on a different planet (a distinct possibility and one
I've been giving much thought to recently), but virtually every JS
programmer I know considers this a best practice, and it has been
considered so for many years.
Frankly, and maybe I'm just a bit dull, but I can't conceive of what the
advantage to the above change might be. What am I missing?
Chas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
This is how we do JavaScript/ExtJS development at my work place, except with a twist. We actually have a javascript-only project for a our javascript library. We use the maven-javascript-tools plugins to create a javascript project that relies on others (in our case, things like Simile Timeline and ExtJS). We then compile/minify the javascript into an 'artifact' that gets used by our main webapp, where the alchim yui-compressor takes all the CSS/Javascript and bundles as much of it as possible into a single huge JS file. The library project can make use of JSUnit tests (slow-to-run, recommend for integration tests only), and has its own stubbed out controllers and jetty for testing. It's a very interesting setup, but I'm very happy with it. We have very modular JS code, and very very very very very very little JSP/HTML code (we didn't select lift at work). If I were to start using Lift for my backend to ExtJS I would need support for a similar setup (i.e. expect little or no HTML generated outside of the Javascript). Also, the ability to cache dynamically created pages works great for our product in production, however, we're only dynamically creating a javasript file containing very static resources (externalized string library for use when rendering in javascript. This ensures our Javascript and Java externalization works similarly.) I highly recommend the approach if using something like ExtJS, however for lift's templates I'd agree that a page-unique-id would be required for every synthetically created js file so that caching works appropriately. You can also force the browser to check if something's changed. We have a development hack that checks class-load time of the synthetic-js-generator and ensures the cached copy is up-to-date from that time. This means jetty-reloads will reload the class and ensure the next refresh pulls a new version. It's a bit tricky to get set up at first, but worked great! Hopefully this input is helpful! - Josh On Sun, Sep 13, 2009 at 8:48 PM, Charles F. Munat c...@munat.com wrote: I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there. Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each page (cacheable, too). And I get my dynamically-generated, changing JS (if any) in a final gzipped file. My page is clean, all the scripts load in the proper order at the end, and everything is gzipped and, where applicable, cacheable for the best speed. We've just eliminated several points of failure, as I see it. Note also that since I use Ext JS, some of my JS files are very long and complex. I'm building a rich client, after all. I want to separate these scripts out into simple modules to make it easier to code them. But when they are served, I want them combined together in the proper order into one file. Another benefit of this system. On final option might be to indicate in the Lift tag whether the combined JS should be an external resource or inserted into the HTML page. Then you could insert the dynamic stuff into the page if you wanted to. (Of course, if nothing in the HTML changes, you've just prevented the caching of the HTML page, but it might be a useful option.) I wish I could offer to do this, but I'm desperately
[Lift] Re: Lift deal breakers
Hi Marius,
Ahh yes I see. That's very different from what I originally
understood. Your implementation makes sense.
Thanks,
Xavi
On Sun, Sep 13, 2009 at 8:43 PM, marius d. marius.dan...@gmail.com wrote:
I kinda used the term js file a bit too loosely. It is true that each
page would likely have different functions there and even the same
page on subsequent load would have different content so the file can
not really be cached.
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
...
.. and at the end of the page:
script type=text/javascript
function liftAjax(id) {
liftAjax.lift_ajaxHandler(id + '=true',null, null, null); return
false;
}
...
/script
Likely there will be more synthetic functions that would need to be
generated depending on specific cases. This approach would result in a
slightly larger markup but I'm not sure if the impact is negligible or
not. In essence we are replacing a function call with another one more
concise which helps just in having a more concise function calls in
the markup.
BUT most likely for functions like liftAjax above we should put them
in liftAjax.js that lift generates and those would just be helper
function. This means that the script block above will not be needed
anymore. Thoughts?
Thanks Xavi for the good points.
Br's,
Marius
On Sep 13, 7:03 pm, Xavi Ramirez xavi@gmail.com wrote:
If I understand everything correctly, the proposal is to dynamically
create a js file for each page request to add event handlers?
If this is true, then I'm against the proposal for the following two reasons:
1. Every page will load slower
Since the js file is dynamically create on each request, the js file
will be un-cacheable. This means the browser be will forced to make
an addition HTTP request to the server to render each page. This adds
roughly 150ms to the page load time (50ms to 200ms for network lag,
50ms for download, 10ms for js execution).
2. Each page will be more fragile
Requiring the synthetic js file will add another point of failure.
Even now-a-days with the ubiquity of broadband, connects still get
lost and files still get corrupted.
It's true that most modern web pages already depend a number of
external JS and CSS files, but typically these files are static and
easily cached.
Just adding my 2 cents.
-Xavi
On Sun, Sep 13, 2009 at 5:41 PM, marius d. marius.dan...@gmail.com wrote:
I think so too. Does anyone have an opinion against this? I'll
probably have some time this week or next weekend to work on it.
Br's,
Marius
On Sep 13, 2:59 pm, Timothy Perrett timo...@getintheloop.eu wrote:
A synthetic file sounds good to me and would probably be preferable.
Cheers, Tim
On 13 Sep 2009, at 20:31, marius d. wrote:
That looks a little cleaner but we'll have to look more into it if
we'd want to go on this path. Perhaps accumulate those function into
synthetic js file .. we'll see
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
On Sep 13, 8:00 pm, Charles F. Munat c...@munat.com wrote:
marius d. wrote:
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
This is not what I had in mind at all. You still have the event handler
in the HTML. The idea, I thought, was to attach the event handler from
an external file using the id (or class) of the button element.
I understand that but this is a bit impractical because lift would
have to generate artificial ID-s OR id-s could be tampered with or
other JS libraries may generate their own ID-s etc. Selectors by class
is also a little impractical from a framework standpoint. Also we'd
have to add code for each underlying JS library (JQuery, YUI etc).
This would require IMHO significant code to write and not a
significant gain. But I'd love to prove me wrong.
Maybe I'm living on a different planet (a distinct possibility and one
I've been giving much thought to recently), but virtually every JS
programmer I know considers this a best practice, and it has been
considered so for many years.
I know this is practical from applications perspective when writing
specific JS etc. but from a framework perspective, this is not.
Frankly, and maybe I'm just a bit dull, but I can't conceive of what the
advantage to the above change might be. What am I missing?
I'm not 100% buying any proposal so far ... as I explained above the
disadvantages as we replace a JS expression with another JS function
call. It just adds a bit of conciseness .. nothing more.
Chas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
Well, conciseness is always good. I haven't looked at (and don't have
time to look at) the code that inserts this stuff, so I'll take your
word for it that it's a big undertaking. Lord knows, I don't have time,
so I'm certainly not complaining.
But we've got a desideratum, anyway. Maybe down the road someone will
have time to look at it.
Thanks for the clarification!
Chas.
marius d. wrote:
On Sep 13, 8:00 pm, Charles F. Munat c...@munat.com wrote:
marius d. wrote:
I'm thinking that instead of:
button onclick=liftAjax.lift_ajaxHandler
('F1029758482780OTA=true',null, null, null); return false;Press me/
button
We could have:
button onclick=liftAjax('F1029758482780OTA')Press me/button
This is not what I had in mind at all. You still have the event handler
in the HTML. The idea, I thought, was to attach the event handler from
an external file using the id (or class) of the button element.
I understand that but this is a bit impractical because lift would
have to generate artificial ID-s OR id-s could be tampered with or
other JS libraries may generate their own ID-s etc. Selectors by class
is also a little impractical from a framework standpoint. Also we'd
have to add code for each underlying JS library (JQuery, YUI etc).
This would require IMHO significant code to write and not a
significant gain. But I'd love to prove me wrong.
Maybe I'm living on a different planet (a distinct possibility and one
I've been giving much thought to recently), but virtually every JS
programmer I know considers this a best practice, and it has been
considered so for many years.
I know this is practical from applications perspective when writing
specific JS etc. but from a framework perspective, this is not.
Frankly, and maybe I'm just a bit dull, but I can't conceive of what the
advantage to the above change might be. What am I missing?
I'm not 100% buying any proposal so far ... as I explained above the
disadvantages as we replace a JS expression with another JS function
call. It just adds a bit of conciseness .. nothing more.
Chas.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Lift group.
To post to this group, send email to liftweb@googlegroups.com
To unsubscribe from this group, send email to
liftweb+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/liftweb?hl=en
-~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
This is pretty close to what I'm doing. I have a REST backend (in Lift) that serves the data, and a separate Ext JS front end (one single page with a lot of Ext JS) running in a separate Lift app. It's still in progress and I haven't worked out all the details yet, but I'm very happy with it so far. It has really simplified things. The difficult part is authentication/authorization. Ugh. I, too, am planning to combine and minimize my cacheable JS files when it goes live. Sounds like your system is much more sophisticated... Chas. Josh Suereth wrote: This is how we do JavaScript/ExtJS development at my work place, except with a twist. We actually have a javascript-only project for a our javascript library. We use the maven-javascript-tools plugins to create a javascript project that relies on others (in our case, things like Simile Timeline and ExtJS). We then compile/minify the javascript into an 'artifact' that gets used by our main webapp, where the alchim yui-compressor takes all the CSS/Javascript and bundles as much of it as possible into a single huge JS file. The library project can make use of JSUnit tests (slow-to-run, recommend for integration tests only), and has its own stubbed out controllers and jetty for testing. It's a very interesting setup, but I'm very happy with it. We have very modular JS code, and very very very very very very little JSP/HTML code (we didn't select lift at work). If I were to start using Lift for my backend to ExtJS I would need support for a similar setup (i.e. expect little or no HTML generated outside of the Javascript). Also, the ability to cache dynamically created pages works great for our product in production, however, we're only dynamically creating a javasript file containing very static resources (externalized string library for use when rendering in javascript. This ensures our Javascript and Java externalization works similarly.) I highly recommend the approach if using something like ExtJS, however for lift's templates I'd agree that a page-unique-id would be required for every synthetically created js file so that caching works appropriately. You can also force the browser to check if something's changed. We have a development hack that checks class-load time of the synthetic-js-generator and ensures the cached copy is up-to-date from that time. This means jetty-reloads will reload the class and ensure the next refresh pulls a new version. It's a bit tricky to get set up at first, but worked great! Hopefully this input is helpful! - Josh On Sun, Sep 13, 2009 at 8:48 PM, Charles F. Munat c...@munat.com mailto:c...@munat.com wrote: I'm afraid I have to disagree. As a website developer, I've been putting all my JS into an external file (per page when necessary) for many years without any problems. Every good JS programmer I know does the same. It is considered *more* not less robust to put the JS in an external file and attach event handlers to the DOM from there. Page loading is in the eye of the beholder. Moving the JS to external scripts and the script tags to the bottom of the page actually makes the page appear more quickly, hence load faster in the mind of the user. Fragility is a non-issue. If the JS is all in the external file and the file does not load, then the page loads without JS. Put the event handlers in the HTML and the external file to which they refer doesn't load, same problem (except now you get a raft of JS errors). With best practices, the JS file can be cacheable, albeit per-page. Ideally, here's what I'd like. I add Lift tags to my page for each JS file I want included with the page. In each tag I designate whether that file is cacheable or dynamic and whether it is site-wide or specific to that page. Lift then takes all the site-wide cacheable pages, in the order I specified them, and gzips them up into a single file. Then it inserts a script tag for that file at the bottom of the page. Similarly, it takes all the page-specific cacheable pages, adds Lift's own page specific stuff at the end (the event handlers of which we speak), gzips it, gives it a name unique to that page, and adds another script tag for that file. Finally, it gzips up all dynamically-generated JS and gives it a timestamp for a filename so it won't be cached. This way I get jQuery, Ext JS, etc. all downloaded and cached in one big gzipped file. I get all page-specific but unchanging JS in another gzipped file for each page (cacheable, too). And I get my dynamically-generated, changing JS (if any) in a final gzipped file. My page is clean, all the scripts load in the proper order at the end, and everything is gzipped and, where applicable, cacheable for the best speed. We've
[Lift] Re: Lift deal breakers
Hey, If I understand Dustin correctly here he wants unobtrusive javascript. That is no javascript in the elements but javascript code that hooks into the dom and attaches events as needed. I am not familiar enough with the internals of lift's js wrapping to know how easy it would be to do it this way. regards Bjarte On Sat, Sep 12, 2009 at 5:30 AM, DMB combust...@gmail.com wrote: I'm not sure how you'd implement an _ajax_ Button without Javascript. :-) I also don't see how it is bad for SEO. These days, depending on the page and search engine, Javascript either gets executed (if there are JS blocks that run onload or inline) or ignored. In case of less popular pages, JS is nearly always ignored, for indexing performance reasons. On Sep 11, 7:13 pm, Dustin Whitney dustin.whit...@gmail.com wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin -- Bjarte Stien Karlsen Ronatoppen 6a, 4638 Kristiansand 95219547 MSN: m...@ibjarte.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
I am not a fan of buttons in the html that don't do anything if javascript is disabled. To stop them from coming up in a text based browser or something similar, I've always had the rule for myself that any forms or buttons dependent on javascript must be inserted by javascript, and everything that appears in a plain html page should be functional (to some degree) with no javascript. That is the definition of unobtrusive javascript that I learned. I haven't yet spent much time with letting lift handle my javascript as I am used to handling it myself so I'm not too familiar yet with the limitations when making unobtrusive javascript solely with lift. I have always designed my pages first with no javascript, make it all work, and then add javascript/ajax without breaking the original behavior (overriding of course, using ajax instead of following a link, that sort of thing). -- Derek Williams --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
On Sep 12, 8:34 am, Indrajit Raychaudhuri indraj...@gmail.com wrote: Even if we assumed that Lift managed to do all the hard work, we still have a contradictory situation: the body/ being completely devoid of scripts but still have 'JS loaded at the end of the page'. It still has to be before the close of body tag and thereby sneaking into the body/. Worse, it's going to be incredibly difficult to implement a rich client interface (Cappuccino, Dojo, Sproutcore etc. - those who want to take complete control over the DOM) without the developer constantly having to prevent Lift and the UI framework not wrestle and step into the each other. A web *application* (like CMS) can get away with that, but not a *framework* (like Lift). What control of Lift over the DOM are you talking about. Lift's generated scripts in HTML is minimal, and it is about Comet mostly. Lift scripts do not really stay in other frameworks way. If you have a concrete example where Lift's stays in the way of integrating other tools please be specific about the problem and we'll see what/if we can do something about it. What is the exact wrestle here? And I am given to understand spiders are nowadays smart to recognize dom events handlers (e.g., onclick) and decide what to do when it encounters them. Oh, and while at that, 'view source' a GWT based application and help youself have a perspective :) Cheers, Indrajit On Sep 12, 5:07 pm, marius d. marius.dan...@gmail.com wrote: +1 Andrew. Regarding the rule - absolutely no javascript in the markup doesn't make a lot of sense. Some of the Lift's generated javascript for comet/ ajax calls is put inline at the end of the page. I see no practical reason not to do that. On the other hand putting liftAjax.js on the top of the page is not bad either. IN certain situations users may need this loaded prior their own js code. Besides I really doubt that putting it at the end of the page would really make any practical difference. Not putting lift's JS callas such as Ajax at onclick events like that can become quite lucrative from framework perspective because: 1. Lift would have to queue all these events and add them to a JS sequence and add this js to the served page. 2. that would create a dependency to JQuery events style that would have to be changed when YUI is in place or potentially other framework. If we'd still want this style but be JS library agnostic we'd have to do our own DOM manipulation etc which just adds more overhead without any practical gain. Br's, Marius On Sep 11, 10:18 pm, Andrew Scherpbier and...@scherpbier.org wrote: Dustin Whitney wrote:Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html:buttononclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/buttonThat onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. (I presume here SEO == Search Engine Optimization.) If you are going to use AJAX in your website, you have to use Javascript, right? If you don't want to use AJAX with lift, don't... Just use standard forms and links. (Also turn off client-side garbage collection and any comet stuff in Boot.scala...) So assuming you actually want an ajaxButton, the onclick needs to get in there somehow. The only other way would be to have lift create some javascript that modifies the DOM to somehow add that onclick. I think that would be much harder to read! For the SEO stuff, are you assuming deep traversal (clicking through forms) into your webapp by spiders? I don't know of any spiders that do that very well. Anyway, if that's what you want, then I wouldn't use AJAX for anything. A neat trick to let spiders get to all your public pages if your site has a complex form/ajax based navigation system is to use a site map and make sure all your main URLS are simple, non-form URLs. Criticism is best if one can demonstrate a better alternative.Client Side Load Time: I strive for that A in Y-Slow, so when I seescripttype=text/javascriptsrc=/ajax_request/liftAjax.js/scriptat the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. Have you actually verified that this makes a difference? I haven't verified this, so pardon my ignorance. It just seems like it either makes a difference of milliseconds or no difference at all because modern browsers make parallel requests and start rendering before everything is available. I'm sure if you can demonstrate two pages where the only difference is the location of the script include, and the one with the script include up front is noticeably slower
[Lift] Re: Lift deal breakers
I, too, would like to be able to move the liftAjax script call to the bottom of the page. Chas. Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
One nice thing about jquery's events, if done wisely, is they are applied after the DOM is loaded. With an onclick a button can be clicked and some ajax call is fired that returns and tries to modify a part of the DOM that hasn't been loaded. This is especially true if you have lots of javascript includes at the top of the page. I have waded my way through many wonky javascript bugs like this. They don't happen in your local environment because they load so quickly, but when pushed to production, problems ensue. Maybe there is a hook in the lift ajax js that waits to fire the call until after the DOM is loaded? -D On Sat, Sep 12, 2009 at 2:48 PM, Charles F. Munat c...@munat.com wrote: I, too, would like to be able to move the liftAjax script call to the bottom of the page. Chas. Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
Moving the script import shouldn't be too difficult, we have the lift:tail element and tail merge (which acts exactly the same as head merge) for just this sort of problem. On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney dustin.whit...@gmail.comwrote: One nice thing about jquery's events, if done wisely, is they are applied after the DOM is loaded. With an onclick a button can be clicked and some ajax call is fired that returns and tries to modify a part of the DOM that hasn't been loaded. This is especially true if you have lots of javascript includes at the top of the page. I have waded my way through many wonky javascript bugs like this. They don't happen in your local environment because they load so quickly, but when pushed to production, problems ensue. Maybe there is a hook in the lift ajax js that waits to fire the call until after the DOM is loaded? -D On Sat, Sep 12, 2009 at 2:48 PM, Charles F. Munat c...@munat.com wrote: I, too, would like to be able to move the liftAjax script call to the bottom of the page. Chas. Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
Maybe adding javascript event handlers could be delegated to something that depends on which library is being used? - Kevin Wrightkev.lee.wri...@googlemail.com wrote: Moving the script import shouldn't be too difficult, we have the lift:tail element and tail merge (which acts exactly the same as head merge) for just this sort of problem. On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney dustin.whit...@gmail.comwrote: One nice thing about jquery's events, if done wisely, is they are applied after the DOM is loaded. With an onclick a button can be clicked and some ajax call is fired that returns and tries to modify a part of the DOM that hasn't been loaded. This is especially true if you have lots of javascript includes at the top of the page. I have waded my way through many wonky javascript bugs like this. They don't happen in your local environment because they load so quickly, but when pushed to production, problems ensue. Maybe there is a hook in the lift ajax js that waits to fire the call until after the DOM is loaded? -D On Sat, Sep 12, 2009 at 2:48 PM, Charles F. Munat c...@munat.com wrote: I, too, would like to be able to move the liftAjax script call to the bottom of the page. Chas. Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
Technically it could (as I implied above) but this can be lucrative and IMHO the benefits are simply not that big. I'm not saying that things are nailed down but I'd love to see a list of practical benefits for Lift to not add event handlers such as on click to the elements but rather programatically using synthetic (lift generated) JS functions that would add events (i.e. JQuery, YUI ways). Br's, Marius On Sep 12, 9:05 pm, Naftoli Gugenheim naftoli...@gmail.com wrote: Maybe adding javascript event handlers could be delegated to something that depends on which library is being used? - Kevin Wrightkev.lee.wri...@googlemail.com wrote: Moving the script import shouldn't be too difficult, we have the lift:tail element and tail merge (which acts exactly the same as head merge) for just this sort of problem. On Sat, Sep 12, 2009 at 8:07 PM, Dustin Whitney dustin.whit...@gmail.comwrote: One nice thing about jquery's events, if done wisely, is they are applied after the DOM is loaded. With an onclick a button can be clicked and some ajax call is fired that returns and tries to modify a part of the DOM that hasn't been loaded. This is especially true if you have lots of javascript includes at the top of the page. I have waded my way through many wonky javascript bugs like this. They don't happen in your local environment because they load so quickly, but when pushed to production, problems ensue. Maybe there is a hook in the lift ajax js that waits to fire the call until after the DOM is loaded? -D On Sat, Sep 12, 2009 at 2:48 PM, Charles F. Munat c...@munat.com wrote: I, too, would like to be able to move the liftAjax script call to the bottom of the page. Chas. Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive javascript: when I create an ajaxButton I get this html: button onclick=liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no javascript should appear on the page whatsoever. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type=text/javascript src=/ajax_request/liftAjax.js view-source:http://localhost:8080/ajax_request/liftAjax.js/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. -Dustin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
[Lift] Re: Lift deal breakers
Dustin Whitney wrote: Hey, I like Lift so in an effort to improve it I am submitting some criticism. Obtrusive _javascript_: when I create an ajaxButton I get this html: button onclick="liftAjax.lift_ajaxHandler(quot;F1029758482780OTA=truequot;, null, null, null); return false;"Press me/button That onclick is not ok. It's bad for SEO and makes the page harder to read. Ideally, no _javascript_ should appear on the page whatsoever. (I presume here SEO == Search Engine Optimization.) If you are going to use AJAX in your website, you have to use _javascript_, right? If you don't want to use AJAX with lift, don't... Just use standard forms and links. (Also turn off client-side garbage collection and any comet stuff in Boot.scala...) So assuming you actually want an ajaxButton, the onclick needs to get in there somehow. The only other way would be to have lift create some _javascript_ that modifies the DOM to somehow add that onclick. I think that would be much harder to read! For the SEO stuff, are you assuming deep traversal (clicking through forms) into your webapp by spiders? I don't know of any spiders that do that very well. Anyway, if that's what you want, then I wouldn't use AJAX for anything. A neat trick to let spiders get to all your public pages if your site has a complex form/ajax based navigation system is to use a site map and make sure all your main URLS are simple, non-form URLs. Criticism is best if one can demonstrate a better alternative. Client Side Load Time: I strive for that A in Y-Slow, so when I see script type="text/_javascript_" src="/ajax_request/liftAjax.js"/script at the top of the page, I feel a little uneasy, and there is nothing I can do (I think) to move it to the bottom of the page. Have you actually verified that this makes a difference? I haven't verified this, so pardon my ignorance. It just seems like it either makes a difference of milliseconds or no difference at all because modern browsers make parallel requests and start rendering before everything is available. I'm sure if you can demonstrate two pages where the only difference is the location of the script include, and the one with the script include up front is noticeably slower than the other one, I'm sure something can be done. --Andrew -Dustin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Lift group. To post to this group, send email to liftweb@googlegroups.com To unsubscribe from this group, send email to liftweb+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~--~~~~--~~--~--~---
