wicket8 : wickets js/ jquery integration
Hi, currently wicket renders all its jQuery and Ajax stuff right into the head, and I wonder why. Current best practice seems to defer all javascript till the end of the page just right before the closing tag to let the browser meanwhile get the DOM and do some work and not get blocked by loading resources. So wouldnt it maybe with wicket 8 be a good time to change this? e.g. Do all the stuff ajax stuff... by default? and since mostly today jQuery is already on the page maybe even allow to apply a null at the getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket reference on it at all? Many webapps nowadays tend to only have 1 app.js that includes everything as its often build by tools like webpack. Would this be a good or bad idea? Best, Korbinian PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?
Re: wicket8 : wickets js/ jquery integration
Hi Korbinian, using the "defer" attribute on script tags in the head section seems to be best practice now: https://www.shivering-isles.com/the-science-of-loading-javascript/ Wicket supports the attribute since https://issues.apache.org/jira/browse/WICKET-5715 Have fun Sven Am 07.10.2017 um 19:49 schrieb Korbinian Bachl: Hi, currently wicket renders all its jQuery and Ajax stuff right into the head, and I wonder why. Current best practice seems to defer all javascript till the end of the page just right before the closing tag to let the browser meanwhile get the DOM and do some work and not get blocked by loading resources. So wouldnt it maybe with wicket 8 be a good time to change this? e.g. Do all the stuff ajax stuff... by default? and since mostly today jQuery is already on the page maybe even allow to apply a null at the getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket reference on it at all? Many webapps nowadays tend to only have 1 app.js that includes everything as its often build by tools like webpack. Would this be a good or bad idea? Best, Korbinian PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?
Re: wicket8 : wickets js/ jquery integration
On Oct 7, 2017 23:23, "Sven Meier" wrote: Hi Korbinian, using the "defer" attribute on script tags in the head section seems to be best practice now: The problem is that the ondomready scripts depend on jquery and wicket-xyz ones and there is no way to defer them. https://www.shivering-isles.com/the-science-of-loading-javascript/ Wicket supports the attribute since https://issues.apache.org/jira /browse/WICKET-5715 Have fun Sven Am 07.10.2017 um 19:49 schrieb Korbinian Bachl: > Hi, > > currently wicket renders all its jQuery and Ajax stuff right into the > head, and I wonder why. > Current best practice seems to defer all javascript till the end of the > page just right before the closing tag to let the browser meanwhile > get the DOM and do some work and not get blocked by loading resources. So > wouldnt it maybe with wicket 8 be a good time to change this? > > e.g. Do > > > all the stuff > > > > ajax stuff... > > > > by default? and since mostly today jQuery is already on the page maybe > even allow to apply a null at the > getJavaScriptLibrarySettings().setJQueryReference(null); > to not have a wicket reference on it at all? Many webapps nowadays tend to > only have 1 app.js that includes everything as its often build by tools > like webpack. > > Would this be a good or bad idea? > > Best, > > Korbinian > > PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right? > >
Re: wicket8 : wickets js/ jquery integration
Is the such option for CSS as well? I have implemented "delayed load" manually since both JS and CSS were reported as "blocking scripts" On Sun, Oct 8, 2017 at 12:25 PM, Martin Grigorov wrote: > On Oct 7, 2017 23:23, "Sven Meier" wrote: > > Hi Korbinian, > > using the "defer" attribute on script tags in the head section seems to be > best practice now: > > > The problem is that the ondomready scripts depend on jquery and wicket-xyz > ones and there is no way to defer them. > > > https://www.shivering-isles.com/the-science-of-loading-javascript/ > > Wicket supports the attribute since https://issues.apache.org/jira > /browse/WICKET-5715 > > Have fun > Sven > > > > Am 07.10.2017 um 19:49 schrieb Korbinian Bachl: > >> Hi, >> >> currently wicket renders all its jQuery and Ajax stuff right into the >> head, and I wonder why. >> Current best practice seems to defer all javascript till the end of the >> page just right before the closing tag to let the browser meanwhile >> get the DOM and do some work and not get blocked by loading resources. So >> wouldnt it maybe with wicket 8 be a good time to change this? >> >> e.g. Do >> >> >> all the stuff >> >> >> >> ajax stuff... >> >> >> >> by default? and since mostly today jQuery is already on the page maybe >> even allow to apply a null at the >> getJavaScriptLibrarySettings().setJQueryReference(null); >> to not have a wicket reference on it at all? Many webapps nowadays tend to >> only have 1 app.js that includes everything as its often build by tools >> like webpack. >> >> Would this be a good or bad idea? >> >> Best, >> >> Korbinian >> >> PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right? >> >> -- WBR Maxim aka solomax
Re: wicket8 : wickets js/ jquery integration
Hi Sven, in theory you are right - but with wicket ajax on page you get an inline script like marting said. > The problem is that the ondomready scripts depend on jquery and wicket-xyz > ones and there is no way to defer them. So, you never can defer the jQuery currently as its from wicket itself and same is IMHO for the wicket js files. The only way I can think of is to transfer the inline script into a base64 and embedd it this way: Then the jQuery could be made defered - you can check it here: https://stackoverflow.com/questions/41394983/how-to-defer-inline-javascript However, I'm not sure yet that every browser works with this. So the put to bottom is IMHO still the best way to do it. Or did I miss something here? Also what do you think on allowing to not use the wicket jQuery at all? e.g.: getJavaScriptLibrarySettings().setJQueryReference(null); Anyway, I think wicket should not block the rendering of the page by default, especially as mobile is becoming the 50%+ audience nowadays. Best, Korbinian - Ursprüngliche Mail - > Von: "Sven Meier" > An: dev@wicket.apache.org > Gesendet: Samstag, 7. Oktober 2017 22:22:56 > Betreff: Re: wicket8 : wickets js/ jquery integration > Hi Korbinian, > > using the "defer" attribute on script tags in the head section seems to > be best practice now: > > https://www.shivering-isles.com/the-science-of-loading-javascript/ > > Wicket supports the attribute since > https://issues.apache.org/jira/browse/WICKET-5715 > > Have fun > Sven > > > Am 07.10.2017 um 19:49 schrieb Korbinian Bachl: >> Hi, >> >> currently wicket renders all its jQuery and Ajax stuff right into the head, >> and >> I wonder why. >> >> Current best practice seems to defer all javascript till the end of the page >> just right before the closing tag to let the browser meanwhile get >> the >> DOM and do some work and not get blocked by loading resources. So wouldnt it >> maybe with wicket 8 be a good time to change this? >> >> e.g. Do >> >> >> all the stuff >> >> > src="../wicket/resource/org.apache.wicket.resource.JQueryResourceReference/jquery/jquery.js"> >> >> ajax stuff... >> >> >> >> by default? and since mostly today jQuery is already on the page maybe even >> allow to apply a null at the >> getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket >> reference on it at all? Many webapps nowadays tend to only have 1 app.js that >> includes everything as its often build by tools like webpack. >> >> Would this be a good or bad idea? >> >> Best, >> >> Korbinian >> >> PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?
Re: wicket8 : wickets js/ jquery integration
Putting header items at the end of is documented here: https://ci.apache.org/projects/wicket/guide/8.x/single.html#_put_javascript_inside_page_body. Like Sven I also personally dislike this kind of habit but we might consider to make the overall configuration easier for it. On 08/10/2017 11:06, Korbinian Bachl wrote: Hi Sven, in theory you are right - but with wicket ajax on page you get an inline script like marting said. The problem is that the ondomready scripts depend on jquery and wicket-xyz ones and there is no way to defer them. So, you never can defer the jQuery currently as its from wicket itself and same is IMHO for the wicket js files. The only way I can think of is to transfer the inline script into a base64 and embedd it this way: Then the jQuery could be made defered - you can check it here: https://stackoverflow.com/questions/41394983/how-to-defer-inline-javascript However, I'm not sure yet that every browser works with this. So the put to bottom is IMHO still the best way to do it. Or did I miss something here? Also what do you think on allowing to not use the wicket jQuery at all? e.g.: getJavaScriptLibrarySettings().setJQueryReference(null); Anyway, I think wicket should not block the rendering of the page by default, especially as mobile is becoming the 50%+ audience nowadays. Best, Korbinian - Ursprüngliche Mail - Von: "Sven Meier" An: dev@wicket.apache.org Gesendet: Samstag, 7. Oktober 2017 22:22:56 Betreff: Re: wicket8 : wickets js/ jquery integration Hi Korbinian, using the "defer" attribute on script tags in the head section seems to be best practice now: https://www.shivering-isles.com/the-science-of-loading-javascript/ Wicket supports the attribute since https://issues.apache.org/jira/browse/WICKET-5715 Have fun Sven Am 07.10.2017 um 19:49 schrieb Korbinian Bachl: Hi, currently wicket renders all its jQuery and Ajax stuff right into the head, and I wonder why. Current best practice seems to defer all javascript till the end of the page just right before the closing tag to let the browser meanwhile get the DOM and do some work and not get blocked by loading resources. So wouldnt it maybe with wicket 8 be a good time to change this? e.g. Do all the stuff ajax stuff... by default? and since mostly today jQuery is already on the page maybe even allow to apply a null at the getJavaScriptLibrarySettings().setJQueryReference(null); to not have a wicket reference on it at all? Many webapps nowadays tend to only have 1 app.js that includes everything as its often build by tools like webpack. Would this be a good or bad idea? Best, Korbinian PS: in wicket 8 jquery 2.x is interchangable with jquery 3.x, am I right?
