Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The React tutorial rewritten in Om

github.com

Post reply on HN
Print view View original

21–30 of 35 posts

Re: The React tutorial rewritten in Om

#21

Post by Robin_Message »

recuter wrote: post #7

"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 who…

Programming's Vietnam is supposedly object-relational mapping, although MVC does tend to be built on top of ORM so maybe the comparison is apt :) http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Compute...

Re: The React tutorial rewritten in Om

#23

Post by X4 »

catshirt wrote: post #6

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 o…

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.

Re: The React tutorial rewritten in Om

#25

Post by X4 »

CognitiveLens wrote: post #20
catshirt wrote: post #14

Earlier quoted context omitted.

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 i…

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.

--

[1] http://en.wikipedia.org/wiki/Dataflow_programming

[2] http://en.wikipedia.org/wiki/Dataflow

[3] http://en.wikipedia.org/wiki/Flow-based_programming

[4] http://en.wikipedia.org/wiki/Knaster%E2%80%93Tarski_theorem

[5] http://en.wikipedia.org/wiki/List_of_programming_languages_b...

[6] http://en.wikipedia.org/wiki/Newspeak

Re: The React tutorial rewritten in Om

#26

Post by jlehman »

swannodette wrote: post #3

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.

Re: The React tutorial rewritten in Om

#27

Post by catshirt »

X4 wrote: post #25
CognitiveLens wrote: post #20

Earlier quoted context omitted.

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 i…

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 a…

>> 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?

Re: The React tutorial rewritten in Om

#28

Post by X4 »

catshirt wrote: post #27
X4 wrote: post #25

Earlier quoted context omitted.

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 a…

>> 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.

Re: The React tutorial rewritten in Om

#29

Post by kenko »

bretthopper wrote: post #5
hueyp wrote: post #4

Earlier quoted context omitted.

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?

This was posted yesterday: https://github.com/holmsand/cloact

"cloact" is ... not a good name.

Re: The React tutorial rewritten in Om

#30

Post by lame_duck »

X4 wrote: post #25
CognitiveLens wrote: post #20

Earlier quoted context omitted.

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 i…

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 a…

Fascinating stuff, can you point me to somewhere where I could get more info about all of it?
Post reply on HN