IMO its origins in the gaming community, and all the moderation features that grew out of it, make Discord a much better fit for open source communities than Slack. For example:
- Individuals can block and report other users
- There are tiered mod levels
- Per-community pseudonyms, but a single account makes it easier to track bad actors
Markdown support, including syntax highlighting, is actually better in Discord than Slack already, too.
If you haven't checked out an OSS community on Discord yet here are a few:
A framework like Phoenix would be awesome. Even something more lightweight (Express-like) would be pretty handy. Clojurescript front-end, Clojure backend...
CSS-in-JS libs like https://emotion.sh make "micro-componentization" even easier - pretty much every raw DOM element can be replaced by a domain-relevant/ui-relevant component type. Then if you need to add something beyond styles like state or complex render logic, the consumers don't even know about it because the reference is the same.
Fastify is a similar project that aims to be faster than Express and adds a number of API improvements like baked-in schema validation for routes, logging, and async-by-default APIs.
Haven't used it in production but replaced Express with it in some side projects.
Since server.js is built on top of express it might even be possible to build a variant of it on Fastify instead and get those benefits as well.
This would be a good checklist for anyone considering building a UI framework. This kind of thing is the reason Bootstrap & friends are so large - they do a lot for you.
Still, it isn't entirely obvious under what conditions the methods of a React Component class are going to be called. For all you know they might always be called against the instance.
This might be the way to go for complex dependencies like React where APIs move in and out of the main package, or could be implemented by third parties (like how Preact can supply render and createElement in a mostly-compatible way).
It also makes clear that semver dependencies in package.json are insufficient to describe the library combinations that work in the main package.
"Overall it's not a bad experience. JSX makes HTML feel more at home, but tends to obscure the underlying Javascript. Composition and higher-order components are more obvious in plain JS. If I was writing a library using those patterns heavily I might be tempted to go JSX-free even if bundling with Webpack + Babel."
I could be wrong, but I don't think a LISP macro can transform the structure of the code in the same way that the JSX pragma turns an XML tree "inside-out". For example here's the source for the Babel JSX transformer:
React is my preferred frontend library, so rather than ditch it when I needed to work with a CMS I decided to go JSX-free and write my component in plain ES2015 with Preact's hyperscript/createElement syntax. I thought I'd write up a few tips and a demo widget to show how it works.
Overall it's not a bad experience. JSX makes HTML feel more at home, but tends to obscure the underlying Javascript. Composition and higher-order components are more obvious in plain JS. If I was writing a library using those patterns heavily I might be tempted to go JSX-free even if bundling with Webpack + Babel.
