Atom is very different from other things. The editor component is something that revolves almost entirely about state, and a huge amount of state at that.

I think the future is, like many abstractions, one where your tighter loops escape the abstraction (like numpy's C bindings). There's still advantages on a big-picture scale to using declarative frameworks like React

EDIT: one thing is that a text editor can know a lot better how to edit the DOM after an event (like hitting a character) than React's general algorithm

This is why I designed Glitch:

http://research.microsoft.com/apps/mobile/showpage.aspx?page...

Note that all the live editor examples in the essay are written in Glitch. Think of Glitch as a react like framework that focuses on fixing mutable state through time management rather than avoiding it.

I believe that the page you referenced to is broken. I.e. no videos or code samples on, see screenshot - http://snag.gy/lMAp8.jpg

Ugh...mobile link, this should work:

http://research.microsoft.com/en-us/people/smcdirm/managedti...

Hi Sean, having skimmed the presentation you linked to, Glitch's programming model seems similar to VHDL and Verilog, in that the "tick" is an explicit construct and statements are not guaranteed to execute sequentially.

I'm not experienced in VHDL, so I might be completely wrong here.

Did you take any design cues or inspiration from hardware design languages?

There is an inspiration from synchronous reactive languages, which are in turn inspired by hardware design (not sure if they predate or post date vhdl); you can read the related work section of the essay-linked conference paper if you are interested about lineage.

Glitch is a bit weirder in that all statements execute at the same time within a tick, their order isn't just unfixed: they are guaranteed to see all of each other's effects (except event handlers, which execute more hardware-like discretely to do state transitions).

After having watched so many frameworks come and go, the pattern I've noticed is that it's not just about hotness. It's that the new ideas that the frameworks provide push everyone else into better directions.

Everything becomes familiar. Then someone tries something new. Sometimes it works, sometimes it doesn't, sometimes it promises more than it can deliver. But all the folks who stick with familiar will take the reasons that people leave, and roll their own solutions.

Sometimes a fad framework really is a bust, but more often than not, it's always a stepping stone and motivation for every project out there.

They're using an approach that is absolutely inspired by React, for a use case that is inhospitable, pathalogical even, to a "generic web" approach to performance.

Choosing to not use React itself to implement the editing component of a text editor? Not a big deal at all.

This is not a solid "everyone moving away from React" example at all.

At least until something better comes along i am going with React. React makes lot easier and cleaner to build apps. I have built a stock ticker app with changing values and highlighting the change. Initially there were few performance issues, but using immutable data and shouldcomponentupdate those were resolved.

Haha, it was only a matter of time (measured in weeks) until React was over. The new hotness is evidently manually setting innerHTML.

Atom already wraps jQuery - they wrote their own DSL for mutating the DOM called space-pen[1]. They tried to get rid of it later (and rightfully so), but its too late now.

1. https://github.com/atom/space-pen

Given the huge feature gains in vanilla JS over the past few years (and in particular, the past year via ES6), I think we'll see more people shedding frameworks altogether. At least for the common tasks that were accomplished / made simpler by jQuery.

He's missing the point of Declarative vs Imperative and Virtual DOM vs Data Binding if he thinks it will circle back to jQuery.

The hype cycle is a well-known, predictable thing that happens to almost every new technology.