Stacks edit mode performance

I strongly discourage using PlusKit to import Stacks pages into Stacks. Many things will not work at all. Some will work strangely.

PlusKit is built to import simple pages – pages with basic content and a few assets.

PlusKit warns against importing complex pages (like Stacks) – right inside the plugin setup.

Honestly, I really really want to just make this impossible, but too many people complained when I beta tested that – so here we are.

But seriously, just don’t do it.

Use partials. Or even externals editing in separate files. If editing a sub-page in its own file is STILL too slow, then it’s not RW or Stacks or your project or you – it’s time to demand that the Stack developer put some more effort in to speeding up edit-mode.

As a total aside, I’ve been considering attacking this sort of edit-mode performance things head on. Here’s my current brain-dump on that at the moment… feel free to ignore – and don’t respond here – it’s entirely off topic. If you have questions or comments about this, start a new thread. 😃

OK, let’s do this…

Most of the issue comes down to putting too much CSS/HTML into edit mode’s web view. Of course Edit mode was meant to be a simplified, style-free tool for composing the layout of your page – just enough style to guide you – leaving everything else for Preview mode. Of course everyone likes to see a bit more WYSIWYG preview in there too – and stack devs try to please… so after a decade of pleasing results are: stack developers try to force as much of preview-mode into edit mode. It looks nice, but it’s pretty slow – unless you have a blazing fast machine editing a big page or one with a few complex stacks can be frustrating.

There are various ways I can skin this cat:

  • do only partial loading of just what you see on the screen at the moment
  • limit the api to exclude the costly stuff
  • add another new layer of fast-editing (this time for sure Rocky)
  • etc.

partial loading

partial loading seems like a nice idea – but it only buys so much. frameworks like foundation/foundry/etc. load a heap of CSS at the top of the page and expect it to apply to the stacks at the bottom of the page – so partial loading would either have to account for that (in which case we haven’t really helped much) or force the frameworks to do some painful redesign.

honestly, i don’t see this solution as having any legs in the current ecosystem.

limit the api for edit mode

i did this a bit years ago – but developers resist it. i cut out a VERY slow API feature called “repeat” and told developers it would go away “soon” – and they should stop using it. That was about 7 years ago. there are stacks still being released that use the feature. in order to really make a dent on performance, i’ll would have to seriously chop – and that just seems nearly impossible. Developers won’t stop until they’re forced – and that means hurting customers which I’m loathe to do ever.

i’ve considered putting a big, high-profile, switch on the edit mode UI that just chops out most of the CSS – but controlled by the user. this would, at the cost of making edit mode very bland, radically speed things up. but i know if i do it that developers will start hiding styles inline within the HTML. so it’s probably just a temporary fix at best. i can combat that with some filtering. it would be a game of whack-a-mole.

despite these downsides, i still think there are potentials to this methodology. some combinations of limitations, filters, and user-controlled “enable fast mode now” switches seems like it could at least be a partial solution.

a fast edit-mode

since our nice once upon a time fast edit-mode has turned into a barely-faster-than-preview mode, it might be a good idea to make a really-really-i-mean-it-this-time-for-sure-edit mode. something that didn’t include any CSS – or maybe some hugely limited styling – or maybe just a plain vanilla source-list view of all the stacks – no layout, no style, no nothing – just rely on jumping over to preview or the RW simulator for seeing the results of your edits.

Of course none of those things, on its own, sounds too great either. Editing your stacks in a list-view seems only one step up from HTML. But again, maybe in combination with other solutions it might work?

I’ve probably already decided on which direction I’ll take Stacks, but since these forums seem to be scraped by the less-original amongst the competitors looking for feature ideas – i have to just let everyone guess at what that direction will be. 😉


@isaiah Great brain dump.

The Partial Loading may still be valuable for the sort of micro featherlight framework being developed, such as HabitualShakers Source. Source shows that frameworks don’t have to be huge in size and also that you don’t need to throw the kitchen sink full of code at every page. With hindsight, maybe we can say that these relatively huge frameworks were not a good fit and never will be, for RW + Stacks.

Another option that may be worth considering is Partial Removal or off screen section Removal, i.e. removing chunks of layout that are not required either for current view or for the part of the page being worked on. In a web page with more content that fits on a screen, the view above and below the screen edit view, may not need to be processed.

Out of renewed interest, if you hide a stack, does that stack get processed and made invisible or is it complexly ignored and collapsed from view?

1 Like

The problem is that it’s very difficult to figure out what bits you can stop loading and how much performance that will buy. It varies greatly by stack. I’m quite sure that most developers have no idea how, how-much, or why their stack is performing poorly.

One thing that I can do to help this situation is to expose more hard performance data for the user: how much time each stack takes to render

And expose more hard data for the developer: how much time each template/control/library takes to render/display.

These might not be tools for every user or every developer – but hopefully the more advanced users will have useful data for these forums and developer bug reports. And the better developers will have more specific info to help them improve.


That sounds great 👍

2 weeks ago, everyone was praise of the speed of UIKit3 including @Isaiah so is it just that we try to make pages that are very big and complex and cause these problems for ourselves. Perhaps we should use a different tool for such pages if we really need so much. UIKit is fast for me with all reasonable pages (not super small).

1 Like

@Johan - UIKit is great. A framework that really focuses on speed and simplicity.

It’s a good counterpoint to many of the other frameworks, because just as you’ve said, you can build very complex pages even with moderate hardware and things stay quite usable.

I don’t know that UIKit is the perfect solution for all folks though. Some of the other frameworks, while definitely slower (in Edit mode) are a bit more feature complete. As always, there are tradeoffs to be made.

UK: Horses for courses…
US: Different strokes for different folks…

What I’d really like to see… UIKit get a few more features. And some of the more feature-full frameworks could focus a bit on improving performance.

UPDATE: I just realize that @Lucas released a new version of UIKit with more goodies only 2 hours ago!!! So, I think I’ve got one thing from my wish-list already. 😆

Because at the end of the day, it’s best if there’s a wide range of frameworks available – because there are a lot of VERY DIFFERENT projects that have VERY DIFFERENT needs.