@OvermindDL1 Yes!, Here are some additional details…

Architecture Notes

• Elixir & Phoenix Backend
• Light JS frontend
• After initial page load, channels are used for UI rendering. HTML is rendered on the server and pushed to the client over channel
• Originally build as a stand-a-lone single app.
• In the process of refactoring it to be extensible through plugins
• We will be using it for a client framework with initial support for the chat app and our commercial WebRTC soft phone (delivered as a plugin)

Current Features Implemented

• Multiple channel types (public, private, direct messages)
• Favourite channels
• @mentions with audible and badge notifications
• Presence with override
• Message editing, pinning, starring, deleting
• About 30 slash commands (create room, invite user, …)
• Autolink and preview urls
• Drag and drop file update with image and video preview
• Emoji support with picker
• Message reactions
• Unread message handling
• Customizable Role and Permission system
• Some basic Bot experimental support
• Code syntax highlighting
• Profile editing and admin pages
• Very configurable
• and more …

Feature Roadmap

• Peer to peer Video
• Peer to peer Audio
• Presence adapters for on-the-phone presence with Asterisk PBX
• Mobile clients and Push notifications
• Email and SMS notifications
• OTR Conversations
• Live chat feature
• 3rd party integration (web hooks, Rest API)
  • BitBucket
  • Github
  • Jira
  • …
• OAuth and LDAP
• XMPP Integration
• Internalization (Much of the UI uses gettext already)
• UI theming
• and more …

Ok, I’ve pushed the source of the project (pre architecture change) to the UcxChat temporary repo. I’m working on hosting it now. Should have something soon.

Please be easy on me. There is some code in there I’m not proud of and needs to be refactored.

In terms of paying the rent that may have been a wise move - however I continually wonder about the wisdom(/benefits) of using something like Angular in the first place. And while Typescript is great for supplying type information to IDEs for coding assistance and while I like static typing support there is this:

Non-goal: Apply a sound or “provably correct” type system. Instead, strike a balance between correctness and productivity.

Sound’s to me that while being “statically typed”, TypeScript is choosing to be “weakly typed” - i.e. the primary motivation behind TypeScript is to bring in the OO baggage that many Java/C# developer’s are already familiar with.

I spent a significant amount of effort to “skill-up” in Angular 1.x, getting to the point where I started to see the wisdom in “How I’ve Improved My Angular Apps by Banning ng-controller” (Tero Parviainen’s “Build Your Own AngularJS” is a great piece of work btw.). Now Angular 2 fixes a lot of issues but by being an “opinionated framework” it’s “view of the world” is the one-and-only “correct view of the world” and ultimately it still feels way too heavy-weight and too OO (in a Java EE type of way).

In my opinion Angular’s adoption was primarily driven by corporations preferring open source backed by “big names” (i.e. Google - even though this also implied that Google is motivated by it’s own agenda and not really motivated to listen to anybody else) and backend OO developer’s wanting to do front-end development while largely staying away from the browser’s DOM.

The other issue with a heavy-weight framework is the temptation to move actual business-domain-logic into the front-end which architecturally speaking is a “bad idea” (a disconnected, browser-based app is a different kettle of fish). While a UI should remain responsive, it should focus on performing “UI-logic”, not business logic.

Working through jQuery, Angular 1.x, Node.js, React.js, and Elm I’ve become more reluctant to invest in frameworks and favour highly focused, small libraries (which compose well with other highly, focused, small libraries).

So it makes me wonder if @OvermindDL1 is onto something with a “plain JavaScript + Polymer (more generally, web components)” approach; maybe that should become the contemporary equivalent of adopting jQuery in 2006-2008 (unless you are adopting a “compile to JavaScript” language that has more going for it than TypeScript).