Here’s the latest report from the futuristic, upcoming world of Apostrophe 3.x development:
https://medium.com/@apostrophecms/apostrophecms-3-0-sprint-2-we-sure-do-like-magic-3743d96f0a23
For those new to the party: 3.x is due early in 2019, but support for 2.x will continue for years to come, and we are starting projects on 2.x every day. And many of our “enterprise” modules like apostrophe-workflow will take time to port after 3.x appears. So don’t wait.
Excited to see what comes out of sprint 3! One thing I would love to see is less polution of the DOM with editor related wrappers in areas, and the bump in major version number offers an opportunity to change the DOM structure there.
I suppose one of the reasons for the extra DOM wrappers is the need to position editor controls next to widgets on the page. Assuming that there’s no intent of changing the UX for editors by moving widget controls elsewhere on the page, I think the following naive solution could work well: the position of a widget is read on hover, and the controls are then simply appended to document.body as opposed to the widget itself. Vue could be helpful here by somehow letting widgets reference which button components should be injected into each particular widget’s toolbar.
For front-end developers, I know it would make a big difference to be more in control of templates by having fewer unintended DOM nodes.
Fredrik, this is great feedback. We’ve gone back and forth on this many times over the years.
It has indeed been a goal to minimize the impact of Apostrophe on the DOM. However we run into some realities. If a widget has no content or the content isn’t very tall we can’t fit the buttons; we have to add height to that widget. If a widget is a rich text widget, we have to create some space to accommodate both reading the text (or clicking into it to edit it) and accessing the buttons for the widget. Etc. Drag and drop operations, as well as widget players, at a minimum need to be able to find a container element for the widget as a whole.
There is also the challenge of repositioning controls if the widget gets moved - allowing it to actually be in the DOM is certainly simpler and feels less “jumpy” than javascript trying to keep them together as a widget is dragged.
But, having the controls nest in the widget has all sorts of implications as you’ve pointed out. This is worth another rethink for 3.x.
I will ask others to chime in on this thread as well.
It makes sense that Apostrophe has some base requirements for areas and widgets. An empty area needs to occupy space, as you say. Rich text editors need a min-width and min-height. But without having delved too deep into it, I think those demands can be rather easily met with a single wrapper for areas and widgets respectively.
I also pondered the potential issue of having to move toolbars around if widgets move, but in reality it seems like a rare scenario to have widgets that move around the page as the editor tries to click the toolbar buttons for that widget (slideshows with nested widgets seem like one exception, though). Don’t get me wrong, some slow polling could still be useful, but when weighing the benefits of fewer DOM wrappers against the problems of polling widget positions, it seems like fewer DOM wrappers would win.
Eager to hear if there are any further reports from work on 3.x? 
Hey Fredrik, sorry for the lack of updates on that subject. Our frontend team has had the most recent 3.x sprints and I’ve asked them to post an update.
For updates that are a little older but sound like they may still be new to you: