Let's choose a view framework for docs, generated packages, etc.

[thedaniel]

(This is an attempt to restate #3752, explain the current position and present options)

A blessed view system for Atom

We're in an interesting place with respect to generating views in packages and core. We wrote space-pen and used it heavily, but ultimately decided to discontinue using it for new views (though some base views still use space-pen we are no longer recommending it). So now we find ourselves in an unfortunate position of using the DOM APIs directly, and suggesting package authors do the same, choose a framework themselves, or ╮(. ❛ ᴗ ❛.)╭ - Not a great place to be, and makes it hard to write docs with nice examples.

We used React in the editor component for six months or so, and it was a good experience, but it has a bit of a learning curve.

We experimented with a few things inspired by React and Polymer, and have done some research on 3rd-party view frameworks, but haven't come to a decision. As we work on better docs for the run up to 1.0, we have to start taking this seriously.

Requirements

• Embrace modern browser features (custom elements, Object.observe, etc) as much as possible
• It absolutely does not pollute the global namespace
• Data-binding preferred to imperative updates if templates are used
• View model / MVVM-style separation of rendering and logic
• No dependencies on jQuery-like helper libs
• Small learning curve
  • somewhat self-explanatory when used in docs examples
  • in other words, most web developers will be able to recognize the concepts that are applied without reading a book on it

Contenders / experiments

• React
• Etch - a library for writing HTML-based view components that provides the convenience of a virtual DOM while at the same time striving to be minimal, interoperable, and explicit - written by @nathansobo and @maxbrunsfeld
• rivets for templating+data binding plus some basic JS object glue for Atom
• television - "Television aims to cleanly integrate the virtual DOM approach of React.js into HTML 5 custom elements." - an experiment from @nathansobo
• virtual-dom this library is used by television, but could be a component in a similar solution that accomplishes the above goals.
• elmer - An experiment from @benogle based on Polymer's template binding
• vue.js - simple, component-based, simple & small
• Something custom, delightful & new from your friends the Atom team (but we don't reallllly want to maintain another view frameowrk)

Want to help?

One way to help speed this along is to do some experimentation with using your favorite framework in a package. See https://github.com/benogle/template-explore as an example package using https://github.com/atom/elmer.

A couple questions I would try to answer with the package:

• How does it handle model/DOM updates? Data-binding? Imperative + virtual-dom like react?
• How does it handle events? i.e. How do I bind a click handler to an element?
• Can it work with Object.observe and not it's own model system?
• Does it inject any globals?
• How does it interact with web components, both in terms of creating new ones and using existing components written using different frameworks?

Discuss

We're interested in hearing the pros and cons of the various ways we can satisfy the items listed under requirements, recommendations for solutions we don't have listed, and questions about the reqs and how and why we arrived at them.

Also, I encourage @atom/core and maintainers to edit the Contenders section in the issue body as more come in, and let me know if I missed / misstated anything in Requirements

[mark-hahn]

That is good news. There was a vacuum for new package developers.

On Wed, Feb 25, 2015 at 6:38 PM, Daniel Hengeveld notifications@github.com
wrote:

(This is an attempt to restate #3752
#3752, explain the current position
and present options)
A blessed view system for Atom

We're in an interesting place with respect to generating views in packages
and core. We wrote space-pen https://github.com/atom/space-pen and used
it heavily, but ultimately decided to discontinue using it for new views (though
some base views still use space-pen
https://github.com/atom/atom-space-pen-views we are no longer
recommending it). So now we find ourselves in an unfortunate position of
using the DOM APIs directly, and suggesting package authors do the same,
choose a framework themselves, or ╮(. ❛ ᴗ ❛.)╭ - Not a great place to be,
and makes it hard to write docs with nice examples.

We used React in the editor component for six months or so, and it was a
good experience, but it has a bit of a learning curve.

We experimented with a few things inspired by React and Polymer, and have
done some research on 3rd-party view frameworks, but haven't come to a
decision. As we work on better docs for the run up to 1.0, we have to start
taking this seriously.
Requirements

• Embrace modern browser features (custom elements, etc) as much as
  possible
• recognizable markup (allow users to write 'normal HTML')
  • data binding preferred to imperative updates if templates are used
    • View model / MVVM-style separation of rendering and logic
• Easy for developers to replace with another preferred library
  • this implies not polluting the global namespace
    • No dependencies on jQuery-like helper libs
• Small learning curve
  • somewhat self-explanatory when used in docs examples
  • in other words, most web developers will be able to recognize the
    concepts that are applied without reading a book on it

Contenders / experiments

• React http://facebook.github.io/react/
• rivets http://rivetsjs.com/ for templating+data binding plus some
  basic JS object glue for Atom
• television https://github.com/atom/television - "Television aims
  to cleanly integrate the virtual DOM approach of React.js into HTML 5
  custom elements." - an experiment from @nathansobo
  https://github.com/nathansobo
• elmer https://github.com/atom/elmer - An experiment from @benogle
  https://github.com/benogle based on Polymer's template binding
• virtual-dom https://github.com/Matt-Esch/virtual-dom
• vue.js http://vuejs.org/ - simple, component-based, simple & small
• Something custom, delightful & new from your friends the Atom team
  (but we don't reallllly want to maintain another view frameowrk)

Discuss

We're interested in hearing the pros and cons of the various ways we can
satisfy the items listed under requirements, recommendations for solutions
we don't have listed, and questions about the reqs and how and why we
arrived at them.

Also, I encourage @atom/core https://github.com/orgs/atom/teams/core
and maintainers to edit the Contenders section in the issue body as more
come in, and let me know if I missed / misstated anything in Requirements

—
Reply to this email directly or view it on GitHub
#5756.

[steelbrain]

I am using vanilla-jsx, it supports JSX but it spits out native HTML Elements so it's performant and lightweight

[gilbert]

Mithril.js saved JavaScript for me. Like many others frameworks/libraries it uses a virtual DOM, but most importantly it's just JavaScript. No JSX, no OOP, no arbitrary html-ish templating languages. Once you learn its five or so core methods, you're free to think and do anything JavaScript without Mithril getting in the way.

[mark-hahn]

no arbitrary html-ish templating languages

I think there should be a blessed template syntax as per the "recognizable
markup" requirement. I want to be able to easily read other package's
code.

IMHO it should be a simple noise-free template syntax like that of
space-pen.

On Wed, Feb 25, 2015 at 8:02 PM, Gilbert notifications@github.com wrote:

Mithril.js http://lhorie.github.io/mithril/index.html saved JavaScript
for me. Like many others frameworks/libraries it uses a virtual DOM, but
most importantly it's just JavaScript. No JSX, no OOP, no arbitrary
html-ish templating languages. Once you learn its five or so core methods,
you're free to think and do anything JavaScript without Mithril getting in
the way.

—
Reply to this email directly or view it on GitHub
#5756 (comment).

[thedaniel]

IMHO it should be a simple noise-free template syntax like that of space-pen.

This conflicts with the second requirement listed - I personally am strongly against anything like space-pen's syntax, or HAML, and I believe the rest of the team either doesn't feel strongly, or prefers that if we use templates at all we do data binding + templates similar to Polymer: https://www.polymer-project.org/docs/polymer/databinding.html

I'll let them chime in, but I wouldn't get your hopes up for something space-pen-like.

[mark-hahn]

I personally am strongly against anything like space-pen's syntax, or HAML

I don't see how Atom could bless coffeescript and not Space-Pen syntax. They are one and the same.

I know we have to use an existing solution so there probably won't be such a syntax available but I would certainly argue for matching coffeescript if we could.

[benogle]

recognizable markup (allow users to write 'normal HTML')

This is definitely not a requirement. Television, for example is more space-pen-like (and even more react like, minus the jsx). I personally like the markup better than the code-like definition, but it's not a requirement.

Easy for developers to replace with another preferred library; this implies not polluting the global namespace

The global namespace issue is a super hard requirement. Not really for ease of switching, but for playing nice with other versions of the framework, and with other frameworks.

We basically want the option of more than one framework to be used as a dep. That way we're relatively future proof. When the next react or whatever comes along, we can use it by including it as a dependency.

[mark-hahn]

The television link is a 404.

[benogle]

@mark-hahn it should work now. Sorry about that

[thedaniel]

Perhaps I let my opinions leak into the requirements - we're evaluating some options that don't use normal markup in their templates. I still think it's very prudent from a docs perspective but I'll move it out of the issue body and into "thedaniel's suggestions in the comments" since it's not actually a hard requirement.

[mark-hahn]

Television looks awesome. It looks cleaner and less-noisy than space-pen. And the custom element handling seems simple, even to a luddite like me. I think it would be accessible to beginners.

[lhorie]

Mithril's out of the box syntax is very similar to virtual-dom/television, but you can also get HTMLy syntax via MSX (basically the same thing as React's JSX) if curly braces are important.

There's also SugarTags for a different flavor of code-like definitions.

[lee-dohm]

I like the template+data-binding approach. I think it would be awesome if the template language was pluggable so if people wanted something more HTML-like, they could have it, closing tags and all. And if they wanted something simplified a la HAML/Jade/Slim, they could have that too.

[benogle]

If anyone out there is interested, one way to help speed this along is to do some experimentation with using your favorite framework in a package. See https://github.com/benogle/template-explore as an example package using https://github.com/atom/elmer.

A couple questions I would try to answer with the package:

• How does it handle model/DOM updates? Data-binding? Imperative + virtual-dom like react?
• How does it handle events? i.e. How do I bind a click handler to an element?
• Can it work with Object.observe and not it's own model system?
• Does it inject any globals?