Merge pull request #9 from easycoder/dev

Doc update

Author: easycoder

resources/md/technical.md

@@ -8,7 +8,7 @@ By imposing structure we aim to reduce the opportunity for coding errors to be m
 
 At ~ec~ we take issue with this claim, for the following reasons:
 
-1. Frameworks reduce the scope for ingenuity, seeking to eliminate errors from the outset by reducing all programming effort to a simple process of following rules that relies more on learning the structure than on thinking about problems and solutions.
+1. Frameworks reduce the scope for ingenuity, seeking to eliminate errors from the outset by reducing all programming effort to a simple process of following rules that relies more on learning the structure than on thinking about problems and solutions. We consider the benefit to be marginal at best and the approach to result in sites that are harder to maintain as the structure is not always easy to see.
 
 1. Rather than imposing a straitjacket on developers, large monolithic systems should wherever possible be broken down into smaller units that work in cooperation with each other and are maintained independently - the classic "black box" approach. Each unit can use different design choices, depending on the job being done and the skills available to construct it.
 
@@ -24,10 +24,10 @@ At ~ec~ we take issue with this claim, for the following reasons:
 
 ~ec~ is modular and pluggable. It is composed of a core set of JavaScript files totalling less than 250k bytes, with additional plugins that provide special functionality. Many projects will need no more than the core set, which provides basic language features, DOM manipulation, JSON and REST features. Plugins are available for text editors, Google Maps, markdown processing and more. In this respect ~ec~ is itself a framework, albeit one that emphasises language rather than structure.
 
-~ec~ compiles script into an intermediate form; an array of objects, one for each step in the program. The runtime engine goes through the array item by item and achieves respectable performance.
+~ec~ compiles script into an intermediate form; an array of objects, one for each step in the program. The runtime engine goes through the array item by item and achieves respectable performance. This all happens in the browser, unseen by visitors to the web page.
 
 ~ec~ is highly customizable. If the supplied functionality is insufficient, a plugin module can be written to provide missing features or to make existing ones run faster. Plugin programming is straightforward; it comprises code to handle the additional syntax and to wrap the algorithms used at runtime. Google Maps is a good example; it has a simple API that is well suited to being implemented as an ~ec~ plugin, and the source JavaScript of the plugin, comprising compiler and runtime, is only 560 lines long.
 
-~ec~ does not use any third-party libraries for its core code, so its behavior can be relied upon not to change. Some plugins make use of code from CDN libraries so we cannot offer any guarantees in that respect, but all the ~ec~ files are available as Open Source here on GitHub.
+~ec~ does not use any third-party libraries for its core code, so its behavior can be relied upon not to change as a rsult of updates to such libraries. Some of our plugins make use of code from CDN libraries so we cannot offer any guarantees in that respect, but all the ~ec~ files are available as Open Source here on GitHub.
 
 A website bult with ~ec~ can be maintained by any competent programmer without needing high-level skills in specific languages or frameworks. This lowers the overall cost of ownership and helps extend the useful life span of the product.