Size does Matter

hcgtv · 2015-07-05 14:16:41

What I love about Textpattern is it’s small size.

A Textpattern 4.5.7 install takes 2.2MB of disk space, uploading this to your web space is a breeze, even on 56k dial up.

Since I’ve been back, I’ve begun re-acquainting myself with the dev branch, and I can report that it’s a growing.

Maybe it’s getting enticed by other sexy projects?

Right now the master branch of TXP takes up 3.8MB of disk space on my local web server.

That’s a jump of 1.6MB from 4.5.7 to 4.6dev, that’s a big increase in size.

Mostly it’s the Vendors folder, I imagine it’s for the backend admin enhancements.

Can someone explain to me the folders under Vendors, the uses for said library – admin only or the front end needs it kind of thing.

Thanks.

Bloke · 2015-07-05 14:31:07

It’s not just the vendors folder that accounts for the space increase. That contains mostly code that has been moved from elsewhere into a more object-oriented kind of structure so actual code footprint hasn’t gone up that much (bar jQuery UI and other third party libraries rolled in).

The big space hogs in 4.6-dev are:

Full DocBlock comments for functions and variables instead of crappy one-liners (or none). There’s much more of that to come so it’s going to grow further.
Standard headers to every file: copyright info, licence info, if-you-use-this-software-and-it-eats-your-lizard-it’s-not-our-fault info. With the increase in the number of files, this adds a fair bit to the space utilisation.
Moving from 1 tab character to 4 spaces for indentation. That’s a HUGE size hog, and one I don’t particularly care for. But I know why it was done, to comply with PSR-2’s recommendation that it makes diffs more robust in version control systems when moving from system to system. A space is a space is a space. A tab is 4 spaces, no… 8, no… 3…

hcgtv · 2015-07-05 14:42:44

Bloke wrote #292589:

It’s not just the vendors folder that accounts for the space increase. That contains mostly code that has been moved from elsewhere into a more object-oriented kind of structure so actual code footprint hasn’t gone up that much (bar jQuery UI and other third party libraries rolled in).

Yeah, the jQuery UI accounts for 0.7MB of the size.

I’m really liking the new Hive in 4.5.7, in place edits and all that, no more page refreshes. And the new admin layout update is awesome, wish I could run it already. If the libraries are needed, then so be it.

Just playing devil’s advocate.

gaekwad · 2015-07-05 17:46:43

It’s possible to trim a lot of stuff away from 4.5.x if you prefer a slimline Textpattern, I’m sure most of this can be achieved with 4.6-dev, too:

zap the rpc directory if you’re not using RPC
zap the sites directory if you’re a single site
zap the textpattern/setup directory if you’re upgrading an existing site
zap the admin themes you’re not using
zap *.txt, except checksums.txt

How does that look, now?

hcgtv · 2015-07-05 18:19:35

gaekwad wrote #292595:

How does that look, now?

You just detailed the specially rolled textpattern-hcg build that goes up the tubes ;)

Along with mods, special .htaccess files, etc.

gaekwad · 2015-07-05 18:23:12

hcgtv wrote #292600:

You just detailed the specially rolled textpattern-hcg build that goes up the tubes ;)

I’m sure we can reduce the size further – just opened this thread: forum.textpattern.com/viewtopic.php?id=45919

phiw13 · 2015-07-06 01:37:41

I’m not really worried about disk space, personally. That is cheap and plentiful.

What worries me more is network performance (jquery-ui.js is very heavy at 240kb, although gzipping will improve that) and, importantly, rendering performance. Again, jquery-ui.js is a serious perf. hog. Philwareham has somewhere a mockup of the preferences pane with some manipulation of radio buttons through jquery-ui.js. On my iPad mini retina the page rendering is dead slow (the script has to loop through ~76 radio buttons). Ditto on my 11“MBA (with any browser).

Imagine if jquery-ui.js is applied to more than radio buttons (like select elements) and more importantly on the Write pane (used more frequently, I would think).

Bloke · 2015-07-06 08:46:22

phiw13 wrote #292612:

jquery-ui.js is a serious perf. hog.

Yes it is. And I’m not exactly happy to have it in core for that reason alone, although I recognise some of the stuff it allows us to do.

