brucou · HackerTrans

3 lata temudiscuss

I beg to differ here. Or let's say that the React "functional programming" model has very little to do with the actual functional programming done by actual functional programmers. What is true is that React components are functions. But functional programming and programming with functions are two different things.

Second, side effects are just about in every React component where you use a hook.

Third, (hypothesis) `useEffect` is probably a misnomer that stick there because it would be a breaking change to rename it to something more proper.

Words and bickering aside, you can write great applications with React, that's fact. It is also a fact that a lot of folks are using it wrong, which shows either a problem with React learnability itself, or with its documentation, or well, with the programmers themselves.

brucou

3 lata temudiscuss

Hi there. IMO, there are three issues there: familiarity, mental model, and caveats (using $ and not getting reactive updates in some cases).

Focusing on mental model, maybe my mental model can inspire yours? Here it goes.

- For me, `$: dependent variable = expression(independent variables)`, is an equation that Svelte guarantees will hold across the single-file component (SFC). So whenever an independent variable change, the dependent variable is also updated to maintained the equation. - Caveat: In the statement `$: dependent variable = expression(independent variables)`, the expression language is JavaScript but the semantics of the statement are Svelte's (i.e. *Svelte's* scoping rules apply, not JavaScript's). SvelteScript is so close from JavaScript that it feels intuitive to use but confusing when the two differ. In a poor analogy, just like using a word that means something in French, another in Spanish, and wrongly guessing the source language (hence the meaning) that applies.

Then: - `$: {some statements here featuring independent variables}`. *Svelte's* scoping rules apply (only the variables visible in the block are targeted by Svelte's reactivity). This is not an equation anymore, it is the expression of an effect triggered by change in dependent variables.

Why this is natural to me? At the specification level, reactive systems are specified with three core syntactic constructs:

1. event -> reaction 2. dependent variable = function (independent variable) 3. dependent variable <- function (independent variables)

The first item means is where you specify what happens when an event occurs. for instance button click -> (counter <- counter + 1; render new counter)

The second item is the same as lambda abstraction. Say `area = f(length, width)`. That's true all the time and allows using `area` everywhere needed instead of `f(length, width)`. But by referential equality rules, you could absolutely do away with `area` - at the expense of course of less clear and more verbose code (and probably less performant too)

The third item is assignment, and is used to describe changes in the state of the component. As a rule, (reaction, new state) = f(event, current state). So the third item describes how to get new state from current state. The first item describes how to get the reaction from the event and current state. The second item is optional but helps a lot readability, conciseness, and performance (not computing `area` twice if you use it twice).

In Svelte syntax: 1 is $: {reaction code here} (event is some change in value of variables scoped in the code) 1 bis: <some html code here> is the same case as 1 with a different syntax when the reaction is a (re)render. Whenever the dependent variables in scope change, a rerender reaction is executed. 2 is $: x = f(a,b,c,...) (Note that the right hand is a single variable name) 3 is any assignment occurring in the SFC.

Not sure if that helps, but well, that's how I stay away from the pitfalls of mixing SvelteScript and JavaScript. Identify events, state variables, the reaction to the events, and the state changes. Then translate that into SvelteScript.

brucou

5 lat temudiscuss

:-) I feel you. I like to think that state machines are used where they are useful (in some games, process orchestration, generators, embedded systems, etc.). The question is more where else can they be useful given that the low hanging fruits have already been harvested.

I am using state machines to write reactive applications: https://brucou.github.io/documentation/

So far I have to say that it is a mixed experience. There is a cost to the abstraction and the indirection (that is fairly well known easy to describe even if we rarely do so due to some self-imposed no-negativity bias or having some interest in the game), and then there are the benefits that are less easy to describe because they depend highly on the nature of the problem that you are addressing.

