Comments URL: https://news.ycombinator.com/item?id=44421141

Points: 1

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=40235557

Points: 11

# Comments: 7

https://jasono.co/blog/software-engineering/ - mostly focused on front end, and a lot of older posts about the Haxe programming language.

https://jasono.co/blog/personal/ - mostly about faith (I consider myself both Christian and Agnostic)

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.

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.

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).

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.

> 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.

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.

Comments URL: https://news.ycombinator.com/item?id=28725791

Points: 3

# Comments: 0

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.

From Firefox 72 permission prompts won’t be shown unless they’re triggered from a user interaction.

From the blog post:

> Notification prompts are very unpopular. On Release, about 99% of notification prompts go unaccepted, with 48% being actively denied by the user.

https://blog.mozilla.org/futurereleases/2019/11/04/restricti...

I’ve heard Chrome is moving in a similar direction

We pick a tribe and can be loud and obnoxious in support of them.