Hello! Author here. When I say absolute positioning, I mean it in the CSS sense (as in position: absolute) to contrast it with CSS Normal Flow, Flexbox, Grid, Floats etc.
While it's true that SVG allows percent positioning and foreignObject with HTML inside, this does not help us for the task at hand: Positioning shapes/text in relation to other shapes/text. This is out of scope for SVG to my knowledge, while it's the natural domain of CSS.
Almost all of our charts have text labels of different size. In many charts, we measure the text with measureText() on a canvas first, then compute the SVG positions manually. Or we have HTML/SVG hybrids where we measure the text using getBoundingClientRect(). This two-stage measure/layout process is what we seek to reduce.
Hi, I’m Mathias, the author of the linked article.
Jeremy, I think we’re on the same page. Only the individual developers are able to decide about an appropriate app architecture. My goal is to help people make these informed decisions. I’m saying that devs should learn from others who have dealt with the same problems before – and found different solutions.
What you are calling malarkey is just my professional experience from 2+ years of developing Backbone apps that have 10K-20K LOC, as well as giving Backbone consulting to startups and mid-size companies.
I’ve seen the codebase of several “plain” Backbone apps. All of them faced specific, but also common problems and solved them by putting layers on top of Backbone. Some of these layers were well-engineered, some of these were horrible. The idea of Marionette and Chaplin is to put the best practices in modular code. Let’s face it, there are probably more Backbone apps than good JavaScript application architects.
Following the paths that Marionette and Chaplin have chosen “isn’t always wise” – there’s no doubt on that. It’s the philosophy of Marionette that you should pick those parts you find valuable for your app. And even in Chaplin you’re free to break all rules if you know what you’re doing. A lot of Chaplin users are doing this, which is fine.
> hiding and showing different parts of your app with simple CSS classes is usually less complex and faster (…)
If that suits your app, full ACK. There are a lot of apps where this makes more sense.
> That pre-fab "ListViews" are often nice for simple cases, but fall down when you want to do something truly custom and high-performance.
Marionette’s CompositeView and Chaplin’s CollectionView aren’t only for simple cases. Of course, an abstraction library can’t cover custom, high-performance lists. We’re not even trying. That’s what we’re telling our users: If you want high performance, you need to get rid of the convenience layer and operate on a lower level.
> That throwing away all of your models and views by default … is actually the opposite of the approach you normally want to take
Chaplin does not say that you should throw away everything. If you can reuse objects to speed up your app, you should do so.
Chaplin wants you to think about object persistence and object disposal. Chaplin provides means for both. In Chaplin, you can mark objects explicitly as reusable. That’s a safe approach to memory management AFAICS.
Backbone surely has good parts we were able to use right away: the event-driven concept in general (the Backbone.Events mixin), the Model with its attributes and change events, the View with its conventions (element reference, the Render pattern, free templating). Even if we couldn’t use all parts of Backbone it was a good idea to built upon the Backbone code and these common practices.
We dropped the Backbone.Router completely, but Backbone.History in turn is quite decent for HTML5 history and hashchange handling, so we’re relying on that.
Of course we could have borrowed only the code from Backbone we might need, but I think in the long run it’s a good idea to build upon an existing library or framework which is actively maintained, even if it doesn’t provide everything you might need at the moment. So writing all code ourselves wasn’t really an option for us.
While it's true that SVG allows percent positioning and foreignObject with HTML inside, this does not help us for the task at hand: Positioning shapes/text in relation to other shapes/text. This is out of scope for SVG to my knowledge, while it's the natural domain of CSS.
Almost all of our charts have text labels of different size. In many charts, we measure the text with measureText() on a canvas first, then compute the SVG positions manually. Or we have HTML/SVG hybrids where we measure the text using getBoundingClientRect(). This two-stage measure/layout process is what we seek to reduce.