I kinda wish there was a leaner alternative as my sneaking suspicion is that the reason the WP admin side is so unbearably sluggish is all the widget interaction and JavaScript code. It’s just mental the amount of stuff that’s included in the /js folder.

There are other widgety tools out there of course, including a swiss army knife set of micro tools, although there’s no consistency in presentation if using disparate tools like that to achieve the job. jQuery UI is at least themeable(ish), with a fight.

In the absence of anything better (anyone?), we’ll just have to hope we can keep JS interaction to a minimum and only include the elements we need to keep the speed up. Or work around the jQuery UI limitations in places such as the Prefs panel example you cite by, I dunno, splitting it up and using AJAX to load each group (or something) to minimise the amount of items on a page.

One thing we do not want to introduce is a sluggish admin experience, so anything and everything we can do to keep the speed up (compression, minifying, only loading what we need when we need it, keeping byte count down in markup and stylesheets, and so on) are high on my hit list, as and when bottlenecks are identified. So please keep testing and if anyone has any cool ideas about how to improve performance, I’m always keen to hear them.

philwareham · 2015-07-06 08:58:55

The jQuery UI radio buttons are something I’m playing around with, for sure, but may well decided against in final code. Ditto the jQuery-UI <select> lists.

philwareham · 2015-07-06 09:03:36

I

Bloke wrote #292620:

I kinda wish there was a leaner alternative as my sneaking suspicion is that the reason the WP admin side is so unbearably sluggish is all the widget interaction and JavaScript code.

Currently we include the whole suite of jQuery UI widgets and interactions – there may be some we can cull to improve performance. Although… we may want to keep all as a more flexible approach – I seem to remember some discussions when we first considered the jQuery UI library that it would be good to include the whole library and not just cherry-pick.

Bloke · 2015-07-06 09:07:11

philwareham wrote #292625:

I seem to remember some discussions when we first considered the jQuery UI library that it would be good to include the whole library and not just cherry-pick.

Yes, we decided to include the full thing. And it makes sense (easier to use a CDN for starters). And also that plugin authors can add UI functionality that may not be in core without having to worry about loading their own version.

Once downloaded and cached it’ll be fine from a page download/byte count perspective. The optimisations will come from being smart about which bits of jQuery UI we expose in the admin side to enhance the experience without slowing things down.

hcgtv · 2015-07-06 09:34:13

Coming from Textpattern 4.4.1, and using 4.5.7 for the last week in production, I like the new admin side, it’s grown on me. Like I mentioned earlier, the new save action on the write page is great, no screen flicker.

Aside from making the admin more responsive, I don’t see a need for any other jQueriness. The new admin layout I’ve been testing from Phil has the settings page with drop down blind effects, I prefer the way 4.5.7 has it, 3 toggles on the top, simpler.

There are all kinds of really cool stuff in the jQuery UI libraries, I think for the front side, for someone wanting to create a more interactive experience for their users, it’s great not having to re-invent the wheel.

Honestly, I want less on the admin side, the tag builder is history in the admin layout update branch, larger text areas at last. The whole look of the new admin layout is light years ahead of the old classic theme in 4.4.1, it’s now a project with a fighting chance to gain users, IMHO.

Where’s that command line interface to Textpattern, us old-timers don’t need no stinking GUIs ;)

Last edited by hcgtv (2015-07-06 09:35:01)

Textpattern CMS

Textpattern CMS support forum

#1 2015-07-05 14:16:41

Size does Matter

#2 2015-07-05 14:31:07

Re: Size does Matter

#3 2015-07-05 14:42:44

Re: Size does Matter

Bloke wrote #292589:

#4 2015-07-05 17:46:43

Re: Size does Matter

#5 2015-07-05 18:19:35

Re: Size does Matter

gaekwad wrote #292595:

#6 2015-07-05 18:23:12

Re: Size does Matter

hcgtv wrote #292600:

#7 2015-07-06 01:37:41

Re: Size does Matter

#8 2015-07-06 08:46:22

Re: Size does Matter

phiw13 wrote #292612:

#9 2015-07-06 08:58:55

Re: Size does Matter

#10 2015-07-06 09:03:36

Re: Size does Matter

Bloke wrote #292620:

#11 2015-07-06 09:07:11

Re: Size does Matter

philwareham wrote #292625:

#12 2015-07-06 09:34:13

Re: Size does Matter

Board footer