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
parse an XML tree looking for parametric attributes, returning the so-called VirtualTree;
update the XML tree with new calculations.
I’d like to split the two steps into two separate libraries – a parser and a patcher. They’d communicate using a separately-versioned AST format. Many other low-level libs have gone this way and succeeded (http://npm.im/commonmark, http://npm.im/virtual-dom, http://mdast.js.org/).
We get lots of benefits:
👍 The parser can take any form of XML (for example, from a saved SVG file), generate an AST and pass it over to any other patcher (for example, a virtual-dom-based one).
👍 The AST can be precompiled and loaded separately as a JS file. That would radically boost performance for complicated stuff.
👍 The patcher can take an AST generated by another parser (for example, by some non-JS plugin for Inkscape).
👍 The API will be explicit, without overloading – easier to document and understand.
I see one tradeoff there however:
👎 The learning curve will be higher. Non-programmers (designers, makers, etc) probably won’t like the API.
Perhaps I’ll leave the API as it for now – and work on the parser and generator separately. When the low-level stuff is ready, I’ll wire it up with this lib. The API here will keep its implicit, jQuery-like spirit.
I’m still open to other ideas though!
The text was updated successfully, but these errors were encountered:
Right now the library does two things implicitly:
VirtualTree
;I’d like to split the two steps into two separate libraries – a parser and a patcher. They’d communicate using a separately-versioned AST format. Many other low-level libs have gone this way and succeeded (http://npm.im/commonmark, http://npm.im/virtual-dom, http://mdast.js.org/).
We get lots of benefits:
👍 The parser can take any form of XML (for example, from a saved SVG file), generate an AST and pass it over to any other patcher (for example, a virtual-dom-based one).
👍 The AST can be precompiled and loaded separately as a JS file. That would radically boost performance for complicated stuff.
👍 The patcher can take an AST generated by another parser (for example, by some non-JS plugin for Inkscape).
👍 The API will be explicit, without overloading – easier to document and understand.
I see one tradeoff there however:
👎 The learning curve will be higher. Non-programmers (designers, makers, etc) probably won’t like the API.
Perhaps I’ll leave the API as it for now – and work on the parser and generator separately. When the low-level stuff is ready, I’ll wire it up with this lib. The API here will keep its implicit, jQuery-like spirit.
I’m still open to other ideas though!
The text was updated successfully, but these errors were encountered: