"Lets have a tinybrowser like thing to target that will run inside the browser and output to it as if it was a GPU" is truly one of those its-so-crazy-it-just-might-work ideas.
I'm a tad miffed about the size (70KB), but then again it is smaller than Angular.
I took a wait-and-see attitude with Angular/Ember/Meteor/Yet-another-Express, they are all neat in a way but never completely shoo away the feeling that the whole Javascript MVC thing is some sort of programming Vietnam.
The OP is totally different and alien and actually gives me hope! Hurrah! Exciting times.
Excellent :) I do caution people getting too deep into Om at this point, some details may change over the next couple of months and I've got a few big ideas coming as well.
Writing this felt really good. This is been the first time writing CLJS in which dom manipulation wasn't a primary concern (to the point of distraction from application logic).
This is awesome work. Really looking forward to seeing where you take it.
Know of any resources of using clojurescript + react without Om (while we wait for more awesome)? Would the idea be calling setState from an atom's watch and transforming the map to a javascript object?
As someone who is having a hard time wrapping my head around the syntax of ClojureScript with its terse variables and so on, I really appreciate that the author took the time to make this so readable.
so... React in clojurescript is great. the other bindings i have seen are pump [1], but as i'm new to lisp/clojurescript i struggled with some of the parallels. a tutorial comes welcome.
somewhat aside- am i crazy for thinking React should bundle some sort of internal style processor? having your template and and your logic in the same place, in the same language, (cljs + react) seems to transcend the dirty feeling of template interpolation (Backbone muddies your JS with selectors. Angular muddies your HTML with directives and logic).
having your styles in the same place, in the same language, seems like next step to truly portable web components. probably lots of ways to do this wrong but probably at least one way to do it right.
maybe it's nice, but it's nice in the same way we've been separating HTML and JS for years, which React completely disregards.
if styles were solved in a similar way i think you'd be able to get rid of the notion of a selector all together (though it would compile down to normal selector based css).
also, components would just be easier to grok and more portable.
Until recently I would disagree that we should find a way to integrate styling into the application code, but I think you make a good point, that styling can be seen as one property of an application component, something that should be coherent with its structure+behavior.
As long as the styling code could remain simple to update independently of the business logic, it would be great to have it all part of the same internally-consistent dev system.
exactly! React helped me realize this point. another practical side effect of style as a property is being able to (sanely and safely) manipulate style based on state.
I see a recurring pattern in here! We all started seeing mixing markup, style and logic before 2000. Pre 2000 was ruled by functional programming and the decade before was ruled by procedual programming.
Then we rapidly started to "encapsulate", when OOP boomed. Now "packaging" is the main problem every programming language and OS has to solve. Today we end up implementing lightweight packages, so called components and we think it's a new idea to use statemachines to keep the interdependent component's state coherent. This idea was influenced by the boom of Interpred programming languages. Although 40 years ago, there were programs that only focused on allowing "components", which were "pluggable" modules back then, to be controlled by the DataFlow Pattern [1].
To formalize the main problem of the HTML,CSS and Javascript abstractions, blended into the DOM, we have to recognize that Data (Input) and UI (Output) are bound to States (Data Flows [2]). A solution to these problem is to use the FBP paradigm [3] in the browser engine and to implement the UI as an array of graphs. Usage of vectors allow the use of highly advanced mathematical solutions to be used to apply a optimization much easier than it is possible today, without rewriting the browser engine. For instance creating a UI now just means dragging and dropping items into a pane, which creates a matrix of number sequences that have relations to each other, yes basically a graph.
Because the UI and State is deterministic (except for Networks protocols!?), we can use the Knaster–Tarski theorem [4] to solve such DataFlow problems. Using Topological Data Analysis (TDA), we can even get deep level insight into UI & usage patterns that evolve and recur.
"Control of the language we use can be used to restrict our thinking. I find that this pattern is proving George Orwell's Newspeak [6] is similar to programming languages today.
What do I know, so please correct me when you think that there is no such pattern, or when you think something is wrong in what I said. So that others will profit from it.
>> To formalize the main problem of the HTML,CSS and Javascript abstractions, blended into the DOM, we have to recognize that Data (Input) and UI (Output) are bound to States (Data Flows [2]).
i can't see where CSS or style becomes relevant in the problem you are defining. but, as i understand, what you defined seems to be the principle behind React. no?
Yes, exactly. I just reflect about the thinking in react and propose that there is a pattern from past to today. Say that language controls our thinking and believe that TDA and Graph computation can solve these problems.
I would like to add that all of this is highly similar to AI and rebuilding our brains. Because those are also highly networked units that can topologically independently compute in parallel and in batches.
What all of this leads us to is compression or entropy and the moral of the story is that entropy is the function of state.
PS: It took me 2hours to remember the word Cliometrics. I usually cannot forget things, but when I do, I remember the beginning of a word. Which is totally frustrating, however I suddenly remembered it.
I can't see the parallels between js/html and css/html. React disregards the js/html because they acknowledge that there never really was proper separation. With css/html, at least to me, it seems like there is a clearer separation. Maybe I'm being shortsighted.
hah, I just wanted to post this! Dear catshirt, you were faster =)
I am really curious on the differences between om an pump, do you already have any practical experience with any of these, so you can share your insight?
tbh. I found out about pump, by reading the github issues in OM.
I know very little about React, so this might be a dumb question. I looked at the source for the example and it looks very nice, but I noticed the DOM is built using constructs like (dom/div ...). Is it also possible to use something akin to hiccup's syntax like [:div ...]?
I'm a tad miffed about the size (70KB), but then again it is smaller than Angular.
I took a wait-and-see attitude with Angular/Ember/Meteor/Yet-another-Express, they are all neat in a way but never completely shoo away the feeling that the whole Javascript MVC thing is some sort of programming Vietnam.
The OP is totally different and alien and actually gives me hope! Hurrah! Exciting times.