Design "reference package" for showcasing view frameworks


One of the things that the Atom team wants to do is select a view framework for creating Atom packages that is recommended and supported by the Atom team. Additionally, we would like to enable package authors to use whatever view framework they want or feel most comfortable with. It was suggested by @kanekotic that we could keep a collection of packages that showcase how to build Atom packages with different view frameworks.

I think it would be great if the community could design a “reference package” that could be implemented in all the different frameworks and then links to these packages could be added to the Flight Manual in an appendix.

I’m thinking we would want the package to:

  1. Have some sort of UI
  2. Be pretty simple, but functional (don’t want to make it too hard to toss one out)
  3. Include a couple different control types beyond just text (but should include atom-text-editor in its mini incarnation because of its popularity)

Thoughts? Suggestions?

/cc @mark_hahn @mnquintana @Wliu


I would adjust my vue based boilerplate package vue-hello-world once you found a reasonable reference…


I can see this as a “competition” to see whose framework works the best in Atom. I would like for others to use what I use to make it easier to collaborate. Competition is healthy although I am not talking about anything explicit.


Great @leedohm.

how about extend the current count words (to minimize the impact on documentation). It should be possible to extend it by making the count based on the filtered word of the user input. Something similar to the next mock-up.

As i expressed on the discussion I think one neat thing will be the package generator to have an extra option to on the long run as this examples are generated they can be clone and used as templates for new projects.


I agree that this would be awesome to do. I’m just not sure that the Atom team has the bandwidth to support multiple view frameworks.


I’d be happy to be one of the supporters of this package. There is no reason it has to be a core package, although putting it in the docs would be nice.


I agree with you @mark_hahn if you dont mind i will like to also be a supporter of this package with you :slightly_smiling: . I dont think that the main atom team needs to use their bandwoth on this one, we as community can help :slight_smile:


I was thinking that various community members could publish packages like:

  • view-reference-etch
  • view-reference-vue
  • view-reference-angular
  • view-reference-foo

Then we could link to these packages by the various authors from the Flight Manual as examples. I feel like this spreads the support burden around the community and gives people the recognition they deserve for their efforts.


Maybe test package could a collection of widget for thing commonly used, including something like setting view.

  • An alert to display information.
  • A simple prompt for easy macro (say how many time to repeat X).
  • An example inserting text at the cursor.
  • An example reading line / word at the cursor.
  • A progress bar.
  • A notification.
  • An example pannel
  • An example tab
  • An instance of texteditor
  • An example input / radio button / select with something that act on selection.
  • Something that display html


Let’s do it. Anyone can contribute support to any package they care about. I happen to be between projects so I’ll work on vue.

We have to decide on the app and what to name the projects. I’m not sure I’m in love with view-reference-xxx. (grin)


I think ‘package-template-xyz’ could be expresive enough

getting back in the discussion, and mixing with what is happening in the other post, how about a ‘find TODO comments’ on the editor?


I don’t see that any user input would be needed for that. ToDoMVC has a nice balance of input/output.


Actually it doesn’t need to be like that, because you can add controls to filter the results.

As per the TodoMVC will not show the interaction with the editor, that at the end is one of the most important things i think.

PS. actually i have been thinking and i think that the count works is simple enough as template, a TodoMVC or other may add to much noise, no?. We shouldn’t mix a benchmark project with a basic template project.


I went through my packages and I discovered that the main thing missing is templating, not MV or component frameworks. Space-pen had great templating but vue doesn’t suggest any particular templates. Also the core api provides components like views. Some major components, like pop-ups, are missing, but they are an exception.

What do other people use for templates? The package generator doesn’t use any template at all. The dom is built with pure javascript which really sucks.


@mark_hahn can you explain a bit what you mean with templates?. wouldn’t it be something similar to Vue Components

btw… i created the basic package template with vue (the intention is to modify it as to the example wanted to be implemented). I will try to do the same with other frameworks.


Maybe I’m using the word template wrong. What would the HTML language be called? I guess markup. You can’t enter real html directly into atom package source.

A real template would be something like jsx, space-pen, mustache, jade, etc. The one I use for non-atom projects is called teacup which is very much like space-pen but predates it.

Edit: @kanekotic has corrected me on the html situation. You can input HTML directly into Vue. Even though I have used vue extensively I never noticed this. So my questions about templating don’t apply to Vue.

I know that react has JSX. Do other frameworks also have markup ability?


I think we should split this into 3 different implementations per framework:

  • Template: what should be generated by the next generation of the atom package generator as an empty project for each of the frameworks. (my vue proposal)

  • Example: the current word count example seems a good introduction to creating packages in atom, i think it just need a slight modification to demonstrate how to interact with user input, this will allow the introductory documentation of atom to stay the same and just undergo minimal modifications. (my vue proposal)

  • Benchmark: a more complex solution as the TODO example to help benchmark and demonstrate the qualities of each framework

Thoughts? ideas?


IMHO it is too complex. If we can just agree on one simple app and get them all done we will be doing good.


I have done a small pull request to enable templates in package-generator.