New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
thedaniel opened this Issue Feb 26, 2015 · 132 comments

Comments

Projects
None yet
@thedaniel
Contributor

thedaniel commented Feb 26, 2015

(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

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Feb 26, 2015

Contributor

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

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.

Contributor

mark-hahn commented Feb 26, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@steelbrain

steelbrain Feb 26, 2015

Contributor

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

Contributor

steelbrain commented Feb 26, 2015

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

@gilbert

This comment has been minimized.

Show comment
Hide comment
@gilbert

gilbert Feb 26, 2015

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.

gilbert commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Feb 26, 2015

Contributor

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

Contributor

mark-hahn commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@thedaniel

thedaniel Feb 26, 2015

Contributor

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.

Contributor

thedaniel commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Feb 26, 2015

Contributor

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.

Contributor

mark-hahn commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Feb 26, 2015

Contributor

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.

Contributor

benogle commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Feb 26, 2015

Contributor

The television link is a 404.

Contributor

mark-hahn commented Feb 26, 2015

The television link is a 404.

@benogle

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Feb 26, 2015

Contributor

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

Contributor

benogle commented Feb 26, 2015

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

@thedaniel

This comment has been minimized.

Show comment
Hide comment
@thedaniel

thedaniel Feb 26, 2015

Contributor

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.

Contributor

thedaniel commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Feb 26, 2015

Contributor

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.

Contributor

mark-hahn commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@lhorie

lhorie Feb 26, 2015

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.

lhorie commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@lee-dohm

lee-dohm Feb 26, 2015

Member

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.

Member

lee-dohm commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Feb 26, 2015

Contributor

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

benogle commented Feb 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Feb 26, 2015

Contributor
  • How does it interact with web components, both in terms of creating new ones and using existing components written using different frameworks?
Contributor

nathansobo commented Feb 26, 2015

  • How does it interact with web components, both in terms of creating new ones and using existing components written using different frameworks?
@benogle

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Feb 26, 2015

Contributor

I added a section in the body about helping out and answering these questions.

Contributor

benogle commented Feb 26, 2015

I added a section in the body about helping out and answering these questions.

@nathansobo nathansobo self-assigned this Feb 26, 2015

@lee-dohm

This comment has been minimized.

Show comment
Hide comment
Member

lee-dohm commented Feb 26, 2015

@benogle

This comment has been minimized.

Show comment
Hide comment
@benogle

benogle Feb 26, 2015

Contributor

I'm taking a look at Vue.

❤️ Thanks. I briefly looked at it to see if it supported Object.observe, but iirc it didnt right now, and was not clear how to hack it in.

Contributor

benogle commented Feb 26, 2015

I'm taking a look at Vue.

❤️ Thanks. I briefly looked at it to see if it supported Object.observe, but iirc it didnt right now, and was not clear how to hack it in.

@lee-dohm

This comment has been minimized.

Show comment
Hide comment
@lee-dohm

lee-dohm Feb 26, 2015

Member

🙇 You're welcome. This is my opportunity to dig deeper into the DOM and rendering, so I figured I'd give it the good ol' college try. I'm currently running into unsafe eval issues, but I'll take another crack at it later tonight.

Member

lee-dohm commented Feb 26, 2015

🙇 You're welcome. This is my opportunity to dig deeper into the DOM and rendering, so I figured I'd give it the good ol' college try. I'm currently running into unsafe eval issues, but I'll take another crack at it later tonight.

@wmertens

This comment has been minimized.

Show comment
Hide comment
@wmertens

wmertens Feb 28, 2015

Things that make me prefer React:

  • largest community of the proposed options
  • battle-tested with constant focus on performance
  • good dev tools: chrome devtools extension, webpack hotloader support etc.
  • JSX is optional and you can use television-like syntax as well
  • Plays well with immutability; statelessness gives you almost-free undo management and can really speed up your page draws while maintaining a simple concept for the code. For an example, see Goya (written in clojurescript on top of React) and the code it needed for undo management.
    • Note that if you embrace statelessness you don't need Object.Observe, or am I mistaken?

wmertens commented Feb 28, 2015

Things that make me prefer React:

  • largest community of the proposed options
  • battle-tested with constant focus on performance
  • good dev tools: chrome devtools extension, webpack hotloader support etc.
  • JSX is optional and you can use television-like syntax as well
  • Plays well with immutability; statelessness gives you almost-free undo management and can really speed up your page draws while maintaining a simple concept for the code. For an example, see Goya (written in clojurescript on top of React) and the code it needed for undo management.
    • Note that if you embrace statelessness you don't need Object.Observe, or am I mistaken?
@Zireael07

This comment has been minimized.

Show comment
Hide comment
@Zireael07

Zireael07 Feb 28, 2015

Focus on performance? Me likey.

Zireael07 commented Feb 28, 2015

Focus on performance? Me likey.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Feb 28, 2015

Contributor

This framework is for packages and almost no package has any performance
issues.

On Fri, Feb 27, 2015 at 11:03 PM, Zireael07 notifications@github.com
wrote:

Focus on performance? Me likey.


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

Contributor

mark-hahn commented Feb 28, 2015

This framework is for packages and almost no package has any performance
issues.

On Fri, Feb 27, 2015 at 11:03 PM, Zireael07 notifications@github.com
wrote:

Focus on performance? Me likey.


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

@wmertens

This comment has been minimized.

Show comment
Hide comment
@wmertens

wmertens Feb 28, 2015

@mark-hahn Hmmm, I have like 40 packages installed. A lot of small slowdowns also results in a large slowdown... So I think that potential performance should be weighed as well.
For example, if I go to the dev tools timeline and record, I get a ton of timers fired and redraws every second, even though nothing changed and nothing is active. The timers are mostly from minimap which seems to poll the dom every 0.1s but doesn't turn off the polling when a pane is not active (I'll open a bug).
I'm just armchair programming here, but if immutability were used, the minimap would be only dependent on the editor text and the window position. Whenever either changes, it can re-render (and it would have both old and new versions available for diffing). No polling would be needed then.

wmertens commented Feb 28, 2015

