Plone 5 frontend development plugin for webpack

[datakurre (Asko Soukka)]

@djay How much of Plone do you need exactly? That really affects the complexity.

[djay (Dylan Jay)]

@datakurre I think we mostly need patterns and tinymce integration. We also need patterns that have been written in the plomino bundle. Mainly we are trying to handle several DX forms by loading and POSTing them via ajax. And they use patterns.

[djay (Dylan Jay)]

@datakure we don't need the toolbar or contents or any of that stuff.

[datakurre (Asko Soukka)]

@djay As I said, I'd try my first approach (without plonetheme-webpack-plugin) at first. So, instead of merging that, I merged parts from plonetheme.webpack:

Include and configure mockup for webpack

It builds, at least. I have not tested further. Another twists are that typescript will complain when you import non-ts-modules (and because it does not know about webpack aliases) and if you don't use those modules, typescript seem to drop them and they won't get bundled. Also, as you can see from the required tweaks (lot of git checkouts with npm), we are far from being proper JS citizens.

[keul (Luca Fabbri)]

@vangheem

I still image, even with http2 spec, we'll want bundling. Considering modern framework can build hundreds of files together--even if the client is able to maintain one connection, it'll be many more hits on the server and I also wonder if the client will be less performant.

Although I think that bundle could never disappear completely, recently I read a lot of articles by some "front-end guys". What seems clear is that HTTP2 remove the need of bundling. Full stop. Somebody says that "bundling will be an anti-pattern". Also: HTTP2 support today is really high so I find the webpack approach outside Zope every day more interesting.

This take me to another question:

(...five secs of dramatic drum sound...)

Will Zope ever support HTTP2? Or it makes no sense?

[thet (Johannes Raggam)]

@keul

Will Zope ever support HTTP2? Or it makes no sense?

I think, that can be achieved via an external WSGI server.

[djay (Dylan Jay)]

@datakurre sorry I missed where you said to not use plonetheme-webpack-plugin. I've had a look at your code. I can see it tries to bring in patterns so now I will try calling the scan and see if I can get that working. I will also have to work out how to modify this to bring in the patterns defined in plomino but I think this will give me the start I need. Thanks very much for you help

[datakurre (Asko Soukka)]

I've finally updated plonetheme.webpacktemplate for Webpack 2.x. I should be using it myself for the next few weeks, so I expect to solve any issues.

I'm also experimenting the related webpack plugin (one that loads resources from Plone RR for webpack) with add-on development https://github.com/plone/plone.app.theming/pull/130 Not sure yet, if it's really that useful outside theming.

[hvelarde]

@keul

recently I read a lot of articles by some "front-end guys". What seems clear is that HTTP2 remove the need of bundling. Full stop. Somebody says that "bundling will be an anti-pattern".

do you mind to share those readings? it could be interesting for people still hooked on the past, using old fashioned technologies like bundling (pun intended).

[hvelarde]

@vangheem

I still image, even with http2 spec, we'll want bundling. Considering modern framework can build hundreds of files together--even if the client is able to maintain one connection, it'll be many more hits on the server and I also wonder if the client will be less performant.

that's not the case; here are some good reasons against bundling (from a Stack Overflow post):

• Bundling can lead to trivial cache misses. Any change to any part of your app invalidates the browser cache.
• Bundling can make it harder to leverage a cache of common libraries. If you're using the same version of jquery from the same cdn as everyone else there's a good chance your users will never have to even hit your servers for it.
• Bundling means that you generally are loading all of your JavaScript at once. There are exceptions like webpack code splitting but this complicates your build pipeline versus cating files.
• Bundling means missing out on HTTP/2's ability to handle multiple asset requests in parallel.

here are some real life numbers from the CloudFlare website:

Access via HTTP Protocol Version 	Average Page Load time
HTTP 1.x 				9.07 sec.
SPDY/3.1 				7.06 sec.
HTTP/2 					4.27 sec.

yes, we may still need bundling, but for some totally different reasons than performance.

UPDATE: here are other interesting numbers showing latency in the biggest player here: if you expect a high latency then you gain almost nothing by concatenating: but, if you expect low latency concatenating could be in fact much better:

The Right Way to Bundle Your Assets for Faster Sites over HTTP/2

having said that, my initial proposal to bundle on a add-on base makes a lot of sense.

for Plone, bundling for anonymous and authenticated users, leaving the common libraries out, sounds like the best approach.

[datakurre (Asko Soukka)]

@datakurre

I've finally updated plonetheme.webpacktemplate for Webpack 2.x. I should be using it myself for the next few weeks, so I expect to solve any issues.

I've finally updated plonetheme.webpacktemplate for Webpack 4.x for building a TTW uploadable Diazo them with Webpack bundled resources. I have not yet updated my projects to use it, so it is possible that there are still some rough edges.

Travis has smoketest builds for the latest Plone 5.0 and 5.1 Travis CI - Test and Deploy with Confidence

There are a few major changes to fix things and make the template simpler to use:

• The resulting theme now loads Plone require.js configuration after Webpack bundles. This fixes issues with non-patternized scripts like search page and Dexterity schema editor drag and drop. It also allows to write TTW scripts with require.js even when the base bundle is Webpack based.

• There is only one Webpack bundle entry-point by default. Resources for logged-in-users are loaded lazily using Webpack dynamic imports when the user looks like being logged-in. Previous versions created separate bundles for anymous and logged-in users (and e.g. for large add-ons) and unnecessary bundles were filtered using Diazo rules. This is still possible, but I wanted to support dynamic imports by default (with a polyfill for IE 11) and include example of using those. Technically this would allow e.g. include certain patterns only when "pat-something" is present (if lazy loading does not affect the user experience).

• jQuery is not exposed by default (but can be exposed with uncommenting a single line)

• I removed SVG-icons option and Vagrant support. Also, thanks to upstream fixes, it was also no longer required to include a customized copy of barceloneta.plone.less. These all reduced number of files and hopefully simplified the template.

[datakurre (Asko Soukka)]

I had chance to do some maintenance for plonetheme.webpacktemplate with the following results:

• Latest webpack 4.x is supported.

• Plone 5.0.x is currently supported only up to 5.0.8, because Plone 5.0.9 and 5.0.10 seem to ship with source versions of TinyMCE and Mockup incompatible with each other (the pattern requires resources not available in the shipped TinyMCE version).

• Plone 5.1.5 seems to work fine.

• Plone 5.2.0 is now supported. Minor change (dynamic require) in moment-pattern required upgrade to the webpack plugin. Also because of some change between Plone 5.1 and 5.2, pattern registry scan was no longer triggered automatically with webpack bundles, but must be called from the bundle (included in template).