Just run, baby!
XVG is a simple, desktop-oriented SPA that allows end users to draw Islamic geometric patterns via point-and-click usage of a mouse.
It has the look-and-feel of a native Windows 7-ish application, which ought to appeal to graphic designers familiar with the classic MS way of doing things.
The idea is you don’t want an end user to have spend too much time trying to figure how to use XVG, while making some of the SVG design innovations of the tool be as natural and familiar as possible to Windows users.
From an open source programming perspective, I also want XVG to be easy for anyone — especially newcomers to JS who are learning about Islamic geometry — to easily extend the app to suit their particular needs.
I also want XVG to be protected from malicious hacking.
Finally, I reckon most programmers would rather not have to figure out some more or less over sophisticated or cryptically terse or overly abstract or otherwise confusing piece of (uncommented) code.
For these reasons, I have decided to adhere to the following 12 application design and coding rules:
- No connection to the Internet, except in the embedded SVG workspace in the main layout html document, and at the top of the “dispatcher” JS module (which is loaded by the html doc), where it is required for subsequent SVG DOM manipulation to work*
- No CSS preprocessors
- Emphasis on combining structured analysis and design of the problem domain with early prototyping and subsequent refactoring
- Usage of latest ECMAScript functionality allowed, but only where there is a compelling technical rationale to do so — otherwise, plain JS is encouraged
- Optimized to Blink browser engines (Chrome, Edge, Opera, et al), due to a number of technical reasons (chief among them the availability of WebSQL as a storage engine)
- Usage of nested callbacks will be minimized and promises written as async/await functions
- Fancy and or showoff JS abstractions and/or patterns are to be avoided in order to emphasize code readability and maintainability
- Reliance on a custom dispatcher to funnel SVG and HTML event handling into 2 separate JS function files**
- XVG is almost stateless, in order to reduce complexity — thus, no “undo” for e.g. — except when it comes to keeping track of a limited number of event types (see Point 8)
- Persistence of user-created SVG designs is achieved via direct SQL statements sent to the browser’s WebSQL db. Since XVG does not expose its DB to Internet end uers, there is no needed for the tedious extra work that must be done to protect against SQL injections for apps that do.
- No frameworks, such as Vue, Angular etc
- No third-party JS libraries, or node.js
My hope is that adherence to these principles will allow me to efficiently develop XVG.
* the only connections to ze miracle of the Internet are here
deferThis Boolean attribute is set to indicate to a browser that the script is meant to be executed after the document has been parsed, but before firing
Scripts with the
defer attribute will prevent the
DOMContentLoaded event from firing until the script has loaded and finished evaluating.
# # #