For a change of pace, lets do something more practical.

I have little doubt that whatever solution I push for CRUD, it will be based on a language that behaves like SQL.

But SQL has a large share of issues, some coming from semantics, and some from syntax. This article will focus on syntax, and experiment with a few alternatives.

The SQL syntax has some well known problems, most of them common in commercial languages from the 80s:

• it's way too complex and inflexible

• it's way too verbose

• it's not composed of small blocks

• small blocks do not compose into large instructions

• the order it's written is inconsistent, doesn't match the semantics, doesn't work for partial program analysis, and allows for common and very harmful mistakes

• extending the semantics requires adding complexity to the syntax

So, let's try changing it and see what it becomes.

Continuing with the CRUD problem, the entire thing is data-oriented, right?

When you have important data, the most pressing requirement you usually have is to make sure it's correct. A process that checks this is called "data validation", and on the current systems it usually happen in several different stages, on several different places, with widely different capabilities, none of them complete.

Data validation comes on several different forms.

• It comes as types systems, where you declare your requirements and some standard piece of software checks them through all of your code; either at runtime or beforehand.

• It comes as custom verification you write on your data-handling code.

• It comes as post-fact verification, where reports and alerts tell people of some problem.

• It comes as your users calling support and yelling...

And yet, well except for that last format, all of that diversity hides the same kind of code running the same kind of checks.

Quite a few of the multitude of tiny problems one faces creating a CRUD come from the fact that the software is divided in layers. The modern implementations are universally composed of 3 layers, all run by different software, usually on different computers.

Let's call those that "data" layer, that runs in a RDBMS, "transformation" layer that runs in a web server, and "presentation" layer that runs in a web browser.

The separation of those 3 layers creates all sorts of integration problems, that forces people into writing the same code for each one of them. Worse yet, while the data layer affords a lot of requirement analysis (done before the fact), and the transformation layer affords a lot of code analysis (done after the fact), no software quality methodology is equally afforded by all 3, and most of that analysis is not extended to any other layer.

So, not only people have to write their code multiple times, there are very little know-how on ensuring that those copies are correct or even coherent with each other.

Writing CRUD should be really fast; that should bring no loss of flexibility; the work required should be close to proportional to the business complexity; expertize and competency should have a measurable impact on developer productivity all the way through.

Nowadays you can get one of those, and not more than one, some you can't get at all. This is the problem.

CRUD is supposed to be the simplest and most straight-forward kind of software one could write. All of the complexity should come from the requirements, and should be immediately visible from the outside.

Yet on practice those systems famously get very complex very quickly and all of that stops being true. Not to say about what pass around as modern practice, that makes software this way from the bare start.

That's a problem that has been bugging me for a long time. But if I try to do something about it, I actually don't know how to solve it. So I believe I'll gain something from cristalizing my understand of it first.

Well, I've got a less worse name for my site, that is now "Concept Coati". I really liked drawing that coati on the logo.

This is the third part of a multi-page article on an experiment to decide if I can migrate the designer front-end into rust and wasm.

On the first part, there is the motivation and also the creation of a hello world project. Also, the code we will migrate is presented there; it is a module that creates tabbed panels and lets them be assigned into containers.

On the second part there is a first attempt on migration and discussion of the problems it faces.

Now, we get the final form of that code.

This is the second part of a multi-page article on an experiment to decide if I can migrate the designer front-end into rust and wasm.

On the first part, there is the motivation and also the creation of a hello world project. Also, the code I will migrate is presented there; it is a module that creates tabbed panels and lets them be assigned into containers.

On the third part there are the conclusion and the final code.

Now, let's migrate that module.

Currently, the Designer is written in vanilla web languages.

That wasn't a conscious choice. Instead the current format of the editor is the consequences of a series of experiments on laying-out the desired interaction on a web page with modern browser features.

And my conclusion form those experiments is that the modern web is going in a pretty good direction!

CSS is getting great, and the DOM is quite expressive nowadays. Doing things in vanilla web tech has never been so easy... and I'll just leave JavaScript out of the conclusion.

I started those experiments expecting JavaScript to break at some point. As expected, it did, but in an unexpected way. Now that it is broken and I know how, it's time to fix things.

This is a multi-part article. Here at the first part we will get the problem description and a hello world wasm project working.

The second part has an attempted solution and the description of the problems found integrating Rust generated wasm with the DOM.

The third part has the conclusion and the final code.

The Designer is an entity-relationship model (ERM) viewer and editor, aimed at designing physical databases (only databases, and only physical). It is currently under development and will probably be the first component you can actually download from here and use.