@mark-hahn Hmmm, I have like 40 packages installed. A lot of small slowdowns also results in a large slowdown... So I think that potential performance should be weighed as well.
For example, if I go to the dev tools timeline and record, I get a ton of timers fired and redraws every second, even though nothing changed and nothing is active. The timers are mostly from minimap which seems to poll the dom every 0.1s but doesn't turn off the polling when a pane is not active (I'll open a bug).
I'm just armchair programming here, but if immutability were used, the minimap would be only dependent on the editor text and the window position. Whenever either changes, it can re-render (and it would have both old and new versions available for diffing). No polling would be needed then.

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Feb 28, 2015

Contributor

@abe33 Would you consider switching mini-map to use atom.views.pollDocument to coordinate polling with the editor? It's currently an experimental API and it would be nice to get some external feedback on it. There's also atom.views.readDocument and updateDocument for coordinating reads and writes which may be of interest.

Contributor

nathansobo commented Feb 28, 2015

@abe33 Would you consider switching mini-map to use atom.views.pollDocument to coordinate polling with the editor? It's currently an experimental API and it would be nice to get some external feedback on it. There's also atom.views.readDocument and updateDocument for coordinating reads and writes which may be of interest.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Feb 28, 2015

Contributor

. A lot of small slowdowns also results in a large slowdown...

I'm arguing that slowdowns aren't caused by the framework when the package is only working on a small part of the DOM, like a half-dozen divs.

I get a ton of timers fired and redraws every second, even though nothing changed and nothing is active.

If this is true then there should be a core API to consolidate these. I have asked before for the presenter to be able to be used by packages.

Contributor

mark-hahn commented Feb 28, 2015

. A lot of small slowdowns also results in a large slowdown...

I'm arguing that slowdowns aren't caused by the framework when the package is only working on a small part of the DOM, like a half-dozen divs.

I get a ton of timers fired and redraws every second, even though nothing changed and nothing is active.

If this is true then there should be a core API to consolidate these. I have asked before for the presenter to be able to be used by packages.

@kolya-ay

This comment has been minimized.

Show comment
Hide comment
@kolya-ay

kolya-ay Mar 5, 2015

Regarding React alternatives there is a good thread on Reddit with comments from frameworks authors. The most mature Virtual DOM's implementations could be catched form Virtual DOM Benchmark project. Actually lot of full featured "frameworks" are based on the great virtual-dom library (mercury, aforementioned television, elm language to name a few).
Personally, I'm a huge fan of Mithril because of its internal elegance and simplicity. However its scope is a bit bigger than just a "view system". Besides view layer it embraces routing and Ajax wrapper which might be considered as a bloat for Atom

kolya-ay commented Mar 5, 2015

Regarding React alternatives there is a good thread on Reddit with comments from frameworks authors. The most mature Virtual DOM's implementations could be catched form Virtual DOM Benchmark project. Actually lot of full featured "frameworks" are based on the great virtual-dom library (mercury, aforementioned television, elm language to name a few).
Personally, I'm a huge fan of Mithril because of its internal elegance and simplicity. However its scope is a bit bigger than just a "view system". Besides view layer it embraces routing and Ajax wrapper which might be considered as a bloat for Atom

@johanlunds

This comment has been minimized.

Show comment
Hide comment
@johanlunds

johanlunds Mar 29, 2015

FYI: I've been trying out Rivets.js for my first package: https://github.com/johanlunds/atom-ruby-debugger

Here are my impressions so far.

What I like:

  • simple and small, quick to learn
  • only view-layer
  • CoffeeScript, easy to read and understand. Simple implementation.
  • Good documentation
  • Integrates pretty nicely with Atom