I implemented a Medium clone application (https://codebase.show/projects/realworld) with state machines. The result is 47Kb (brought down to 39Kb after compiling the machine and other optimizations) vs. 70Kb for the Vue implementation or 160 KB for the React/Redux one (that implementation piles abstraction over abstraction in the form of libraries and pays the corresponding price). I would count that as benefit. Also cf. https://brucou.github.io/documentation/v1/tutorials/index.ht... for the full pitch.

The high-level machine is that one: https://brucou.github.io/documentation/graphs/real-world/rea...

At this level, you can follow the routing of the app. Every route is a compound state. If you open it, you see the details of the behavior. The full machine (post refactoring) is like this: https://brucou.github.io/documentation/graphs/real-world/rea...

So one advantage is that with those graphs, it is easier to onboard new folks arriving to the codebase. They just have to follow arrows to know what the code is doing in response to a series of inputs.

I could continue but with all that said, the Hyperapp implementation of the same application is 27Kb and also fairly simple (even if arguably not as simple) to get into. So there isn't a clear-cut ex-nihilo benefits to state machines here. In fact if you would have implemented the same application as a MPA instead of a SPA, for most, if not all of the pages, using a state machine to model the behavior is simply overkill. Most of the job and value of the machine in my example is to do the client-side routing done in the machine (so no extra library cost).

Anyways the bottom line is the tool is useful but you have to figure for what, and where is the value maximized. The obvious cases have already been figured out.

brucou

5 lat temudiscuss

If we talk about professional use, then Powerpoint (many years ago), then Visio (also many years ago), then yEd (by yWorks, https://www.yworks.com/products/yed). Then there are a ton of specialized open-source tools, with varying quality. Mermaid improved a lot. PlantUML has a lot of options, but I would not use it professionally. draw.io has also plenty of options, but has some usability issues in the frame of a frequent, professional use.

For anything UML-related, Enterprise Architect is quite good, but boy you better know UML. That ain't user-friendly in the least. But super powerful and there are a few more like that out there with somewhat limited free versions.

Long story short, my best choice is yEd. And I still reach out to Powerpoint every now and then.

brucou

6 lat temudiscuss

I do agree with the thesis that nobody got fired for using React. I don't however think that the conclusion is to use React anywhere for anything.

From what I read here, what happened here is that this developer has good knowledge of React for having used it repeteadly in the past. At the same time, he did not have experience in lit or svelte. He hit some issues and then went back to the things he knows better. It is more comfortable and more productive, there is no doubt about that. The conclusion is more like, you will write your app faster in the language, environment, and framework that you already master. I agree with that. Change one of those, and you will go through some moments of loneliness. Change two of those, you may just fail the project entirely.

What is true, and proven by many data points, is that you can write complex applications with lit-html, svelte, elm or just vanilla-JS. GitHub is not a web graphics editor but it is entirely vanilla JS. Hum, po*n apparently use plenty of vanilla JS too (https://davidwalsh.name/pornhub-interview). IBM implemented their Carbon design system in Svelte. Adobe's adaptive color tool (https://leonardocolor.io/?colorKeys=%236fa7ff&base=ffffff&ra...) is entirely in vanilla-JS. The list is long.

So what we have here is one anecdote from one person. All data points issued from real experience are welcome, valid and useful but we should be careful to not get to conclusions too fast.

brucou

7 lat temudiscuss

State machines are a generic term. You will find here the different kinds of state machines, with varying expressive power that are used in computer science and actuak programming: https://github.com/achou11/state-machines

In any case, keep in mind that Turing machines are (extended) state machines (albeit with infinite memory) so the expressive power of state machine is at least anything computable (sequentially - turing machine is a model of sequential computation).

brucou

7 lat temudiscuss

I have been looking for that too and could not find much, at least not much that is available for free. That said, I give a series of example of miscellaneous complexity in Kingly documentation site (https://brucou.github.io/documentation/). Kingly is a state machine library that replicates pretty much the formalism of statechart, without its concurrency model (i.e. no parallel states). Interestingly the amazon book you quote is also recommending to make spare use of parallel states (if I remember well, it recommends to use it only at the top-level of the chart, and when possible not at all). Anyways, on the Kingly site, you will find the following examples: - a counter (yeah there is always a counter or hello world somewhere) - a keypad app (with Svelte) - a password meter (tells you if yuor password is strong enough) - a two-player chess game (with React) - an interface to an online movie database (with 7 different UI libraries, including Vue, React, Svelte, Ivi) - a wizard form (with cycle.js) - an implementation of suspense functionality (with Svelte) - an implementation of Conduit, a clone of Medium. Conduit is considered to be, like TodoMVC a benchmark of miscellaneous approaches to UI implementation, but for a real world complex application.

I also published an article on the subject on infoq: https://www.infoq.com/articles/robust-user-interfaces-with-s...

All of that may be useful to you, with the benefits that you won't have to make the examples, as I had to, to evaluate the applicability of the technique to UI implementation.

If there is anythign you do not understand let me know.

brucou

7 lat temudiscuss

That is one of the early papers by David Harel which divulgated statecharts among the scientific community. Note that since then, there has been a number of criticisms made about the original statecharts (namely the absence of precise semantics, and the concurrency model) and a number of variants have since seen the day. What seems to have remained in all variants is the concept of hierarchy. In the Kingly state machine library (https://github.com/brucou/kingly), I only use hierarchy and discard broadcast and concurrency. The latter two can be added at will according to the problem at hand.

brucou

7 lat temudiscuss

I find your thesis interesting (that agile ended the top-down design approach resulting from statecharts modeling). Do you have any references/links I can review to support it? It is true that agile seems antithetic to Big Design Up Front (http://www.agilemodeling.com/essays/bmuf.htm). However the methods did seem to have found commercial success (in safety-critical software) albeit not in front-end programming. I believe instead that the drivers of adoption/rejection are specific to the success factors in specific industries. That or maybe front-end programming is driven more by trial and error (+ hype?) than by engineering.

brucou

7 lat temudiscuss

Nice article!

I authored a javascript library which modelizes state machines as a multidigraph, use cartesian products to derive a standard flat graph, and generate test sequences out of it. Cf. https://github.com/brucou/state-transducer#generatetestseque... for the theory, here for the example : https://github.com/brucou/state-transducer#implementation-ex...

In conjunction with predicates, which tell you which edge you can explore, and when to stop a path search (a test sequence is a path), this gives a pretty flexible and configurable tool for automatic test generation, as you observed.

So far I preconfigured two search strategies, one which visits all transitions in the graph once, and the second which does the same but up to n visits of the same transition. I am working on more complex strategies (favor some paths over some others following a probability distribution etc.) but that is not a priority as of now.

Smart automated test generation is an exciting topic!

brucou

8 lat temudiscuss

This is interesting feedback. There are obviously subjective parts in it, but that's valuable all the same.

Focusing on the objective parts :

  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.

Some caveats aside, cyclejs allows you :

- to express your app as a series of equations

- separate side-effects from pure dataflow processing

Whether that is gratuitous or overreached is a question of taste, familiarity and other things, I won't discuss with you on that.

What I will say is that under some conditions, the cyclejs approach actually can make your application much easier to understand that standard imperative workflow processing. For instance, I could write for a super simplified reservation system :

- screen `=def=` booking_details_screen + booking_feedback_screen

- booking_feedback_screen `=def=` is_ok(booking_response) ? nothing : display_errors(booking_feedback_screen)

- booking_details_screen `=def=` whatever interface you want

- book_button_click `<-read_dom_effect-` = <provided by the DOM>

- flight `=def=` read_flight (booking_details_screen)

- booking_request `=def=` makeBookingRequest(flight) sampled by book_button_click

- booking_response `<-booking_effect-` booking_request

The `=def=` relations are equations which are always true. the `<-effect-` relations express the causal relation between asking for a request to be performed and the response resulting from that request.

On another note, as you can see from the equations, there is no notions of component. Or if you prefer a component is a variable on the leftside of the equations. So for instance screen is a component with two children components.

That is the underlying theory. In practice:

- code does not get written as a list of equations, but through doing some juggling with streams operators. Nothing of the other world really, but there is certainly a ceremony to it, and tips, tricks, gotchas to be aware of.

- Cycle actually does not have a component model stricto sensu. A component model should at least provide a systematic way to combine components into a hierarchy, i.e. a `combine` function by which `parentComponent` = combine(childrenComponents)`. For instance in React, `reactElement = React.createElement(parentComponent, props, childrenComponents)`. With `cyclejs` you must explicitly write your `combine` function yourself, everytime. That represent probably a portion of the pain you felt.

But conversely look at the other approach. Let's imagine a `ParentComponent` with two child components. To reason about your application, you need to know about the end-to-end sequence of operations involved in all the framework's API. So for instance: `render = render Parent -then-> call onRender of Parent -then-> render Child1 -then-> fetch data -then-> render Child2 -then-> etc.`. This is obviously possible, that is how React works and your own proposed framework too - by the way you do not offer a component model either, stricto sensu). Nothing of the other world really, but there is certainly a ceremony to it, and tips, tricks, gotchas to be aware of (yes I copy pasted from before).

So in short, your evaluation of how bad the ceremony is, the effort it involves etc. will obviously include factors which are specific to you. So I am not doubting your feedback. My whole point here is to say that your mileage may vary and that there is no a priori superiority of one approach over another (stuff like `realizing the appropriate abstraction` as you mention in your post). There are real pain points both ways and what is appropriate to you might be in part the result of a higher familiarity with one approach over another.

If you want to understand what I mean by component model, or want to see what a component model for cyclejs look like, I created my cyclejs component model to address some of the pain points you probably encountered : cf. https://brucou.github.io/posts/a-componentization-framework-...

comments