It feels like by adding styling I could make those who click on the “feed” link, but don’t yet know what RSS is have a much better experience than seeing unstyled XML and being confused.
The class name on the HTML element definitely makes me want to start using more expressive class names in my code. (Doesn't seem I'm able to copy/paste it into a Hacker News comment)
They were considered, I was on the team that considered them. (I work at Culture Amp and at one point was leading the Design System team).
To be clear: embedding Elm in React is easy (we host the main NPM library for doing so: https://github.com/cultureamp/react-elm-components). But embedding React in Elm is harder, as Elm doesn't give any easy "escape hatches" to interact with native JS code.
The main opportunity is to use Web Components. Elm knows how to render any HTML component, including `x-my-custom-button`, which could render using React or something else. We looked into options for this, including prototyping https://www.npmjs.com/package/backstitch as a way to embed our React components as Web Components for consumption in Elm. (No open source packages existed to do this at the time).
We also did quite a deep dive on using Stencil, which has a React-like API, to create web components for both React and Elm - even including publishing new plugins for the ecosystem to generate Elm bindings for your web components. Kevin went into some of the detail for this in the post if you're interested.
I work at Culture Amp and was once team lead of the Design System team.
Its not hard to justify the team. If 4 front end engineers in a design system team can solve some common problems (writing components, improving accessibility of existing components, writing docs, answering technical questions etc) in a way that makes 40 product facing front end engineers more effective than 44 who don't have access to the team... then the team is a net positive.
At our scale we'd need to give a 10% improvement in efficiency to the product engineers. Both the engineers in product teams, and the various levels of leadership, have seen enough to believe we're making at least that much of a difference. Like almost any other company... measuring that accurately is a nightmare (and would require a significantly larger team just to measure ) but its a safe enough bet that we continue to invest in it.
(I'm a front end engineer at Culture Amp, and have been involved in hiring)
Perhaps the wording in the blog post is too strong, because people in this thread seem to be interpreting it as a hard rule. The wording was:
> When someone tells us in an interview they’re excited about working here because they like functional programming (say), we count that as an indication they might not be a good fit.
When we do interviewers each person fills out a scorecard for the candidate with several criteria: things like technical skills, communication, UX thinking, interest in the company product/mission, etc.
Under "technical skills" I would usually have counted interest in Elm as a positive, as long as they weren't expecting to only write it. As I mentioned elsewhere in the thread, they'd also be likely to be contributing to Ruby on Rails codebases... so they better be open to, and maybe even excited by, different paradigms, because that's going to be part of the job.
In our interviews one of the things we look for is people who care about our mission (improving workplace cultures, basically). Its not a requirement but it is one of the factors when it comes to making a decision, particularly if we have more qualified candidates than roles.
> If someone came excited about Elm _and_ was interested in the company's product that was fine.
I'd even say if someone is excited about Elm _and_ was interested in making a great quality product (great UX, accessible, performant, maintainable etc.) that would also be a good fit.
I also mentioned above that the engineers we hired to work on features that happened to have Elm front ends would have been working on Ruby on Rails backends most of the time, and we generally expected engineers to be willing to jump into both sides of the stack, even if they specialised in one or the other. A person who is really excited about functional programming and joining only for the chance to work in functional programming languages might end up grating against working in a rails codebase. That's the sort of practical thing we were trying to avoid. (The same would be true today for candidates who are super excited about TS / React / Next.js - they're still going to be expected to occasionally jump into whatever backend stack their team is using).
I work at Culture Amp and have been involved in hiring decisions, including for people who were excited about Elm so happy to comment here. As others have guessed, this is an "indication" not a "rule", and it was more about people who were applying _only_ because of the tech stack, rather than a sense of wanting to build a quality product, or alignment to the company's mission (improving workplace cultures). We hired plenty of people who mentioned Elm. I mentioned Elm in my interview.
Part of the reason for this is very pragmatic: during the time when Elm was in common use at Culture Amp, almost all of the APIs that Elm would have been talking to were written in Ruby on Rails, and our engineers were expected to be able to contribute to work that required changes in both the Elm front end and the Rails API. If someone was a functional language purist, and only wanted to work in say Haskell on the backend... then they wouldn't enjoy being on one of our product teams where writing Ruby on Rails code was part of the day-to-day.
As an engineer at Culture Amp, I strongly agree with all of this, especially:
> Actually improving employee engagement is far from solved or commoditised, and I believe that anyone that can bring an original idea that can be proven to lead to real-world change can still find a place in this industry.
OP it sounds like you and your co-founder had good intuition and insights into what the industry needs. But as indeed30 mentions the market is mature, the competition is strong, the expectations of quality and a certain feature breadth are high, and you'd probably need some decent sales skills to get a look in.
Well done on picking a good problem and giving it a shot. As someone who failed a startup at a similar stage, it sounds like you've walked away at a good time, learned good lessons, and hopefully you've got good opportunities ahead.
That was a helpful read, thanks. My company (also in Melbourne!) is probably one stage of growth beneath this. We have “verticals” and “teams” but don’t really have the layer in the middle yet (“domains”).
As we’ve grown from only a few teams, to multiple verticals, we’ve tried to jump straight from unclear boundaries and implicit APIs to fully versioned services and packages.
Thinking about these as solutions to communication problems, where the problems differ in degree depending on the number of teams interacting with it, is a useful way of framing the discussions.
Hopefully it brings some clarity to discussions about when the light-and-loose methods are okay, and when the more heavy processes are justified.
I used Haxe full time for several years for web development (even started a startup with it!)
It predated Typescript, so at the time the killer feature was being able to write type-safe JavaScript, and being able to share code with a backend which is potentially another language (like PHP).
These days I’m at a company with a lot of TS, and too many other languages (Elm, Ruby, Kotlin, Elixir...) so we’re not looking to add something like Haxe, but I often still miss the expressive type system, the really nice language server integrations, having the multiple output targets so it’s the same language everywhere, and the type safe macro system.
So I often use Haxe for hobby projects still, but then I miss things from the JS ecosystem. You have access to NPM but there’s no equivalent project to DefinitelyTyped. Some of the tools integrate well (webpack as an example), some don’t (Jest). React works, but the way JSX works doesn’t integrate as nicely with the language server. Etc
I also missed some modern es6 syntax. Haxe finally got arrow functions in v4. The thing I’m excited by in this release is module level fields - previously everything had to be in a class, now they don’t. Haxe was already good for writing functional style code. Now when you read the source code it’ll look like it and not have the “class” keyword when you don’t need it.
Amazing work! I'll be following along keenly... and glad to know there's an exhaustive approach being taken to figuring out if anything else was affected
I’ve used it for web (my failed startup was in Haxe, my side projects still are mostly Haxe).
To be honest these days I mostly just use it as a “better JavaScript” because I’d prefer my backend to be NodeJS rather than PHP or Java or sone other Haxe target. But I really do prefer it to JavaScript, even with Babel and Flow and ES6 and all the things to modernise Js.
One advantage Python might have is that the dependencies you use are human readable, they're not compiled, minified or obfuscated. This in theory would make auditing dependencies easier, but I imagine 99% of the time people aren't thoroughly auditing.
The “containers” thing they’re doing to have separate containers with separate cookie jars, is something I’m loving that some die hard Chrome fans have said “I want that” when I explain it to them.
It allows me to have a work container logged in to work trello and Gmail, and a personal container logged in to personal trello and Gmail. It also allows me to have a FB container so I can stay logged in there, but do all my browsing in other containers so they don’t know which other sites I’ve been visiting. That’s a feature I didn’t know I wanted until they built it.
It feels like by adding styling I could make those who click on the “feed” link, but don’t yet know what RSS is have a much better experience than seeing unstyled XML and being confused.