Why isn't discuss.emberjs.com an ember app?

1

Hi, doing view->source on this site I can’t see ember being brought in anywhere. Is there any particular reason why Ember was not used for this site?

2

This site is using http://www.discourse.org/, which is definitely built with Ember.js.

The repo is here: https://github.com/discourse/discourse

1 Like
3

Thanks for the reply, I was not aware of discourse, looks nice.

4

@Ben_Glancy Install Ember Inspector - Chrome Web Store.

Open this site and click on ember inspector in chrome dev tools. You’ll be able to see all the information related to the ember app.

5

As per ember inspector this site is. But surprisingly emberjs.com is not an ember app.

6

I think emberjs.com not being an Ember app is a powerful statement. Ember is for ambitious apps, which a brochure/documentation static site is very much not. Having a favorite framework can be like trying to turn everything into a nail because you have a hammer, so it’s good to be mindful that an app framework isn’t the right tool for everything.

(Coincidentally, parts of the site actually are written in Ember)

3 Likes
7

Ember JS website and the docs (api and guides) are part of a static website generated by a tool called middleman which is a ruby based tool.

I suspect there are at least a few reasons:

  1. These sites are basic static sites and do not need a lot of frontend JS app like features (to Kyle’s point)

  2. These were established long before Ember was really mature, so the tooling represents when these projects (website, guides and api docs) were started. Middleman really is a good tool for the job.

  3. Not enough bandwidth at the moment to actually port things over, even if we wanted to.

  4. It is more complicated/expensive/time consuming setting up a backend than placing some static content on an S3 bucket.

That being said I would like to explore this idea of why ember is not great for a static/brochure site? I certainly appreciate the “if all you have is a hammer everything looks like a nail” argument. But surely there are some other technical and specific considerations.

I am not sure there is anything inherently in Ember that precludes this use case other than an argument that these don’t need to be JS heavy websites. But even with that this could be a good test case for SSR (Server Side Rendering) of Ember.

That being said what would these projects gain from being ported over to an ember js / ember cli project?

That is an interesting question. A few things I can think of.

  1. Showcase ember by eating its own “dog food” so to speak. So maybe marketing benefit.

  2. Richer interactive site. Could probably do some cool things with fancy components that make browsing the website and guides and search a lot nicer.

  3. Static offline mode. Have a data api that serves the markdown data into a JSON API format. Builds some adapters that treat all the markdown content as fixture data. Have richer modeling of the data itself. Guides, API docs, HomePage Content, etc lots of possibilities and nuance could be ensconced in the model layer.

  4. Decouple the data API from the app design. Don’t like the way the API docs look or work? Well build your own version with different interactivity and just consume the API.

  5. Make the publishing process a lot more streamlined. Get content onto the website is not about mucking with the middleman tooling but just about getting content into a publishing flow and pipeline that feeds the public api of the web properties. Content is just well specified and versioned markdown and code files.

  6. Bubble up other content from the ecosystem (meeting notes, rfcs, popular pull requests, any content that could pipelined into the data api).

  7. Build better experiences for mobile and other view ports. The fixed width design of the Ember JS website is kind of long in the tooth.

  8. Canary in the coal mine. Make the ember js website a first class ember app that runs on the canary or beta channel. If a bug crops up in the framework it is going to be evident on the website. More of the dog food argument.

  9. Experience building a large and evolving website/app that it on everybody’s radar. More that just a todo app. This becomes a showcase of how to do things with ember.

Now all this presupposes that the above are worthwhile given the time investment this might take for the core team.

And words are cheap (especially mine) :smile:

5 Likes
8

Those are a ton of awesome ideas @eccegordo!!

The one that especially caught my attention was bubbling parts of the ecosystem. As one of the local meetup organizers, it would be neat to have some space on the site for our content, as well as a single place to check out other meetup content. We get some of it through Ember Weekly, but I think there might value in rolling some of it into the main site. If a primary selling point of Ember is the community, we could probably do more to advertise our commitment to that.

9

Yeah, these are just ideas. A lot of implementation details to consider.

But most of the important content is really just a bunch of markdown files. So if someone could figure out how to build an adapter or data layer around this a lot is possible.

This might actually be a pretty good meetup hack night project if some meetup group were so inclined. Perhaps as a prototype to test the idea.

I imagine there have already been some background discussions about a major revamp of website so maybe this is already on the table just a matter of time and priorities.