LocalDev Tool (Ember Hearth Next)

Hey there, wanted to share something new that I’m starting as a spiritual successor to Ember Hearth and inspired by the recent release of Vue GUI.

As a heads up I’m currently in the outlining phases of the project and feature gathering but wanted to share my thoughts and plans early so I can get community help or steer the project in the right direction. Ok, on to the pitch:

LocalDev is a daemon or full Electron app that allows you to manage development projects of all types. In this way it works more like hotel or Laravel Valet. The idea is that from the GUI a user can:

  • Create new applications
  • See their projects
  • Launch their app via a .localhost TLD domain for easy development without port numbers or port colision
  • View logs
  • Manage Tasks
  • More

While I like the idea of the Hearth development as an Ember development GUI, I think that a flexible tool could see more widespread adoption (both in the Ember community and outside of the Ember community). So to me this means that similar to Laravel’s Valet, LocalDev could have plugins that attach to certain projects. This means that an Ember project could have integration (similar to Vue GUI) like:

  • Searching for Ember Addons from EmberObserver
  • Running Ember CLI Commands
  • UI for Ember Generators
  • Working with Ember CLI Deploy
  • More

Through a plugin architecture we could also support more generic JS projects with features like:

  • Running NPM Tasks
  • Searching the NPM registry
  • Running NPM security audits

Since every Ember project is also a Node/JavaScript project, this could be auto detected and users can have the features from both plugins for their project.

Here’s some screenshots of the rough idea/layout (I’m not a designer):

And here’s the expanded view of the sidebar

That’s a high level view of what I’m starting to think and now I’m opening up for questions/help/interest.

I had talked to @NullVoxPopuli about possibly moving forward on something like this.

9 Likes

For those interested the source to the design app is GitHub - rtablada/localdev-design

1 Like

I have some design ideas, even though I’m also not a designer, I think we could borrow a ton from the Vue GUI.

