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):
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.
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.
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).
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.
@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.
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)
I’m ready to help (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