Elementree is really just an exercise in constraint. I am tired of spending my time in front-end framework documentation. I wanted something that didn't rely on odd templating syntax, proprietary data shapes, multitudes of library imports. Therefore I needed to create something where the entirety of the library could be held in my head, which I might note, hasn't had a memory upgrade in some time. I wanted a library to celebrate the code of the problem domain as opposed to the framework.
Why local view state?
Local state jives with my brain. I have never been fearful of encapsulating state with an object and subsequently mutating that state. I understand the pitfalls and I do my best to work around them when they present themselves. I view local state vs a system like flux/redux a lot like I view procedural vs functional programming. My brain works better with recipes than mathematics, just like it works better with state mutations than reducers.
Why Proxies?
Proxies gives Elementree objects the appearance of everyday JavaScript objects and yet perform specific semantics when mutated. This is just another case of doing my best to decrease the API foot-print, making the entire library easier to process and quickly be productive with.
Why not use a templating engine like lit-html?
I was exceptionally excited about lit-html when I originally saw it. But over time additional 'syntax' has made its way into the library for things like boolean attributes and event listeners. Don't get me wrong, the people working on that project have a whole lot more time and brains than I do, so I am sure it is for good reason. But I went with nanohtml because it didn't do anything special. It makes all Elementree's template look just like HTML with interpolated values. It is the right tool to meet the design goals of Elementree.
Elementree is really just an exercise in constraint. I am tired of spending my time in front-end framework documentation. I wanted something that didn't rely on odd templating syntax, proprietary data shapes, multitudes of library imports. Therefore I needed to create something where the entirety of the library could be held in my head, which I might note, hasn't had a memory upgrade in some time. I wanted a library to celebrate the code of the problem domain as opposed to the framework.
Why local view state?
Local state jives with my brain. I have never been fearful of encapsulating state with an object and subsequently mutating that state. I understand the pitfalls and I do my best to work around them when they present themselves. I view local state vs a system like flux/redux a lot like I view procedural vs functional programming. My brain works better with recipes than mathematics, just like it works better with state mutations than reducers.
Why Proxies?
Proxies gives Elementree objects the appearance of everyday JavaScript objects and yet perform specific semantics when mutated. This is just another case of doing my best to decrease the API foot-print, making the entire library easier to process and quickly be productive with.
Why not use a templating engine like lit-html?
I was exceptionally excited about lit-html when I originally saw it. But over time additional 'syntax' has made its way into the library for things like boolean attributes and event listeners. Don't get me wrong, the people working on that project have a whole lot more time and brains than I do, so I am sure it is for good reason. But I went with nanohtml because it didn't do anything special. It makes all Elementree's template look just like HTML with interpolated values. It is the right tool to meet the design goals of Elementree.