Stacks page not responding well

I am regularly experiencing some latency and unresponsiveness from the Stacks UI when I have many stacks on my page. Usually when I grab a stack to drag it somewhere else this works fine. But in complex pages I find I’m just not able to drop a stack e.g. into a column stack that already contains some stacks. Usually the interface should “make some space” between the two stacks I want to drag something in and indicate that by showing a light blue placeholder. However, on complex pages the placeholder doesn’t appear and when I let the moved stack go where I want it to go, it appears somewhere else (usually below or above the parent stack).
Have others had this experience? I am on RW 7.3.3, Stacks 3.2.7 and regularly check my stacks for updates.

It happens to me sometimes. As a workaround, I cut the stack (command-x), I select the stack directly ahead of the place where I intend to drop the new stack and then press command-v to paste it. Usually, this works, but if I still miss the exact spot, then I drag the new stack into the right place.

I know, this is not an ideal solution, but it works for now. Perhaps @isaiah could get involved in this topic?

I’ve seen this as well as long wait time when editing stack contents on very complex (clicking to select text for example) pages with large numbers of stacks.

I sent a project to yourhead at one point and was told it was expected, I was pushing the limits.
I have since taken to splitting very complex pages into sections in a “template project” and once each section is tweeked, I paste them into the real project. Kind of a PIA but if that’s what it takes…

1 Like

I also see this frequently when working on complex pages with a lot of stacks. As soon as I see this behaviour, I save and restart RW as a precaution and sometimes that helps when RW is restarted. Also, on projects that exhibit this behaviour the Preview times are huge. This actually got so bad that I had to rethink how I used RW to build complex sites and I now try hard to limit the number of stacks inside stacks and add more code where in the past I would have thrown a stack in.

It appears to be worse using a lot of stacks that don’t use Child stacks, on a page.

At least it’s good to hear that others are experiencing the same. I think we might have to reconsider how we are using stacks. My impression is that people tend to rather use a stack if they want to achieve one particular thing rather than adding a line of CSS and addressing the element with that. But an additional stack always brings more HTML, more JS and makes everything more bulky.
Do we need an additional stack to add styling or positioning commands to an element??
I would like every stack to come with a field for class names and IDs so that each single stack can be addressed. That, together with a well-sorted library of CSS commands, could serve us better. What do you think?

Markus Frieauff
Hinter Sundheim 12
55283 Nierstein
Tel. 06133 / 70 19 678

info@frieauff.com
mobil 0163 / 888 94 86

[quote=“therealmf, post:5, topic:14208”]
I would like every stack to come with a field for class names and IDs so that each single stack can be addressed.[/quote]

I completely agree but most stacks that already exist don’t do this, so an extra stack is required to add the Class or ID!

Some developers have been very focused on reducing code and improving efficiency on the published page which is much appreciated and best practice, but it is the Page loading, editing and previewing of large pages that needs a vast overhaul.

I believe that competing Apps such as Bocs App and Bootstrap Studio are taking the right approach by allowing users to build at a Block of page code level instead of the granular stacks building level. E.G they both allow pre built layouts with media populated components with all settings done in one section of code and consequently, they are lightening fast to preview & publish.

Looking forward to what RW8 will be, but I think it needs a lot of work to address the slow edit process.

I notice this too, also I discovered that going off line speeds up preview. If Im using a stack that doesn’t need to load code or fonts its much faster to preview…