What is difficult/what I don't like:

  • very limited
  • computed bindings (ie. function calls) is a bit difficult, and you have to declare the properties/attributes that the function depends on in your HTML-code
  • bindings have to be keypaths, they can't be JS-expressions
  • no {{ }} bindings in textContent or attributes, ie. <span>Hello {{ name }}<span>
  • no transclude à la Angular.js (although it's probably possible with custom "binders" or components that manipulate el)

It's possible to write an adapter to make it use Object.observe, but I haven't tried writing one yet and I couldn't find an existing one. Not 100% sure how to implement it.

Checklist: Requirements

  • Embrace modern browser features (custom elements, Object.observe, etc) as much as possible.

Answer: yes. Custom elements. Object.observe is possible with an adapter

  • It absolutely does not pollute the global namespace.

Answer: yes, it seems ok

  • Data-binding preferred to imperative updates if templates are used

Answer: yes, bindings to keypaths. No full JS-expressions in the templates

  • View model / MVVM-style separation of rendering and logic

Answer: yes, I guess so. You can declare your own components = custom elements that can have their own class = view model

  • No dependencies on jQuery-like helper libs

Answer: yes

  • 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

Answer: yes

Checklist: questions

  • How does it handle model/DOM updates? Data-binding? Imperative + virtual-dom like react?

Answer: It's very basic and a bit constrained. Not as full-featured as for example Angular or Vue.js I think. But the upside is that the implementation is simple. Data-binding: yes. Virtual-dom: no. I don't think DOM-updates are batched.

  • How does it handle events? i.e. How do I bind a click handler to an element?

Answer: use rv-on-click="model.function" in the HTML-template. It does not use event delegation I think

  • Can it work with Object.observe and not it's own model system?

Answer: yes

  • Does it inject any globals?

Answer: no

  • How does it interact with web components, both in terms of creating new ones and using existing components written using different frameworks?

Answer: Pretty sure that won't be a problem, but I haven't really tried

johanlunds commented Mar 29, 2015

FYI: I've been trying out Rivets.js for my first package: https://github.com/johanlunds/atom-ruby-debugger

Here are my impressions so far.

What I like:

  • simple and small, quick to learn
  • only view-layer
  • CoffeeScript, easy to read and understand. Simple implementation.
  • Good documentation
  • Integrates pretty nicely with Atom

What is difficult/what I don't like:

  • very limited
  • computed bindings (ie. function calls) is a bit difficult, and you have to declare the properties/attributes that the function depends on in your HTML-code
  • bindings have to be keypaths, they can't be JS-expressions
  • no {{ }} bindings in textContent or attributes, ie. <span>Hello {{ name }}<span>
  • no transclude à la Angular.js (although it's probably possible with custom "binders" or components that manipulate el)

It's possible to write an adapter to make it use Object.observe, but I haven't tried writing one yet and I couldn't find an existing one. Not 100% sure how to implement it.

Checklist: Requirements

  • Embrace modern browser features (custom elements, Object.observe, etc) as much as possible.

Answer: yes. Custom elements. Object.observe is possible with an adapter

  • It absolutely does not pollute the global namespace.

Answer: yes, it seems ok

  • Data-binding preferred to imperative updates if templates are used

Answer: yes, bindings to keypaths. No full JS-expressions in the templates

  • View model / MVVM-style separation of rendering and logic

Answer: yes, I guess so. You can declare your own components = custom elements that can have their own class = view model

  • No dependencies on jQuery-like helper libs

Answer: yes

  • 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

Answer: yes

Checklist: questions

  • How does it handle model/DOM updates? Data-binding? Imperative + virtual-dom like react?

Answer: It's very basic and a bit constrained. Not as full-featured as for example Angular or Vue.js I think. But the upside is that the implementation is simple. Data-binding: yes. Virtual-dom: no. I don't think DOM-updates are batched.

  • How does it handle events? i.e. How do I bind a click handler to an element?

Answer: use rv-on-click="model.function" in the HTML-template. It does not use event delegation I think

  • Can it work with Object.observe and not it's own model system?

Answer: yes

  • Does it inject any globals?

Answer: no

  • How does it interact with web components, both in terms of creating new ones and using existing components written using different frameworks?

Answer: Pretty sure that won't be a problem, but I haven't really tried

@mnquintana

This comment has been minimized.

Show comment
Hide comment
@mnquintana

mnquintana Apr 27, 2015

Member

A few ideas:

  • Whatever we end up going with, I'd really like it to be something that encourages separation of the template from the controller / view model / glue logic (in separate files, really). Space Pen encourages the exact opposite of that - templates are smashed right into the logic for that template - and I've always found it really messy and unnecessarily confusing.
  • I'd really prefer a Component-based separation of concerns over an MVVM / MVC / MVW approach (if they are mutually exclusive at all, that is).
Member

mnquintana commented Apr 27, 2015

A few ideas:

  • Whatever we end up going with, I'd really like it to be something that encourages separation of the template from the controller / view model / glue logic (in separate files, really). Space Pen encourages the exact opposite of that - templates are smashed right into the logic for that template - and I've always found it really messy and unnecessarily confusing.
  • I'd really prefer a Component-based separation of concerns over an MVVM / MVC / MVW approach (if they are mutually exclusive at all, that is).
@wmertens

This comment has been minimized.

Show comment
Hide comment
@wmertens

wmertens Apr 27, 2015

@mnquintana Actually, that was my original concern about React too - I have seen way too many crappy PHP apps. They always worked nicely but the code was a mess.

Turns out that if you write React code in a sane way, having your template together with your code is great. Most of the time you are not actually outputting HTML tags but custom elements that combine into what you need, and can have unit tests etc.

wmertens commented Apr 27, 2015

@mnquintana Actually, that was my original concern about React too - I have seen way too many crappy PHP apps. They always worked nicely but the code was a mess.

Turns out that if you write React code in a sane way, having your template together with your code is great. Most of the time you are not actually outputting HTML tags but custom elements that combine into what you need, and can have unit tests etc.

@lee-dohm

This comment has been minimized.

Show comment
Hide comment
@lee-dohm

lee-dohm Apr 27, 2015

Member

I'd really like it to be something that encourages separation of the template from the controller / view model / glue logic (in separate files, really)

I'd agree with this as long as it is "encourages" and not "requires". One of the things that is awesome about Atom is that one doesn't have to write a package to create a simple command. One can just put some code into the init.config to experiment. But, when the code is ready, it can be wrapped up into a package. It is a gradual learning curve that has easy steps between each level.

As @mark-hahn has pointed out, I'd like there to be a simple way to create small packages with UI that doesn't require more than two files (template and code). And then an obvious transition (perhaps simply documented as best practices or advanced use) that allows people to build whatever abstraction is designed to be "the right way".

Member

lee-dohm commented Apr 27, 2015

I'd really like it to be something that encourages separation of the template from the controller / view model / glue logic (in separate files, really)

I'd agree with this as long as it is "encourages" and not "requires". One of the things that is awesome about Atom is that one doesn't have to write a package to create a simple command. One can just put some code into the init.config to experiment. But, when the code is ready, it can be wrapped up into a package. It is a gradual learning curve that has easy steps between each level.

As @mark-hahn has pointed out, I'd like there to be a simple way to create small packages with UI that doesn't require more than two files (template and code). And then an obvious transition (perhaps simply documented as best practices or advanced use) that allows people to build whatever abstraction is designed to be "the right way".

@Jaeiya

This comment has been minimized.

Show comment
Hide comment
@Jaeiya

Jaeiya May 17, 2015

I know it's a bit bleeding-edge, but Aurelia seems to meet the described requirements. It does leverage Object.observe when it can. It's development seems just as active as Atoms and its devs are actively listening to the community on how to move forward.

  • two-way, one-way, only-once bindings
  • Leverages the shadowDOM (optional)
  • Custom Elements (with template's) and Attributes.
  • Tries to avoid dirty-checking in favor of Object.observe
  • Uses systemjs and jspm for a truly modular experience
  • Pure ES6 syntax support with Babel

I'm currently using it in a project of mine and I feel like this could be the big one to replace all the major frameworks out there. This of course is coming from someone who doesn't have a lot of experience with Angular/React frameworks. The closest I've gotten to MVC is Knockout. That being said, the creator of Aurelia was part of the Angular team, whom felt that their (new) philosophy wasn't in line with his own, thus the birth of Aurelia.

Currently the only pitfall it has right now is its lack of documentation, but that's indicative of its current age. It's still very much a WIP. However, I see Atom in the same light as I see Aurelia. Both share a quick development life-cycle and testing is essentially community driven. Bugs are found because of the community. I understand that sharing a philosophy alone isn't enough to decide adoption, but it's good incentive right?

Here are some links
Aurelia.io
Docs
Example app
on Github
Discussion platform

Let me know what you think 😄

Jaeiya commented May 17, 2015

I know it's a bit bleeding-edge, but Aurelia seems to meet the described requirements. It does leverage Object.observe when it can. It's development seems just as active as Atoms and its devs are actively listening to the community on how to move forward.

  • two-way, one-way, only-once bindings
  • Leverages the shadowDOM (optional)
  • Custom Elements (with template's) and Attributes.
  • Tries to avoid dirty-checking in favor of Object.observe
  • Uses systemjs and jspm for a truly modular experience
  • Pure ES6 syntax support with Babel

I'm currently using it in a project of mine and I feel like this could be the big one to replace all the major frameworks out there. This of course is coming from someone who doesn't have a lot of experience with Angular/React frameworks. The closest I've gotten to MVC is Knockout. That being said, the creator of Aurelia was part of the Angular team, whom felt that their (new) philosophy wasn't in line with his own, thus the birth of Aurelia.

Currently the only pitfall it has right now is its lack of documentation, but that's indicative of its current age. It's still very much a WIP. However, I see Atom in the same light as I see Aurelia. Both share a quick development life-cycle and testing is essentially community driven. Bugs are found because of the community. I understand that sharing a philosophy alone isn't enough to decide adoption, but it's good incentive right?

Here are some links
Aurelia.io
Docs
Example app
on Github
Discussion platform

Let me know what you think 😄

@devmondo

This comment has been minimized.

Show comment
Hide comment
@devmondo

devmondo May 17, 2015

another vote for Aurelia 👍

devmondo commented May 17, 2015

another vote for Aurelia 👍

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn May 17, 2015

Contributor

Does Aurelia work well with coffeescript?

I'm in the middle of a project using Vue. I am impressed with it's
simplicity and bindings. I started the same project with rivets and
ampersand before. They were hard for me to understand. I spent two days
on each before trying Vue. It works great with coffeescript.

On Sun, May 17, 2015 at 11:33 AM, Feras Khoursheed <notifications@github.com

wrote:

another vote for Aurelia [image: 👍]


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

Contributor

mark-hahn commented May 17, 2015

Does Aurelia work well with coffeescript?

I'm in the middle of a project using Vue. I am impressed with it's
simplicity and bindings. I started the same project with rivets and
ampersand before. They were hard for me to understand. I spent two days
on each before trying Vue. It works great with coffeescript.

On Sun, May 17, 2015 at 11:33 AM, Feras Khoursheed <notifications@github.com

wrote:

another vote for Aurelia [image: 👍]


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

@pamtbaau

This comment has been minimized.

Show comment
Hide comment
@pamtbaau

pamtbaau Dec 21, 2015

@kanekotic I think it's best to open your own specific issue instead of hijacking this thread.

pamtbaau commented Dec 21, 2015

@kanekotic I think it's best to open your own specific issue instead of hijacking this thread.

@kanekotic

This comment has been minimized.

Show comment
Hide comment
@kanekotic

kanekotic Dec 21, 2015

@pamtbaau i am not trying to hijack this thread, I actually have an open thread in the vue forum for it (so chill bro ;), because i am not asking questions just showing a snippet and saying it doesnt work as expected).

I just want to point out that at least with vue i dont see an easy way to have a two way binding for user input inside atom. This is because user input in atom is done by atom-text-editor and vue supports two way bindings using v-model only on elements input, select and textarea. so binding atom-text-editor in a two-way is not straight forward (i might be wrong but i would think this could be related to the need to also use loophole but i am not an expert in neither of the frameworks).

Most of the examples i have seen are oversimplified just showing that is possible to use the framework but ignores basic cases exposed on the Styleguide. I would expect that the solution selected should at least be able to natively support some basic cases.

I agree with your concern of this becoming an unsustainable discussion of frameworks and everyone providing his own findings, so i would think that it would be a good idea to have an open thread per each of the tested frameworks to track pros and cons.

PS. if anyone else feels annoyed or think that is not useful at all my previous post let me know and i will remove it or refactor it. But my concerns still the same 'how to treat user input'

kanekotic commented Dec 21, 2015

@pamtbaau i am not trying to hijack this thread, I actually have an open thread in the vue forum for it (so chill bro ;), because i am not asking questions just showing a snippet and saying it doesnt work as expected).

I just want to point out that at least with vue i dont see an easy way to have a two way binding for user input inside atom. This is because user input in atom is done by atom-text-editor and vue supports two way bindings using v-model only on elements input, select and textarea. so binding atom-text-editor in a two-way is not straight forward (i might be wrong but i would think this could be related to the need to also use loophole but i am not an expert in neither of the frameworks).

Most of the examples i have seen are oversimplified just showing that is possible to use the framework but ignores basic cases exposed on the Styleguide. I would expect that the solution selected should at least be able to natively support some basic cases.

I agree with your concern of this becoming an unsustainable discussion of frameworks and everyone providing his own findings, so i would think that it would be a good idea to have an open thread per each of the tested frameworks to track pros and cons.

PS. if anyone else feels annoyed or think that is not useful at all my previous post let me know and i will remove it or refactor it. But my concerns still the same 'how to treat user input'

@pamtbaau

This comment has been minimized.

Show comment
Hide comment
@pamtbaau

pamtbaau Dec 21, 2015

@kanekotic See Two-way element binding in Atom using Vue #1 in your project repository. I've posted a sample that works for me.

pamtbaau commented Dec 21, 2015

@kanekotic See Two-way element binding in Atom using Vue #1 in your project repository. I've posted a sample that works for me.

@lee-dohm

This comment has been minimized.

Show comment
Hide comment
@lee-dohm

lee-dohm Dec 21, 2015

Member

user input in atom is done by atom-text-editor

It can be, but doesn't have to be. If you look at my bug-report package, I use standard input tags for text input. I do it this way because it's easier and I didn't need all the fancy features provided by atom-text-editor.

Member

lee-dohm commented Dec 21, 2015

user input in atom is done by atom-text-editor

It can be, but doesn't have to be. If you look at my bug-report package, I use standard input tags for text input. I do it this way because it's easier and I didn't need all the fancy features provided by atom-text-editor.

@littlebee

This comment has been minimized.

Show comment
Hide comment
@littlebee

littlebee Dec 30, 2015

Around the same time I started hacking on Atom, a teammate introduced me to React. React and space-pen both changed a fundamental belief I had about web development, which was that view logic and markup should be separate and distinct concerns. I loath templates like I've seen in Php and Ruby where there is a lot of flow control and looping embedded in the template - which was one of the things that turned me off about Angular when it started to gain popularity on other teams.

I came back to work from my hack-cation in Aug. with the View base class we'd been missing. It was almost space-pen because it gel'd so well with our psuedo Backbone view, heavily jQuery + underscore template views. Making the view objects themselves jQuery instances meant less wiring code.

The winner though, was React. space-pen was deprecated around that time and the components built with React were more reusable and compositing components was easier + a LOT less wiring.

Convincing my team was easy - I just showed them the 334 lines of coffeescript + _ templates specific to one view in our system replaced by 64 lines of React + JSX - assuming they would let me go off and develop some components we would need to connect to our existing Backbone models and collections 😄.

The beauty of Atom and Node though is that you don't have to choose for us. Anyone can use any or all of the above, no?

littlebee commented Dec 30, 2015

Around the same time I started hacking on Atom, a teammate introduced me to React. React and space-pen both changed a fundamental belief I had about web development, which was that view logic and markup should be separate and distinct concerns. I loath templates like I've seen in Php and Ruby where there is a lot of flow control and looping embedded in the template - which was one of the things that turned me off about Angular when it started to gain popularity on other teams.

I came back to work from my hack-cation in Aug. with the View base class we'd been missing. It was almost space-pen because it gel'd so well with our psuedo Backbone view, heavily jQuery + underscore template views. Making the view objects themselves jQuery instances meant less wiring code.

The winner though, was React. space-pen was deprecated around that time and the components built with React were more reusable and compositing components was easier + a LOT less wiring.

Convincing my team was easy - I just showed them the 334 lines of coffeescript + _ templates specific to one view in our system replaced by 64 lines of React + JSX - assuming they would let me go off and develop some components we would need to connect to our existing Backbone models and collections 😄.

The beauty of Atom and Node though is that you don't have to choose for us. Anyone can use any or all of the above, no?

@mnquintana

This comment has been minimized.

Show comment
Hide comment
@mnquintana

mnquintana Dec 31, 2015

Member

Just to clarify, there will be no "official" view framework per se – this is all just to choose the library that will be used in examples in the docs and in the package generator, and that's about it. Package authors will remain free to use whatever they want.

Member

mnquintana commented Dec 31, 2015

Just to clarify, there will be no "official" view framework per se – this is all just to choose the library that will be used in examples in the docs and in the package generator, and that's about it. Package authors will remain free to use whatever they want.

@kanekotic

This comment has been minimized.

Show comment
Hide comment
@kanekotic

kanekotic Jan 6, 2016

so why then not leave it as is? (just using the DOM). It will be the clean solution, as per there are no extra packages/dependencies added.

Maybe what it will be cool is to have a repository in atom where people can collaborate with basic example for the different frameworks that have been experimented with.

kanekotic commented Jan 6, 2016

so why then not leave it as is? (just using the DOM). It will be the clean solution, as per there are no extra packages/dependencies added.

Maybe what it will be cool is to have a repository in atom where people can collaborate with basic example for the different frameworks that have been experimented with.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Jan 6, 2016

Contributor

so why then not leave it as is? (just using the DOM).

No one develops the DOM by using only javascript calls. It is painful, verbose, and hard to remember. I can't think of anything that would scare away newbies more than this. The fact that the sample package uses this is a big problem. No one seems to care about newcomers.

Contributor

mark-hahn commented Jan 6, 2016

so why then not leave it as is? (just using the DOM).

No one develops the DOM by using only javascript calls. It is painful, verbose, and hard to remember. I can't think of anything that would scare away newbies more than this. The fact that the sample package uses this is a big problem. No one seems to care about newcomers.

@lee-dohm

This comment has been minimized.

Show comment
Hide comment
@lee-dohm

lee-dohm Jan 6, 2016

Member

The general idea is that we want to make writing an Atom package, even one with a custom UI, as streamlined as possible. To that end, we feel that we should have a view framework that the Atom team is familiar with so we can assist when people get stuck.

Maybe what it will be cool is to have a repository in atom where people can collaborate with basic example for the different frameworks that have been experimented with.

I think this is a great idea and I would be willing to add a section in the Flight Manual for "reference implementations" of a simple package with a UI that is implemented in various frameworks by community authors. To that end, I've started a topic on Discuss to come up with what that "reference package" could be.

Member

lee-dohm commented Jan 6, 2016

The general idea is that we want to make writing an Atom package, even one with a custom UI, as streamlined as possible. To that end, we feel that we should have a view framework that the Atom team is familiar with so we can assist when people get stuck.

Maybe what it will be cool is to have a repository in atom where people can collaborate with basic example for the different frameworks that have been experimented with.

I think this is a great idea and I would be willing to add a section in the Flight Manual for "reference implementations" of a simple package with a UI that is implemented in various frameworks by community authors. To that end, I've started a topic on Discuss to come up with what that "reference package" could be.

@steelbrain

This comment has been minimized.

Show comment
Hide comment
@steelbrain

steelbrain Jan 6, 2016

Contributor

@mark-hahn I've DOM by only javascript calls in linter panel. It was worth it for the flexibility, I could do all sorts of optimizations specific to linter there

Contributor

steelbrain commented Jan 6, 2016

@mark-hahn I've DOM by only javascript calls in linter panel. It was worth it for the flexibility, I could do all sorts of optimizations specific to linter there

@Hurtak

This comment has been minimized.

Show comment
Hide comment
@Hurtak

Hurtak Jan 6, 2016

How about starting some official 'todoMVC' repo for atom packages. One specific simple package would be developed in several frameworks/libraries, atom devs would then be able to evaluate what suits best to beginners, and potential package developers would see how to develop packages in their favorite framework

Hurtak commented Jan 6, 2016

How about starting some official 'todoMVC' repo for atom packages. One specific simple package would be developed in several frameworks/libraries, atom devs would then be able to evaluate what suits best to beginners, and potential package developers would see how to develop packages in their favorite framework

@kanekotic

This comment has been minimized.

Show comment
Hide comment
@kanekotic

kanekotic Jan 6, 2016

@mark-hahn I agree that using only DOM calls is painful. But i also agree with @lee-dohm and @mnquintana and the flexibility of using different frameworks, but i think the knowledge to help in the different ones should reside in the community it will probably become a burden.
I think the atom package generator should offline continue as is just a simple thing that explains how to start, and maybe extended with an extra option that will clone base projects based on a selected framework, that will allow the flexibility of selecting a framework.

kanekotic commented Jan 6, 2016

@mark-hahn I agree that using only DOM calls is painful. But i also agree with @lee-dohm and @mnquintana and the flexibility of using different frameworks, but i think the knowledge to help in the different ones should reside in the community it will probably become a burden.
I think the atom package generator should offline continue as is just a simple thing that explains how to start, and maybe extended with an extra option that will clone base projects based on a selected framework, that will allow the flexibility of selecting a framework.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Jan 6, 2016

Contributor

todoMVC would be perfect since it has become the standard go-to demo app. It would need to be tweaked to somehow fit into atom instead of the standard web page.

Contributor

mark-hahn commented Jan 6, 2016

todoMVC would be perfect since it has become the standard go-to demo app. It would need to be tweaked to somehow fit into atom instead of the standard web page.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Jan 6, 2016

Contributor

an extra option that will clone base projects based on a selected framework,

I don't see why the sample projects @leedohm wants couldn't be loaded as projects.

Contributor

mark-hahn commented Jan 6, 2016

an extra option that will clone base projects based on a selected framework,

I don't see why the sample projects @leedohm wants couldn't be loaded as projects.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Jan 6, 2016

Contributor

It was worth it for the flexibility, I could do all sorts of optimizations specific to linter there

I can't imagine any optimization that couldn't be done with a framework, particularly vue, which is what I use.

Contributor

mark-hahn commented Jan 6, 2016

It was worth it for the flexibility, I could do all sorts of optimizations specific to linter there

I can't imagine any optimization that couldn't be done with a framework, particularly vue, which is what I use.

@steelbrain

This comment has been minimized.

Show comment
Hide comment
@steelbrain

steelbrain Jan 6, 2016

Contributor

@mark-hahn We have to handle cases with ~5k error messages in one panel, we have to keep a pool of DOM elements and re-use them in both panel and bubble and for that we have to design the message elements to be disposable + reusable.

Contributor

steelbrain commented Jan 6, 2016

@mark-hahn We have to handle cases with ~5k error messages in one panel, we have to keep a pool of DOM elements and re-use them in both panel and bubble and for that we have to design the message elements to be disposable + reusable.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Jan 6, 2016

Contributor

we have to design the message elements to be disposable + reusable.

Actually, vue components would be perfect for that. I'm not saying you
should use vue, just that you underestimate what good frameworks are
capable of.

On Wed, Jan 6, 2016 at 1:10 PM, Steel Brain notifications@github.com
wrote:

@mark-hanh We have to handle cases with ~5k error messages in one panel,
we have to keep a pool of DOM elements and re-use them in both panel and
bubble and for that we have to design the message elements to be disposable

  • reusable.


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

Contributor

mark-hahn commented Jan 6, 2016

we have to design the message elements to be disposable + reusable.

Actually, vue components would be perfect for that. I'm not saying you
should use vue, just that you underestimate what good frameworks are
capable of.

On Wed, Jan 6, 2016 at 1:10 PM, Steel Brain notifications@github.com
wrote:

@mark-hanh We have to handle cases with ~5k error messages in one panel,
we have to keep a pool of DOM elements and re-use them in both panel and
bubble and for that we have to design the message elements to be disposable

  • reusable.


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

@paulpflug

This comment has been minimized.

Show comment
Hide comment
@paulpflug

paulpflug Jan 6, 2016

@mark-hahn We have to handle cases with ~5k error messages in one panel, we have to keep a pool of DOM elements and re-use them in both panel and bubble and for that we have to design the message elements to be disposable + reusable.

I did exactly that with vue already, of course you can't use the built in for loop, though.
(I used a list of entries which change their text and position on scrolling, each entry is a vue component and so the logic of the list and the entry is seperated)

But back on topic: I would prefer something other than todoMVC or a modified todoMVC which uses something of the atom api at least

paulpflug commented Jan 6, 2016

@mark-hahn We have to handle cases with ~5k error messages in one panel, we have to keep a pool of DOM elements and re-use them in both panel and bubble and for that we have to design the message elements to be disposable + reusable.

I did exactly that with vue already, of course you can't use the built in for loop, though.
(I used a list of entries which change their text and position on scrolling, each entry is a vue component and so the logic of the list and the entry is seperated)

But back on topic: I would prefer something other than todoMVC or a modified todoMVC which uses something of the atom api at least

@steelbrain

This comment has been minimized.

Show comment
Hide comment
@steelbrain

steelbrain Jan 6, 2016

Contributor

@mark-hahn I evaluated several options including view frameworks but linter messages caching is complicated than you think, consider this

class MessageView {
  constructor() {
    this.rootElement = getRootElement()
    this.nameElement = getNameElement()
    this.typeElement = getTypeElement()
    this.messageElement = getMessageElement()
    this.rootElement.appendChild(this.nameElement)
    this.rootElement.appendChild(this.typeElement)
    this.rootElement.appendChild(this.messageElement)
  }
  attach(message) {
    if (message.name) {
      this.messageElement.textContent = message.name
    } else this.messaegElement.setAttribute('hidden', 'true')
    ... same for type ...
    if (message.hasLink) {
      // create link outside of pool, costy
      this.messageElement.appendChild(getMessageLink())
    }
  }
}

Now the difficult thing here is that the structure of each component is different, some are divs, some are spans, some are hyperlinks. Any generic caching technique would never be able to give us results that I can get this way. I can create generic message element view objects and attach and detach messages from them

Contributor

steelbrain commented Jan 6, 2016

@mark-hahn I evaluated several options including view frameworks but linter messages caching is complicated than you think, consider this

class MessageView {
  constructor() {
    this.rootElement = getRootElement()
    this.nameElement = getNameElement()
    this.typeElement = getTypeElement()
    this.messageElement = getMessageElement()
    this.rootElement.appendChild(this.nameElement)
    this.rootElement.appendChild(this.typeElement)
    this.rootElement.appendChild(this.messageElement)
  }
  attach(message) {
    if (message.name) {
      this.messageElement.textContent = message.name
    } else this.messaegElement.setAttribute('hidden', 'true')
    ... same for type ...
    if (message.hasLink) {
      // create link outside of pool, costy
      this.messageElement.appendChild(getMessageLink())
    }
  }
}

Now the difficult thing here is that the structure of each component is different, some are divs, some are spans, some are hyperlinks. Any generic caching technique would never be able to give us results that I can get this way. I can create generic message element view objects and attach and detach messages from them

@mnquintana

This comment has been minimized.

Show comment
Hide comment
@mnquintana

mnquintana Jan 6, 2016

Member

I think a TodoMVC-esque example package for Atom is a great idea, but I agree with @paulpflug that it shouldn't literally be TodoMVC, but rather something that makes significant use of the Atom API.

Member

mnquintana commented Jan 6, 2016

I think a TodoMVC-esque example package for Atom is a great idea, but I agree with @paulpflug that it shouldn't literally be TodoMVC, but rather something that makes significant use of the Atom API.

@mark-hahn

This comment has been minimized.

Show comment
Hide comment
@mark-hahn

mark-hahn Jan 6, 2016

Contributor

@steelbrain, I'm too lazy to argue by writing vue samples. I remain convinced though that it can be done with vue in an elegant way. You haven't presented anything to sway me, not that you should care.

Anything turing complete could do it but we'd have to compare final results to really get a good comparison.

Contributor

mark-hahn commented Jan 6, 2016

@steelbrain, I'm too lazy to argue by writing vue samples. I remain convinced though that it can be done with vue in an elegant way. You haven't presented anything to sway me, not that you should care.

Anything turing complete could do it but we'd have to compare final results to really get a good comparison.

@kanekotic

This comment has been minimized.

Show comment
Hide comment
@kanekotic

kanekotic Jan 6, 2016

@mnquintana maybe something that will use the API and could be an adapt is a 'find TODO comments' on the editor.

kanekotic commented Jan 6, 2016

@mnquintana maybe something that will use the API and could be an adapt is a 'find TODO comments' on the editor.

@paulpflug

This comment has been minimized.

Show comment
Hide comment
@paulpflug

paulpflug Jan 6, 2016

@steelbrain I believe, what you would need is something similar to clusterize.js and I'm sure you could implement and adapt it to your use case in nearly any view framework - only a matter of time ;)

paulpflug commented Jan 6, 2016

@steelbrain I believe, what you would need is something similar to clusterize.js and I'm sure you could implement and adapt it to your use case in nearly any view framework - only a matter of time ;)

@kierans

This comment has been minimized.

Show comment
Hide comment
@kierans

kierans Jan 7, 2016

Contributor

I agree with @mnquintana that an examples need to showcase the Atom API, as well as have several different UI widgets to show what's possible.

Contributor

kierans commented Jan 7, 2016

I agree with @mnquintana that an examples need to showcase the Atom API, as well as have several different UI widgets to show what's possible.

@willnwhite

This comment has been minimized.

Show comment
Hide comment
@willnwhite

willnwhite Jun 2, 2016

Whilst this has been going on, I started to just write functions in my code to create and append elements. It reminded me of HyperScript:

var h = require('hyperscript')
h('div#page',
  h('div#header',
    h('h1.classy', 'h', { style: {'background-color': '#22f'} })),
  h('div#menu', { style: {'background-color': '#2f2'} },
    h('ul',
      h('li', 'one'),
      h('li', 'two'),
      h('li', 'three'))),
    h('h2', 'content title',  { style: {'background-color': '#f22'} }),
    h('p',
      "so it's just like a templating engine,\n",
      "but easy to use inline with javascript\n"),
    h('p',
      "the intension is for this to be used to create\n",
      "reusable, interactive html widgets. "))

I'm a big fan of the HTML-like nesting. I will try it out on my package.

willnwhite commented Jun 2, 2016

Whilst this has been going on, I started to just write functions in my code to create and append elements. It reminded me of HyperScript:

var h = require('hyperscript')
h('div#page',
  h('div#header',
    h('h1.classy', 'h', { style: {'background-color': '#22f'} })),
  h('div#menu', { style: {'background-color': '#2f2'} },
    h('ul',
      h('li', 'one'),
      h('li', 'two'),
      h('li', 'three'))),
    h('h2', 'content title',  { style: {'background-color': '#f22'} }),
    h('p',
      "so it's just like a templating engine,\n",
      "but easy to use inline with javascript\n"),
    h('p',
      "the intension is for this to be used to create\n",
      "reusable, interactive html widgets. "))

I'm a big fan of the HTML-like nesting. I will try it out on my package.

@k33g

This comment has been minimized.

Show comment
Hide comment
@k33g

k33g Jun 10, 2016

Hello 🌍 , cc @thedaniel
I'm starting some quick experiments with Atom and UI:

With RactiveJS

http://www.ractivejs.org/

Learning curve is small, abs Ractive is pleasant to use

export default class MyPlugInView {

  constructor(serializedState) {
    this.element = document.createElement('div');

    let myForm = new Ractive({
      el: this.element,
      template: `
      <div>
        <p>{{greeting}}, {{recipient}}!</p>
        <div on-click="activate">{{message}}</div>
      </div>
      `,
      oninit: function () {
        this.on( 'activate', () => { // fooo
        });
      },
      data: {
        greeting: 'Hello world',
        message: 'Click me!'
      }
    });
  }
  serialize() {}
  destroy() {
    this.element.remove();
  }
  getElement() {
    return this.element;
  }
}

With HTMLElement (Custom Element and VanillaJS)

For small codes, to my mind it's enough: Custom Elements with Classes

Nothing but does the work for small tests

'use babel';

class Small extends HTMLElement {
  constructor() { super(); }
  createdCallback() {}
  attachedCallback(){}
  template(data) { return `<div></div>`; }
  html(data) {
    this.innerHTML = this.template(data);
    this.events(data);
  }
  init(data) {}
  static of(tagName, data) {
    let Element = document.registerElement(tagName, this);
    let instance = new Element()
    instance.init(data)
    instance.html(data)
    return instance
  }
}
export default Small;

And then I use it like that:

'use babel';

import Small from './small';

class MyForm extends Small {
  constructor() { super(); }
  template(data) {
    return `<div>
      <h3>${data.message}</h3>
      <form>
        <input type="text" placeholder="${data.placeholder}"/>
        <button>Click Me!</button>
      </form>
    </div>`;
  }
  events(data) {
    this.querySelector('button').addEventListener('click', (e) => {
      let value = this.querySelector("input").value;
      this.querySelector("h3").innerHTML = value;
    });
  }
  init(data) {
    console.log('Inititialize ...', data)
  }
}

export default class MyPlugInView {
  constructor(serializedState) {
    this.element = document
      .createElement('div')
      .appendChild(
        MyForm.of('my-form', {message:'Hello world!', placeholder:'???'})
      )
  }

  serialize() {}
  destroy() {
    this.element.remove();
  }
  getElement() {
    return this.element;
  }
}

k33g commented Jun 10, 2016

Hello 🌍 , cc @thedaniel
I'm starting some quick experiments with Atom and UI:

With RactiveJS

http://www.ractivejs.org/

Learning curve is small, abs Ractive is pleasant to use

export default class MyPlugInView {

  constructor(serializedState) {
    this.element = document.createElement('div');

    let myForm = new Ractive({
      el: this.element,
      template: `
      <div>
        <p>{{greeting}}, {{recipient}}!</p>
        <div on-click="activate">{{message}}</div>
      </div>
      `,
      oninit: function () {
        this.on( 'activate', () => { // fooo
        });
      },
      data: {
        greeting: 'Hello world',
        message: 'Click me!'
      }
    });
  }
  serialize() {}
  destroy() {
    this.element.remove();
  }
  getElement() {
    return this.element;
  }
}

With HTMLElement (Custom Element and VanillaJS)

For small codes, to my mind it's enough: Custom Elements with Classes

Nothing but does the work for small tests

'use babel';

class Small extends HTMLElement {
  constructor() { super(); }
  createdCallback() {}
  attachedCallback(){}
  template(data) { return `<div></div>`; }
  html(data) {
    this.innerHTML = this.template(data);
    this.events(data);
  }
  init(data) {}
  static of(tagName, data) {
    let Element = document.registerElement(tagName, this);
    let instance = new Element()
    instance.init(data)
    instance.html(data)
    return instance
  }
}
export default Small;

And then I use it like that:

'use babel';

import Small from './small';

class MyForm extends Small {
  constructor() { super(); }
  template(data) {
    return `<div>
      <h3>${data.message}</h3>
      <form>
        <input type="text" placeholder="${data.placeholder}"/>
        <button>Click Me!</button>
      </form>
    </div>`;
  }
  events(data) {
    this.querySelector('button').addEventListener('click', (e) => {
      let value = this.querySelector("input").value;
      this.querySelector("h3").innerHTML = value;
    });
  }
  init(data) {
    console.log('Inititialize ...', data)
  }
}

export default class MyPlugInView {
  constructor(serializedState) {
    this.element = document
      .createElement('div')
      .appendChild(
        MyForm.of('my-form', {message:'Hello world!', placeholder:'???'})
      )
  }

  serialize() {}
  destroy() {
    this.element.remove();
  }
  getElement() {
    return this.element;
  }
}
@RobertBColton

This comment has been minimized.

Show comment
Hide comment
@RobertBColton

RobertBColton Jun 17, 2017

+1 There really needs to be some normalization of view frameworks for package authors. People want to be able to do things in a way that they know won't break in the future.

RobertBColton commented Jun 17, 2017

+1 There really needs to be some normalization of view frameworks for package authors. People want to be able to do things in a way that they know won't break in the future.

@kanekotic

This comment has been minimized.

Show comment
Hide comment
@kanekotic

kanekotic Jun 20, 2017

@RobertBColton I agree, but in any case is difficult, i think the rendering framework is not an issue in general.
My concern is becoming the fact that the liberty of rendering is adding dependencies in a per plugin bases. I would like to really se something different as use what is internal to atom so we don't have a mix of instances and resources being used, so performance and resource usage becomes better.
In any case this thread is 2 years old and we have not got to any agreement neither here or the forum.
So my vote is to just get to use whatever DOM is being used internally in atom.

kanekotic commented Jun 20, 2017

@RobertBColton I agree, but in any case is difficult, i think the rendering framework is not an issue in general.
My concern is becoming the fact that the liberty of rendering is adding dependencies in a per plugin bases. I would like to really se something different as use what is internal to atom so we don't have a mix of instances and resources being used, so performance and resource usage becomes better.
In any case this thread is 2 years old and we have not got to any agreement neither here or the forum.
So my vote is to just get to use whatever DOM is being used internally in atom.

@kolya-ay

This comment has been minimized.

Show comment
Hide comment
@kolya-ay

kolya-ay Jun 20, 2017

Is the open issue means that relaying on etch isn't still a done deal?

kolya-ay commented Jun 20, 2017

Is the open issue means that relaying on etch isn't still a done deal?

@nathansobo

This comment has been minimized.

Show comment
Hide comment
@nathansobo

nathansobo Jul 3, 2017

Contributor

At this point we use manual DOM manipulation, Etch, and React in the GitHub package. I think that's as close as we'll come to a specific endorsement, but we'll remain committed to being agnostic and giving package authors freedom of choice. Baking any view framework into Atom core other than the raw DOM APIs that come with the browser is a liability we're not prepared to take on any time soon.

Contributor

nathansobo commented Jul 3, 2017

At this point we use manual DOM manipulation, Etch, and React in the GitHub package. I think that's as close as we'll come to a specific endorsement, but we'll remain committed to being agnostic and giving package authors freedom of choice. Baking any view framework into Atom core other than the raw DOM APIs that come with the browser is a liability we're not prepared to take on any time soon.

@lock

This comment has been minimized.

Show comment
Hide comment
@lock

lock bot Mar 31, 2018

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

lock bot commented Mar 31, 2018

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!

@lock lock bot locked and limited conversation to collaborators Mar 31, 2018

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.