When I see the word 'signal based', I think of the message-passing, change notifying, object-oriented designs I write. Synchronous sounds nice but current computers are serial, Von Neumann machines. It can be emulated with multithreading and the Active Object design pattern but that's not quite the same. If that's near enough for the author, then he's advocating that I do what I'm already doing except I don't have a visual assembler of components and I use far fewer Active Objects on a serial computer.
Drag-and-drop, component oriented programming is somewhere near possible for desktop GUIs but don't expect reliability and performance from the end-users that fiddle with them. As for back-end servers, good luck finding much commonality.
The synchronous bit seems like a good idea and more hardware support is needed. A mini-CPU per object with its own, private area of main memory. As there will be more objects than mini-CPUs, barely used objects get dropped from the registers and replaced. Object swapping and locating will be fun and even funner with huge databases. Wonderful, parameter passing overhead as well, as opposed to the stacks of conventional programs. And don't forget this must be between all the objects in all programs as all processes are active.