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

“Implement text editor DOM updates manually instead of via React”

github.com

Post reply on HN
Print view View original

111–120 of 225 posts

Re: “Implement text editor DOM updates manually instead of via React”

#111

Post by unfamiliar »

methyl wrote: post #104
shurcooL wrote: post #29

Meanwhile, a new Sublime Text 3 Dev build today added enhancements to its minihtml module. It looks like a race of whether Atom can become ST3 faster than ST3 can become Atom. The main competitive advantage that Atom has over ST3, IMO, is that it's open source. If Sublime Text 3 were to become open source, that would be a huge win. Also, that open source ST3 clone limetext [1] written in Go seems to be making progres…

Can you add something more about what is the minihtml module? Google says nothing.

I came here wondering the same thing. Based on the comments above, and what I know of the two editors, and the fact that there were some improvements to minihtml and suddenly today the sublime text changelog popped in HTML format, I would guess that minihtml is a light html renderer that can be used by plugins inside of sublime text. Atom already has this ability by design, so it can do things like draw a usage graph in a side panel, while previously sublime text could only have text-based panels produced by plugins. If I am correct, minihtml should allow plugins to display more complex user interfaces and data through the a minihtml pane.

Re: “Implement text editor DOM updates manually instead of via React”

#113

Post by jessaustin »

PlzSnow wrote: post #94
aikah wrote: post #91

Earlier quoted context omitted.

> I enjoy seeing the latest fad being burned at the stake as much as the next guy You're talking about a project developed in Coffeescript. > I think their technical choice of going for Javascript will be their ultimate downfall, This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.

Why have "acceptable" performance, when I can have "stunning" performance (Sublime Text). I am a professional, and my tools should reflect this.

I am a professional, and my tools should reflect this.

Then why aren't you using vim or emacs? b^)

Re: “Implement text editor DOM updates manually instead of via React”

#115

Post by jordwalke »

seanmcdirmid wrote: post #99
jordwalke wrote: post #76

Earlier quoted context omitted.

It's a great question. All of this (immutability) only makes sense to even attempt if you believe that immutability is easier to reason about than mutability. If we don't agree there, then I have nothing more to add really. But assuming we agree, then there is the question of performance. In most applications, we have three tiers of time durations. Tier One: During an interaction/animation you must update the screen…

> All of this (immutability) only makes sense to even attempt if you believe that immutability is easier to reason about than mutability. If we don't agree there, then I have nothing more to add really. Ok, that makes a lot of sense. I spend a lot of time trying to make mutability easy to reason about (my research), so I agree on the problems but disagree on solution strategies (fixing mutability with managed time vs…

