About

toad.js is for building desktop applications on top of modern web technologies with a TypeScript transpiler and a browser being the only dependencies.

With desktop applications refering to:

• complex domain data with a significant amount of coupling
• large screen, mouse and scroll wheel ⇒ support for mobile devices is not a priority
• pro users ⇒ no eye candy, all apps have the same look

For this toad.js provides a toolbox for design patterns like

• Layered Architecture (DDD),
• Presenters and Humble Objects (Clean Architecture),
• Presentation Model (Martin Fowler),
• Application Model (VisualWorks) and
• good ol' MVC. 😁

While this pattern slices an application horizontally (e.g. presentation, application, domain), some believe it to be obsolete and replaced by vertical slices (e.g. customer, article, payment, ...). This, of course, depends. When vertical slices remain too wide because of the coupling imposed by the domain there is still the option to do both.

Layered Architecture

Layer names are in the order of DDD / Clean Architecture:

About me

I've been developing applications on top of my own user interface libraries since OWL in 1991, always trying to look at how other frameworks worked. With one exception: SmallTalk. While most SmallTalk systems didn't age well, ideas like live coding or user programmable computers still look like something from the future.

The C++ version of TOAD began in 1995 after having worked with OSF/Motif when I realized that

• an ugly user interface framework will most likely result in an ugly user experience
• there is nothing more annoying than being forced to write lots of boilerplate code
• user interface creation should be interactive

Besides the C++ versions of TOAD on top of Java AWT, Fresco, macOS, Windows and X11 and it being the subject of my diploma thesis, toad.js also builds on almost two decades as architect of the Phoenix Contact mGuard's frontend, whose device independent application layer is able to serve CLI, SNMP and Web interfaces and which made UI development an absolute no-brainer.

Development is happening in my spare time and focused on the desktop version of Safari to support the development of workflow and makehuman.js.

*) You may recognise that the above accumulates into a pattern known as Model-View-Controller (MVC), which, undeservedly, got a somewhat bad reputation during recent years. So let's set the record straight:

• MVC in a nutshell:

  • We can solve any problem by introducing an extra level of indirection. Fundamental Theorem of Software Engineering
  • Model means a model of something, e.g. a shopping cart, inside the computer, consiting of data and behaviour.
  • View means a visual representation of that model to the user. E.g. a number might be represented by a text field and a slider.
  • MVC means to keep View and Model separate. (Think Flux, Redux, MobX, ...)
  • MVVM means to further separate the Model into an application independent domain part and an application relevant part.

• The MVC you see in Ruby on Rails or Spring Boot are not MVC. The correct name is JSP model 2.

• Forget about the Controller in MVC. The Controller is an aspect of SmallTalk to insert the view into the system's message distribution. In contemporary systems they can be considered as part of the View.

• The true leverage of MVC/MVVM does not come from the pattern itself, but the vast collection of prefabricated Views and ViewModels from which you can assemble your application.

  It should support forms with input validation including dependencies between different values; arbitrary sized tables which can be edited, resized, sorted and filtered; arithmetic in numerical fields; undo/redo, etc.

• Most MVC/MVVM frameworks are overcomplicated while lacking an adequate collection of Views and ViewModels.

• What Facebook's React team got wrong about MVC:

  • Let’s look at what happens to this [MVC] diagram when we add a lot of models and when we add a lot of views to the system. There's just an explosion of arrows. Hacker Way: Rethinking Web App Development at Facebook 10:49

    What the React team shows here is NOT MVC.

  • And if you just look at these arrows, can you tell if there's an infinite loop here? Where, you know, the model triggers something in the view and the view triggers something in a different model. It goes in a cycle. It’s really hard to tell just by looking at this Hacker Way: Rethinking Web App Development at Facebook 10:49

    This does NOT happen in MVC. The View changes the Model only on user input. An infinite loop of this kind can still happen in both MVC and React/Flux when the View does not adhere to this rule.

    Infinite loops may happen in the application layer, e.g. when a RGB triple sets a HSV triple which in turn wants to set the RGB triple again and variation in floating point calculation results in an endless loop. Explicit locks or implicit locks in the model are a means to get rid of these kinds of loops.

  • So we want to do away with all of this. We want, what we propose instead, is something called FLUX. Hacker Way: Rethinking Web App Development at Facebook 11:40

    FLUX is a rebranded MVC: Action = Message, Store = Model, Dispatcher = Event Loop, View = View.

  • It’s a single directional data flow. Em, and that avoids all of the double arrows that are going, that go in both directions, that make it really hard to understand the system. Hacker Way: Rethinking Web App Development at Facebook 11:45

    Same as in MVC. Still, both go around in a circle, so both are still bi-directional.

Development

How to run single test files:

npm run dev:build

npm run dev:test --file=lib/test/view/ToolButton.spec.js

References