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.