Ah, it's good to know we have an ally against a common foe and I respect that you're taking a different approach (I suspect you'd be interested in Mezzo). I'd really encourage you to try out React though. It's different than other FRP type systems because the granularity of "reactivity" is much larger (at the component level) which means the majority of your code executes on plain data structures such as arrays and objects. There's no need to continuously be lifting your data into some "reactive" data container. For example, if you have two numbers that are changing over time, if you want to add them, you use the + operator instead of creating some kind of "ReactivePlus" operator.

Also, in some types of apps, when you have many of these point to point bindings wired up, the bookkeeping of them can start to add up too, especially when everything ends up changing any time anything small changes. This hurts two cases predominantly: 1. Your initial rendering of the UI. You usually have to set up these point to point bindings. It would be faster to not have to when blocking the initial user experience (which is critical). 2. When small changes end up rerendering the entire page anyways. This is the worst time to be slow because you already have so much to do! If some small imperceivable delay becomes a medium imperceivable delay, it's not so bad. But when the entire scene changes all the time, a framework like React that anticipates this can cut right to the chase and do the rerendering without also having to do the bookkeeping along the way. Different apps will have different sweet spots in different paradigms. I will say that it's worked out well for us at Facebook/Instagram and many other serious production apps (not just simple examples). I'd encourage you to try it out and give us more feedback since you've done so much research in this area.

Re: “Implement text editor DOM updates manually instead of via React”

#116

Post by Morgawr »

PlzSnow wrote: post #94
aikah wrote: post #91

Earlier quoted context omitted.

> I enjoy seeing the latest fad being burned at the stake as much as the next guy You're talking about a project developed in Coffeescript. > I think their technical choice of going for Javascript will be their ultimate downfall, This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.

Why have "acceptable" performance, when I can have "stunning" performance (Sublime Text). I am a professional, and my tools should reflect this.

Why have "stunning" performance when you can have "incredibly groundbreaking" performance (vim, emacs)?

Re: “Implement text editor DOM updates manually instead of via React”

#118

Post by seanmcdirmid »

jordwalke wrote: post #115
seanmcdirmid wrote: post #99

Earlier quoted context omitted.

> All of this (immutability) only makes sense to even attempt if you believe that immutability is easier to reason about than mutability. If we don't agree there, then I have nothing more to add really. Ok, that makes a lot of sense. I spend a lot of time trying to make mutability easy to reason about (my research), so I agree on the problems but disagree on solution strategies (fixing mutability with managed time vs…

Ah, it's good to know we have an ally against a common foe and I respect that you're taking a different approach (I suspect you'd be interested in Mezzo). I'd really encourage you to try out React though. It's different than other FRP type systems because the granularity of "reactivity" is much larger (at the component level) which means the majority of your code executes on plain data structures such as arrays and o…

When I was working in a design studio, I wrote a framework called Bling that auto lifts WPF dependency property animation/data binding for C#:

http://bling.codeplex.com/

So you could write something like:

    w.Right.Bind = v.Left + k.Width
and it would compile that into a continuous data binding expression (auto lifting was also useful for defining shaders in C#, they use similar techniques in JS/WebGL). But you are absolutely right: the book keeping was too much, and if you had say a chart with 100x100 cells each individually bound, your startup time would really suck. Glitch (my current work) has a much lower cost per state read (where you install listeners), and, like React, does not require lifted operations: so you read some state into values, operate on some values, and store the values in some state somewhere else. Each read is traced as it happens, each write is logged as it occurs, everything in between is just normal code; no lifting is necessary (I think React is like that for reads and doesn't allow for state writes outside of DOM updates that appear immutable).

The only question now is about granularity, and that is completely tweakable. There are some issues with state cycles, which have to be rejected (otherwise, non-monotonic changes might not work correctly in an incremental context), and keeping state separate helps prevent "false" cycles from occurring, but I'm looking at ways to separate cycle detection with state update granularity, and anyways, none of that applies to React since writes aren't handled in the framework.

What I'm interested in is expressiveness; as a PL person I have a cliche benchmark: can you implement a compiler in React? A compiler, after all, is just a "view" of flat text into some other form (e.g. a typed AST that can be used as a model in a language-aware editor). For React, I think the symbol table would stop you (everything else in a compiler is pretty much functional), but I might be wrong.

I'm definitely interested in React and will keep looking at it. Unfortunately, I don't do any web work so finding a proper context is hard.

Re: “Implement text editor DOM updates manually instead of via React”

#119

Post by mrkipling »

crazychrome wrote: post #105
vbit wrote: post #40

Earlier quoted context omitted.

Just curious - why replace vim or emacs?

emacs doesn't have decent support of jsx: the jsx-mode is actually for another tech with same name, the js2-mode is great except xml support. i love vim a lot (use evil in emacs), except vimscript. I hope oneday I could use neovim with atom/st2 as frontend.

I use web-mode to edit JSX. It's not bad at all actually - the indentation and highlighting are there. I've started using web-mode for its intended purpose, too (when editing templates that have CSS and JS snippets).

Re: “Implement text editor DOM updates manually instead of via React”

#120

Post by elinchrome »

PlzSnow wrote: post #94
aikah wrote: post #91

Earlier quoted context omitted.

> I enjoy seeing the latest fad being burned at the stake as much as the next guy You're talking about a project developed in Coffeescript. > I think their technical choice of going for Javascript will be their ultimate downfall, This is debatable. Editors like cloud9 have acceptable performances and webtechs allow one to distribute software right in the browser,which fits a huge number of use cases.

Why have "acceptable" performance, when I can have "stunning" performance (Sublime Text). I am a professional, and my tools should reflect this.

Isn't the main complaint about sublime that it's slow once you add enough plug-ins to make it useful?
Post reply on HN