@chadwhitaker thanks for hunting! We couldn't agree more that the design <> development process even in great engineering companies is fundamentally broken. We spend tons of time in design, and even more time in development often reinventing the wheel for problems that have already been solved a million times before by others. We hope we can change the front-end product creation process for the better!

@bdrhoa We're built to be used by product teams (engineers and designers working together on Mason) and offer a few different packages based on your team's size. We start with packages for teams of 5, but we work with companies much larger and much smaller as well. We can definitely work out something special for your non-profit / education focused team. Shoot me a note at tom@trymason.com and we'll work it out!

@dainiskanopa Thanks for raising this! We actually use Mason ourselves; a portion of our site is built with Mason components! The waitlist experience and the register experience, for example, are fully Mason-built and managed. So to answer your question, the product itself works well and is functional, we're just polishing things up in the builder and adding more functionality, hence the waitlist. We plan to open soon and roll out a number of exciting features immediately!

@dainiskanopa Our waitlist screen is a Mason component! You can inspect the code on Mason's page using a web browser debugger. Link: https://app.trymason.com/sales

@dainiskanopa Hey Dainis, I just put together a quick gif of a build experience to give you a little bit of a sneak peek. We'll be planning to open up the product to everyone soon.

@dainiskanopa part two:

@simongu Any chance I can get a login to try it out?

@juanalzaga thank you! 100 points @hellodusko for the awesome design work!

@shreyaa_ratra thanks for the suggestion! We're definitely interested in providing super powers to front end development and product teams!

@patrickjmq It's such an interesting space to be in because so many have tried to attack the problem from so many different angles. I think where other tools get it wrong is they optimize either too much for the builder experience (leaving you locked into their platform and unable to do anything "real" in custom code), or they optimize too much for the developer experience (like an open source library that *only* developers can use to hack into bits to reinvent solutions that are already solved elsewhere) We're treading right in the middle. Our builder lets you drop any pixel perfect design on top of your features, and the features themselves are already pre-packaged standalone units that just do their own job really well and nothing else (like authentication + 2FA for example). Where we differ from others who came before us is in a few ways: 1) Our features live in your codebase, but can be edited/configured in Mason. No more getting stuck in a platform that only does a small amount of what you want.. anything that we don't have you can still do in your custom code 2) You can go as shallow or as deep as you want on the technical level with Mason features. You can drop in simple UI features with no logic, or you can drop in full feature flows and leverage our callbacks to plug in any custom logic you want, so things interplay nicely with the rest of your app. As an example, our waitlist is run on Mason and we inject custom callbacks directly into the feature: Here it is in React (but this could easily just be HTML with our CDN as well): " import { ForgotPassword as MasonWaitlist } from 'mason-library'; ... < MasonWaitlist id={this.props.waitlistId} willSendData={this.props.willSendData} / >"

@patrickjmq definitely. we're certainly mindful of the long history of attempts for this type of product, and the high bar for usability and utility. it's hard to create something more powerful and efficient than writing code, but we think the tools are finally mature enough to make it possible.

@thomasmclaughlin You're speaking my language. Web development is such a pain now with the need to understand a billion and one different scaffolding patterns to build anything. Platform lock in is real, you seem like you are coming at the problem with the exact same set of pain points that I (and many other) feel today. Beyond excited for this, hopefully I clicks with me when I get to use it because if it does, i'll be evangelising the hell out of it.

@kareem_sabri I'm really rooting for you guys with this, from the noises i'm hearing it sounds like you might have the solution pretty much every dev has been looking for. I've subscribed to this and will be following with greeeeat interest.

@patrickjmq Thanks Patrick - we're happy to have you rooting for us. We're coming at this from a developer's perspective by trying to reduce repetitive coding of utility UI and long or overly technical update and deployment processes for trivial UI updates. Some more detail is in our docs http://docs.trymason.com/ Shoot me an email at kareem [at] trymason [dot] com if you're interested in testing out the product, it sounds like you've thought about this problem a lot.

@thomasmclaughlin I love the mission behind this - super ambitious but necessary.

@abadesi thank you!!

@thomasmclaughlin hey Thomas. Can I get an invite to try this out?

@tashugudokin Thank you!

@airlabs_io Hey Chris -- absolutely! We'd love to have you try us out. We're letting folks in off the waiting list as quickly as we can and you'll be able to try us out to see if we're helpful before committing to anything up front

@laander1901 Great questions -- thank you! - How does this integrate into unit/E2E testing workflows and CI/CD? Mason features sit within your codebase so they can be tested just like any other line of code. A lot of our own app is powered by Mason features and we test the Mason parts and the custom code parts the same. Drop me an email at tom@trymason.com and I'll share a few test cases we have in production today (we're running Jest and CircleCI, but you can swap for whatever testing / CI flow you use) - If you can publish updates outside of the typical deployment pipeline, how do you avoid introducing runtime bugs between the components and the rest of the codebase? Every Mason feature is a self contained bit of functionality that just does its own job really well, and nothing else. There won't be any side effects of dropping our features in alongside the rest of your code since all of the logic is self contained in the feature and all of your styles are uniquely namespaced to avoid any conflicts. It really just... works :) *But* if you do make a mistake, you can make edits in the Mason builder that show up live instantaneously after you publish. Mistakes do happen, but with Mason you don't need to wait to deploy a hotfix to make changes anymore. - Are you using iframes, shadow DOM or something else for embedding the components? If not, wouldn't unintentional style overrides be a major hassle? We uniquely namespace all styles for each feature you're using in your app and generate a custom stylesheet that won't conflict with any existing styles elsewhere in your app. All you do is drop in the Mason feature(s) with their unique IDs and on page load our API injects all of the styles and logic to make that feature functional. We package up all styles and JS for you and inject directly into the DOM so there's no iframe hackiness or anything like that. Our approach makes it possible to drop Mason features into virtually any codebase without unintended side effects. - It seems like there's only 3 callbacks supported in the component API (willFetchData, ​willSendData, ​didReceiveData); are data not meant to be passed between components but server-to-server? Our callbacks actually let you do anything with the data coming into or going out of any Mason feature. You can hook into any step in the data transfer to modify data, restructure it on the fly, write it to a store, send it to your server, or use it anywhere else in your application. Think of those callbacks as hooks into every meaningful step of the data transfer where you can use that data however you'd like, just like you could in custom code. Without the headaches of rebuilding it from scratch of course :)

@laander1901 great questions. Tom covered a lot of it but I wanted to add a couple points. - If you can publish updates outside of the typical deployment pipeline, how do you avoid introducing runtime bugs between the components and the rest of the codebase? we support a draft/publish workflow, like a blog. as owner, you can test your pre-published modifications in your production codebase while your users are using the published/tested version. - It seems like there's only 3 callbacks supported in the component API (willFetchData, ​willSendData, ​didReceiveData); are data not meant to be passed between components but server-to-server? more callbacks are coming soon. providing data directly on the client is definitely in the works.

@thomasmclaughlin I had a lot of the same reservations as @laander1901 and gave you an upvote after reading your detailed reply. Which made me curious, your marketing seems targeted toward Product Mangers, but it seems like you might also direct a bit more clarity for those stubborn devs (like us) that aren’t as easily convinced. Cheers to an awesome idea and execution so far!

Thank you so much @moeamaya!