You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
Nick Matantsev
unframework
Hey, I'm Nick – I read books, work with software and play with hardware
Enterprise software models the real world of human activity, interaction, business transactions. Let's consider a typical person modeled by a run-of-the-mill e-commerce app. They'll have a few attributes (read: DB table columns):
first, last name
authentication credentials
shipping address
payment info (PayPal/Stripe token, billing address, etc)
Web-based UIs are hard to componentize into encapsulated widgets. DOM + CSS and the browser runtime have their roots in a document-based, progressive-rendering mentality, and that creates friction when attempting to develop components that don't step on each others' feet.
My ultimate starting point when dealing with encapsulation in-browser is to consider the runtime state produced by the combination of JS, DOM API and CSS behaviour.
In purest form, there are just JS objects that exist in memory of the browser and interact with each other via vanilla method calls and data access. The surface of encapsulation of a pure-Javascript component is just its public methods and properties.
When it comes to displaying things on screen, part of the widget component contract becomes rendering something visible in the browser viewport. Of course, we typically use DOM and CSS to do that (although Canvas-driven app UIs do exist). It makes sense to look at DOM and CSS as a sort of