pickle-ts

Interestingly, in a very early version classes were allowed to be expressed as arrays of strings just like you had, but in the vast majority of cases a space delimited string worked fine, so this feature was dropped for simplicity/uniformity.

Example code:

    div ({ class: "form-group" },   
      label ({ for: "exampleFormControlSelect1" }, "Example select"),  
      select ({ class: "form-control", id: "exampleFormControlSelect1" },   
        option ("1"),  
        option ("2"),  
        option ("3"),  
        option ("4"),  
        option ("5")  
      )  
    )  

The arguments against this approach usually boil down to the mistaken notion that "you're not separating concerns". The response is: separation of language != separation of concerns. No matter what you should still strive to reduce cyclomatic complexity. So you're still separating model, view, themes etc. And you're doing so using abstractions within the language, rather than relying on language and file boundaries. Notably in the reverse case, when you have unavoidable links between these layers (since no useful abstraction isn't leaky), the benefits of expressing everything in one language are considerable (e.g. when refactoring).

Live: https://deep-learning.stackblitz.io/

Live edit code: https://stackblitz.com/edit/deep-learning

Note the inclusion of a state management library for an apples-to-apples comparison, since Solenya has intrinsic state management. Also note that I'm firmly NOT in the "all you need is the V in MVC" camp. Dealing with state is one of the trickiest aspects of writing scalable code that I've sought to address. There's an excellent video that discusses state management in large applications here (in the context of Angular, but the principles apply generally): https://www.youtube.com/watch?v=eBLTz8QRg4Q

My goal has been to deal with these issues in a way that works for both small and big apps. Previously, I dreaded having to make the decision at the start of an app: "is this app complex enough that I have to pay the tax of using a state manager?", where there's two very different ways of writing the application and I had to cross my fingers whether I'd made the right choice. The solution to this dilemma with Solenya, has been to make the tax of having state management so low that it's always on, whether the application is big or small.

Main page w/ links to other resources: https://www.solenya.org/

Fun example app built w/ solenya: deep learning to recognize digits in your browser: https://www.solenya.org/deep-learning

Real world app built w/ solenya: code music in your browser: https://www.motifn.com/

To quote Erik Meijer - the godfather of observables - in this article https://queue.acm.org/detail.cfm?id=2169076

There are many ways to derive Rx, some involving category theory and appealing to mathematical duality, but this article shows how every developer could have invented Rx by crossing the standard JDK (Java Development Kit) Future<T> interface with the GWT (Google Web Toolkit) AsyncCallBack<T> interface to create the pair of interfaces IObservable<T> and IObserver<T> that model asynchronous data streams with values of type T.

No, I was using cycle state/onionify.

[cycle-js] is not a competitor to React

That's not the impression you give in this article: https://staltz.com/some-problems-with-react-redux.html

React may be superior in ecosystem, or with feature coverage, but not so as a paradigm [compared to cycle-js]... Once you learn Elm or Cycle, getting things done will be more productive, less indirect, less verbose, more organized.

Am I quoting you fairly? Have you changed your position?

Central to the understanding of cycle.js is the concept of observables. An observable is powerful abstraction, as it allows event streams to be programmable. However, an overreached abstraction can be even worse than a lack of abstraction. Cycle.js gratuitously applies the observable abstraction to its component model.

The cycle.js notion of a component is a object that takes multiple observable sources, and emits multiple observable sinks. I have to admit, at first I didn't see this as problematic: to the contrary - it actually struck me as elegant. What I didn't realize, before building a real-world project with cycle, was that this meant all interactions between components were asynchronous. So each component cannot even access the state of another component without communication via observables. This introduces enormous needless complexity into an application. Not only do you have to pay an up front mandatory boilerplate tax to minimally wire together your components, you'll tie yourself in knots readjusting that wiring to get those components to communicate with each other in the way you need.

We actually ended up re-writing the project with our own framework, pickle: https://github.com/pickle-ts/pickle For us, this substantially increased maintainability / reduced the code size of our application compared with cycle.js, or the prototype we wrote with react/redux. The code reduction came from realizing the appropriate abstraction: the entire application should be composed of an object-oriented hierarchy of stateful components, where on each update, these mutable components render themselves as immutable v-dom trees. Anyway, to counteract any pluggishness (our framework is obviously super new so is only of interest to ultra early-adopters), the conservative sensible choice for a web framework right now is to use react or vue /w a state manager. Not cycle.js.

http://pickle-ts.com/relativity

Source code you can play with live: https://stackblitz.com/edit/pickle-samples?file=app%2Frelati...