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
Copy file name to clipboardExpand all lines: resources/md/technical.md
+6-4Lines changed: 6 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -6,11 +6,11 @@ Modern web programming regards structure as being more important than content. A
6
6
7
7
By imposing structure we aim to reduce the opportunity for coding errors to be made. It's difficult to measure the success of this approach since to do so would mean creating a second version of the project that does not use a structural framework, then comparing the two to see which is better. Such a test is unlikely to take place for anything but a trivial project, so we have to take the word of the industry that their products are everything claimed for them.
8
8
9
-
At ~ec~ we do not take this as axiom, for the following reasons:
9
+
At ~ec~ we take issue with this assumption, for the following reasons:
10
10
11
11
1. Frameworks greatly add to the size of the code base, and a primary rule of programming is that the bigger the code, the more places there are for bugs to hide.
12
12
13
-
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. This relies more on learning the structure and less on thinking about problems and solutions.
13
+
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. This relies more on learning the structure and less on thinking about problems and solutions. 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 desigh choices, depending on the job being done and the skills available to construct it.
14
14
15
15
1. Frameworks are hard to learn and none last long before they are replaced by different frameworks. It is naive to believe that any of the current crop will still be preeminent in a decade's time. This is bad for projects that require intermittent maintenance over a long period, where skills are often not maintained in the organization. External contractors brought in to deal with updates do not have time to become fully familiar with the product, and overall integrity suffers.
16
16
@@ -20,9 +20,11 @@ At ~ec~ we do not take this as axiom, for the following reasons:
20
20
21
21
~ec~ operates without HTML or JavaScript. There's no virtual DOM; instead the language operates directly on the page. The package has its own compiler and runtime, which both run in the browser. Scripts are plain text files that are compiled on demand. This is very quick; the compiler will process about 20 lines of script per millisecond on an average laptop and take only little longer on a smartphone. Scripts tend to be fairly small, usually well under 1000 lines long. Initial page load times are usually under 2 seconds, depending on how much is needed in the initial page and how much can be deferred until after the page has rendered.
22
22
23
-
~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.
23
+
~ec~scripts describe functionality as seen by a user of the system. Aside from the DOM there are no structural features in the language. This may be a disadvantage for some types of project but ~ec~ is not intended to be a "one size fits all" solution; it's designed to be quick, effective and accessible by casual programmers.
24
24
25
-
~ec~ compiles script into an intermediate form; an array of objects, one for each step in the program. The runtime engine goes through the list, achieving respectable performance.
25
+
~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.
26
+
27
+
~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, achieving respectable performance.
26
28
27
29
~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.
0 commit comments