Even though it's much slower, GPT 4 is way more consistent than 3.5. The OpenAI APIs have had lot of flakiness in the past couple of weeks, we retry requests up to 10 times to work around this
Hey HN. My co-founder and I begun working on Vidu 10 months ago. We are both ex-Intercom - he ran the outbound sales team at Intercom, I was an early engineer.
Vidu aims to help creative sales and marketing teams stand out in a prospect's inbox by allowing them to create hyper-personalized content in seconds. Our first iterations of our product focused on just-in-time use cases [1], it takes about 10 seconds to generate a GIF with our extension and pop it into an email. We're now working on adding integrations to unlock automated use cases, our first Zapier integration was released in beta this week.
On the tech side, we use Blender (for motion tracking and rendering [2]), Ffmpeg, Elixir/Phoenix and Ember.js and we host on AWS.
We decided early on to bootstrap and focus on building and selling. Happily, we recently reached profitability and we're hoping to soon reach a point where we can begin to expand our team.
Ah yes, I didn't realize "ember build" produced a development build. For comparison, create-react-app always builds in production mode to eliminate this exact scenario!
I think that's probably a good change to the default. Today, `ember build` is analogous to `ember s`, and most people deploy to production with `ember-cli-deploy`.
So many frameworks have borrowed from Ember more than Ember itself becoming mainstream I'd like to see the idiomatic approach become widespread whatever the idiom
At Intercom, we've been incrementally upgrading our almost 6 year old Ember app to Octane as the features have landed over the past 8 months. Our app continues to be in great health and we continue to ship hundreds of times a day with a constant stream of features that our customers love [1]
Octane is a huge leap forward for Ember. Its APIs are extremely well designed, composable and cohesive. The new Glimmer components and @tracked properties have resulted in waves of negative diffs as we refactor parts of our app to Octane and, IMO, are an advancement in the state-of-the-art component state tracking / reactive UI.
If you've tried Ember before and were turned off by some of its slightly weird APIs (computed properties, component APIs like tagName, classNames & event handling, the ember object model), you should take a second look.
With Octane, Ember is a framework for rapidly building high quality web applications that will remaining healthy over time as the web platform and JS ecosystem rapidly changes.
Sorry, I meant to say we ship to production about a hundred times per day, not hundreds of times per day. We've shipped continuously since the very early days of Intercom. [1]
We have a solid CI/CD pipeline meaning that every good merge to master hits production a small number of minutes later. Most of these changes are pretty small, focused and routine, adding a new button behind a feature flag, a db migration, a bug fix.
These small changes add up over time to a steady stream of highly polished features and improvements.
if you have 20 people on your team, and they each have 5 PRs merged which are deployed with some continuous deployment strategy, you're already at 100 deploys in one day. :-\
5 PRs a _day_ per engineer? What exactly are they cranking out? 1hr 30min per PR that's insane. Are these literally one-liners or extremely well defined tickets? Do your engineers work very late days?
1.x to 2.0 was a little rough, but so much better than the "all apps left behind" approach of Angular 1.x to 2.0. Ember's 2.x to 3.0 upgrade path was much improved as earlier mistakes were learned from.
Trajectory matters, and Ember had got a really great trajectory for apps that value longevity now.
We've been using Ember at Intercom for over 4 years to build our main app.
We continue to be super productive with Ember, our customers love our product, our code base has never been healthier and Ember's careful upgrade path and approach to deprecations means that we don't spend much energy or time thinking about non-product related technical challenges. The 6 week release cycle is great.
We've grown from 10 to 150 engineers in that time and Ember's strong conventions has helped us continue our tradition of enabling new engineers shipping to production on their first day and shipping a feature to production in their first week.
We started on ~v1.4. Ember has improved in every dimension since then. ember-cli, the ember inspector, contextual components, data down actions up, much better docs, an open RFC process, the ember addon ecosystem, the experimental glimmerjs, a smooth approach to deprecations and major version released. A lot of small steps and the odd big leap really adds up.
Performance is great now. The rendering engine has been rebuilt (without major changes to the templating syntax) and the new glimmer-vm architecture yielded huge performance and payload size wins and continues to deliver incremental performance gains every 6 weeks.
I've never considered error reporting an issue in the past, but I may just not remember the pain. It's not an issue for us now though.
If you (or anyone else reading) would ever like to chat in person, feel free to reach out:
I don’t work there, but was an early customer and have built apps from 1.x days.
The things that have improved:
1. Performance, performance, performance. It’s not fair, but anything that existed before react really was slow, because all JS dom updating was basically .innerHtml. Once we (as a JS community left that), everything has gotten faster (especially ember). Seehttps://madhatted.com/2016/11/30/5-things-to-know-about-embe...
2. Composability of components: being able to compose components together dynamically based and have a well defined boundary for colmunicating with the outside world is great. There is still some papercuts with the actual component API, but those are getting smoothed out.
3. Build-tooling/ecosystem. The amount and quality of tools keeps going up to accomplish tree shaking, AST parsing, etc. I just updated an ember app from 2.3 -> 3.0 and it took less than 2 hours to upgrade, test, deploy.
We've been using Ember at Intercom for over 4 years to build our main app.
We continue to be super productive with Ember, our customers love our product, our code base has never been healthier and Ember's careful upgrade path and approach to deprecations means that we don't spend much energy or time thinking about non-product related technical challenges.
We've grown from 10 to 150 engineers in that time and Ember's strong conventions has helped us continue our tradition of enabling new engineers shipping to production on their first day and shipping a feature to production in their first week.
Ember is not fading away for us, it's enabling us to focus on continuously shipping better and better features to our customers.
Even though it's much slower, GPT 4 is way more consistent than 3.5. The OpenAI APIs have had lot of flakiness in the past couple of weeks, we retry requests up to 10 times to work around this