Helios, HashiCorp’s New Design System | Hacker News Reader

Helios, HashiCorp’s New Design System

hashicorp.com

60 pointsshcheklein10 comments

I’m surprised by the choice of Ember.js. Are many organizations choosing Ember for new projects these days?

React now seems like the conservative choice, with early adopters maybe using Svelte; I haven’t heard much about Ember in years. I’m not a web developer, though :)

I'm also surprised by this given that (AFAIK) Hashicorp uses Next.js for their docs. Perhaps they're planning to ship some kind of generalized multi-framework component library, and Ember is just the starting point?

Likely a different team / org run differently?

A fair number of the hashicorp tools use ember already, including Nomad, Vault and Boundary. I think Boundary is newer, so they're likely still using it for new projects, though both Consul and Waypoint aren't using it based on the repos.

Hashicorp's front end team is largely composed of former Heroku employees.

They've continued to use the same tools as were employed by Dashboard.

It's a shame Ember is nestle extinct IMO, but oh well.

I don't see anything very unique looking here. I think they should have just gone with an off-the-shelf library.

I find myself asking why this is so common. I guess this is welcome because it's based on something other than React?

My last employer (or the company that acquired them, rather) had a team of ~8 working on a design system/component library , trying to encourage adoption across 5+ disparate apps. Our app used Angular. They used React for their implementation. No consideration for mobile whatsoever.

While I understand the desire for consistency in UX (so that it's harder to tell 3/5 products were acquisitions...), for a company that was so focused on "becoming cash-flow positive" they seemed to have no qualms about reinventing the wheel in the UX space.

I think you inadvertently hit the nail on the head here. UX teams looooove to geek out about design systems. If leadership doesn’t understand design (which, let’s face it, they typically understand less than software engineering) the UX folks will get to run wild on this project. Couple that with the fact that in 2023 “good design” has a strong center of gravity and you end up with tons of these “systems” that look the same.

And, by the way, most of these systems can’t be used outside the context of authoring teams’ apps anyway because there are tons of little specific integration points that aren’t included in the system itself!

> I think they should have just gone with an off-the-shelf library.

This is typically not the case in larger orgs with products that need a consistent, unique feel and branding - that's why you see so many design frameworks popping up. Or sometimes you just want components for a particular tech stack (though you could integrate one of the existing ones with your JS/TS codebase, too), which is also what HashiCorp has done here (components for Ember.js).

However for smaller teams I don't think that this approach makes much sense - I've seen 5 person teams spend time on creating their own component library when it felt a lot like bikeshedding, when there was actual functionality that needed to be implemented first. For most out there, just grab Bootstrap, or something specific to your front end framework/library like PrimeVue/PrimeNg/PrimeReact and first make it work, then consider customizing it.

Then again, you don't see many companies out there with products that look like they're out of a Bootstrap tutorial, so go figure. I've actually heard people disliking fonts like Open Sans as well because of how common they are - seems like many want to set themselves apart. Not sure how much of a worthy goal it is, there's nothing wrong with software that works but looks a bit boring (as long as the UX is great).

It looks kind of like Vaadin DS, but I’m digging the subtle differences.

Reply on news.ycombinator.com