Something I’d like to see is a way to install add-ons and change configuration options via the GUI (and I’m sure, with the right plugins interfaces (consumed via engines?) We could do … Anything. :smiley:

Super exciting!

This’ll big big for ember if we can get it used by react people as well ( maybe via some generic react plugin ( currently have no idea what this would offer outside of running package.json scripts atm ) )

If this is going forward as the implementation repo, and not just design. I’d also like to push for typescript. :slight_smile:

Check out JSUI by Kitze; it’s a new tool that sounds like it has at least some overlap. I haven’t looked into it much, but at least it would probably be good to be aware of it and how similar or different it is. GitHub - kitze/JSUI: A powerful UI toolkit for managing JavaScript apps

Yeah I’ve seen JSUI. It’s got some similarities, but a few major differences:

  • It’s only focused on JS Based apps (vs Localdev, Hotel, and Valet which can work with any app)
  • Plugins are globally installed and active on each project (vs detecting and mounting on a per project basis)
  • It focuses on providing a blueprint scaffold tool (vs integrating with the existing tools ember g, yeoman, rails g, laravel make:*, etc)

I think there’s definitely stuff to learn from it though and thanks for the reminder!

In the most simple form LocalDev is really Hotel with plugins and a standalone/menubar app instead of daemon and browser window (although we probably could make it executable as both).

  1. This looks really could and I am sure my team and I would find this useful.
  2. Is the plan for this to be an Ember App running in Electron?
  3. How can I help?

The plan is that the main shell would be an Electron app or a Daemon: with an Ember App for the UI.

For plugins I’m thinking that plugin authors would have access to:

  1. Create a special Ember engine if they want to use Ember
  2. Have access to the plugin area element if they want to use a different framework or UI tool (or vanilla JS)

How you can help

For now, try out things like Hotel or Laravel Valet and let’s gather feedback/improvements that you’d want to see here.

Design and UX is also a HUGE place where I’ll need a lot of help.

Right now the action steps in terms of code aren’t great since it’s in planning phase.

1 Like

Update on a list of next steps:

  1. Gather requirements/features
  2. Create basic server to manage servers (probably forked from Hotel)
  3. Create Electron Shell
  4. Create Ember app to view projects and logs
  5. Create plugin system
  6. Create log plugin
  7. Create node/package.json plugin
  8. Create Ember plugin

If you have features you’d like to see or places you can help out, let’s keep discussions here!

1 Like

I can kinda help with UX and stuff. But I’m not sure how to best communicate thoughts / feelings as I don’t practice this skill in written words.

Related: Let's GUI · Issue #1 · gossi/ember-cli-create · GitHub will come back when flushing my thoughts into a blog post

This is a really neat idea that I think could really help new users to ember as well as those of us who work on multiple ember/react/vanillaJS projects. One thing to consider is how it might handle different versions of node or other global dependencies (e.g. different react or ember versions) when switching projects. I currently use NVM to mange node versions but it would be great if this tool could just manage this for me.

I am an interaction designer as well as an ember/react developer. I’d be happy to help get the UI/UX sorted out and contribute where I can.

Nice work!

2 Likes

@acorncom and I were discussing something very similar recently - basically how developer tooling that leverages Ember’s strengths as a conventional framework could be really helpful on face value, as well as a really good marketing / hype generation channel.

I like where this is going, but I’d like to suggest that interop / support for arbitrary non-Ember projects should not be a goal.

I think it ultimately detracts from the value of this project for two reasons:

  • Getting other JS ecosystems on board with contributing to and growing a tool built around Ember seems unlikely, for the same reasons that it seems unlikely that we’d convince a meaningful number of Ember devs to go learn and contribute to Vue GUI.

  • I think going overly generic here will distract from our ability to ship something useful to Ember developers in the shorter term. Trying to be a be-all-end-all GUI for any project under the sun is an incredibly ambitious task. But shipping a GUI that’s helpful for Ember apps? Much more manageable.

In other words - even if it’s more work in the long run, I’d say start with Ember-first and expand to other ecosystems later, because we’re far more likely to actually ship anything if we ship Ember-first.

3 Likes

I agree, focusing too much on cross-ecosystem could get us into trouble.

I’d hope that cross-ecosystem modularity would be more of a consequence of the architecture - like using engines for plugins that are automatically wired up / mounted on to a route named after the plugin name or something.

An easy UX thing for us to for ember-folk would be to auto-redirect to that engine if we detect there is only one plugin installed.

Or we have the main screen kinda just be general project management where you can configure where your projects are on your system, and display cards and general info about each project. Maybe additional info could be acquired through an engine’s registered ‘project-info-analyzer’? Idk, just spit-balnin’.

I propose a monorepos for all the core plugins and app shell.

Ryan, do you have anything pushed? I can stab at things for a bit this week.

Also, I don’t know if it was mentioned here, but something neat we could do to have better messaging with ember-cli is to have the CLI publish json messages or something that Hearth Next subscribes to. (Not my idea, it’s Tom’s)

Sorry if it felt like I was pushing for “cross-ecosystem” as part of the pitch.

Like @NullVoxPopuli mentions, that is actually more of a consequence of the design.

I think in terms of architecture it’s still best to work with:

  1. Fork or heavily inspired hotel project manager
  2. Add wiring for “project-info” to allow NPM scripts/Ember commands
  3. Add Ember plugin

I don’t have anything up at this time other than the general repo from the design above: GitHub - rtablada/localdev-design

If anyone is ready to help, let’s try to setup a voice call/screenshare via Discord.

1 Like

I’m ready to help :slight_smile: (not immediately right this second, but in evenings, typically) Though, I just started watching Season 2 of The Iron Fist, so I might have to finish that first :slight_smile:

2 Likes

Update from my side of things.

I’ve got a bit of free time coming up and want to work on the core internals (storing projects, plugins, server daemon, etc).

If anyone wants to help out or pair on this let me know @gossi @NullVoxPopuli if you want to jump in a Discord call some time soon!

1 Like

I finally managed to write down my thoughts into a blog post: https://gos.si/blog/thoughts-on-improving-developer-ergonomics-for-emberjs/