brendanib

use vinext! (now 1.0 beta) https://vinext.dev/ https://x.com/James_Elicx/status/2073457440461303836

it already uses Workers Cache for the route-level ISR cache

There's no hard limit on duration! 30 seconds of CPU time

https://developers.cloudflare.com/workers/platform/limits/#d...

Would love feedback on which packages you'd like to see us support:

https://github.com/cloudflare/workerd/discussions/categories...

Three aspects of performance:

1. Cold start perf 2. Post-cold start perf - The cost of bridging between JS and WebAssembly - The speed of the Python interpreter running in WebAssembly

Today, Python cold starts are slower than cold starts for a JavaScript Worker of equivalent size. A basic "Hello World" Worker written in JavaScript has a near zero cold start time, while a Python Worker has a cold start under 1 second.

That's because we still need to load Pyodide into your Worker on-demand when a request comes in. The blog post describes what we're working on to reduce this — making Pyodide already available upfront.

Once a Python Worker has gone through a cold start though, the differences are more on the margins — maybe a handful milliseconds, depending on what happens during the request.

- There is a slight cost (think — microseconds not milliseconds) to crossing the "bridge" between JavaScript and WebAssembly — for example, by performing I/O or async operations. This difference tends to be minimal — generally something measured in microseconds not milliseconds. People with performance sensitive Workers already write them in Rust https://github.com/cloudflare/workers-rs, which also relies on bridging between JavaScript and WebAssembly.

- The Python interpreter that Pyodide provides, that runs in WebAssembly, isn't as fast as the years and years of optimization that have gone into making JavaScript fast in V8. But it's still relatively early days for Pyodide, compared to the JS engine in V8 — there are parts of its code where we think there are big perf gains to be had. We're looking forward to upstreaming performance improvements, and there are WebAssembly proposals that help here too.

I've been using this for a few months now and it's amazing. They're moving crazy fast to support ES6 features, and the interface for writing a new rule is great.

I've been using this for almost three months now and it's fantastic, hard to work without it.

We are collecting anonymous data about the network, browser, etc. and tying it back to core metrics like call length, but there's always more we can do. I'm really hoping that more browsers start to support the network information API natively too: https://developer.mozilla.org/en-US/docs/WebAPI/Network_Info...

Thanks Roger -- we really want to create a connection quality indicator like you describe, kind of like the number of bars on your cell connection.

One of our biggest frustrations with existing services is that it's hard to tell why the call quality is poor - is it my connection, your connection, or the service's fault?

Can I shoot you an email when we get a beta version of that indicator working? I'd love to get your feedback on it.

Let's say you send a link to someone on an iOS device -- we can prompt them to install a native app, then as soon as they open the app, with no login, your call starts.

Apple actually is refusing to add WebRTC to Safari, because if you have good HTML5 support and WebRTC, you can do much more outside of a native app, which hurts their ability to control the app ecosystem, and helps developers ship to Android and iOS on the same day. I hope this changes, but right now it doesn't seem promising.

Right now they're very similar, but we're working on getting Awesometalk onto more platforms than just the web. We want you to be able to send anyone an Awesometalk link, and no matter what device they're using, have a conversation.

Thanks for the feedback, sorry your first call didn't go well.

When the connection is poor, as it sounds like it was in this case, would you be okay if we fell back to audio-only and explained why? This seems like a better experience than trying to fight through lag, but we want to be careful not to arbitrarily cut off your video feed.

Hey, I'm one of the co-founders of Awesometalk. We started working on this 2 weeks ago and I'd be happy to answer any questions you have.

Haha, oops, just an editing mistake leaving those out. Thanks for finding that typo.

Thanks! If you run into any issues getting started, send me an email - brendan@awesomebox.co

Totally understandable - we don't want to exclude you based on the number of characters in your desired username. We just don't have a good set of all the words we need to reserve upfront - what we really want to avoid is ever forcing someone to change their username because of a conflict like this.

We'll see what we can do to allow shorter usernames without ending up in this situation. Thanks for the feedback.

Thanks! Let's take a stab at getting you setup with something small tomorrow ;)

It's funny that you said that about our landing page, because before this, we were probably the most egregious offender of having landing pages that didn't convey what we did. Takes a lot of work to find the right words and presentation, and we still want to make it better.

Thanks!

Our goal is to integrate with your source control, no matter where it's hosted. Anything that can send us a webhook should work just fine - just a matter of timing for us to build the integration. Email me at brendan@awesomebox.co and let's talk.

As far as getting information out of Awesomebox, you're the first person to ask - what type of information would you want? There's a few use cases we've thought of, but I'd love to hear your ideas first.

Whoa, that's amazing, thanks for sharing that. I'll check it out.

Great question - here's a few problems that Matt and I have encountered with Github issues and screenshots:

1) Clients, managers and other "non-developers" usually don't have Github accounts. When we tried making them use Github Issues, most of the time they'd use it for a week and then go back to emailing us or just stop giving feedback.

2) When new code is pushed to Github, how do you show non-developers? Usually this requires maintaining staging servers. What if you want to show different things to three different people? Three servers to maintain. With Awesomebox, you don't have to worry about this - we could even send them notifications to check out new versions, so that you don't have to bug them.

3) It's hard to keep screenshots and their associated conversations organized - it requires a lot of discipline, and when building things I've found that I tend to lose track of UI/UX feedback overtime, even if it's within an issue tracker.

4) Not all feedback is an "issue" or a bug. Github Issues are great, but are designed to track problems, not to help people discuss ideas or provide positive feedback.

I hope that helps answer your question - just a few of the reasons that Matt and I started working on Awesomebox. I'd love to hear more about how you work with people who aren't developers, and if our product doesn't fit your needs, tell us what we could do better. Feel free to reach out - brendan@awesomebox.co

Thanks!

Awesomebox only works with client-side code that runs in a browser - HTML/CSS/JS. If you have a Rails app that serves up a "single-page" app (like Angular, Backbone, Ember, etc.), we can work with you to make Awesomebox work. If this applies to what you're building, email me at brendan@awesomebox.co and we'll do our best to get you running with Awesomebox.

In an ideal world, we'd be able to support literally any application - Rails, Django, even iOS and Android apps. But in order to make your code available without spinning up complex environments and rebuilding parts of Heroku, we're focused on people building client-side javascript apps that send and receive data via APIs. This category of apps is growing incredibly fast, and we think there's a lot we can do to help, as both Matt and I have spent the past year working in Backbone and Angular.

Does that help explain a bit?

:) - could you email me at brendan@awesomebox.co? I'd love to hear more about what you think!

Thanks for catching that!

There are some massive and unsolved engineering challenges to going beyond HTML/CSS/JS, but in an ideal world we'd love to make this work for any app, including native mobile apps.

I can't tell you how happy this makes me. Let's talk!

To answer your questions:

"This will load up my grunt server automatically based on the latest push to github"

Almost - we'll serve the build directory that your gruntfile creates. We are thinking about running your grunt or gulp tasks for you, so that you don't have to commit your builds to git. I'd love to hear more about your setup and see what we can do to make it work.

"I can then annotate that HTML/CSS front-end to my designer for feedback changes."

Yes.

"No more screenshotting for me?!? This would be amazing."

Yup, that's the idea :)

"Any chance you can integrate to Bitbucket? :)"

We want to. Signup or email me at brendan@awesomebox.co and let's talk.

Completely agree - our apologies for not making this explicit. See my answer above for why we ask for the permissions we do.

Part of the challenge is that, during the auth dialog, there's no way for us to explain why we're asking for permissions. This is true across every oAuth identity provider I've done integrations with - they don't give you a way to explain why you ask for something like "Manage Contacts".

For that reason, when we ask you to connect to Github, directly below the button we link to a page about security (right now only visible to logged in users, sorry about that):

http://awesomebox.co/security

We should probably do the same whenever we ask for access to your Google Account. Really appreciate the feedback.

Thanks for the questions - totally understand the concern, and sorry for not conveying this more clearly upfront.

We ask for permission to manage your contacts so that you can easily invite co-workers to your project on Awesomebox.

We ask for permission to access your repositories on Github so that, for the repositories you choose, we can automatically update Awesomebox when you push new code.

Unfortunately, Github's permission model is "all-or-nothing" - we wish we could let you grant us access only to a specific repository, but it's not currently possible via Github's API.

If you'd prefer not to connect your Github or Google accounts, you can also signup with an email address and try using Awesomebox on an example project.

Does that help answer your question?

I dealt with this after a user complaint last week - The "-webkit-text-stroke: 1px" hack mentioned in the Chromium thread does indeed work, but only for headings. If you use a webfont for body copy, and absolutely need cross-browser support, probably just have to fall back.

That's a great example - we're certainly thinking about how to balance the power of static assets, which let us display a few different versions, versus supporting generated content from web servers like Rails or Django, where we can only display what's on your server.

Really, really appreciate the feedback!

Sorry about that! Offhand I think that's a unicode issue that I need to fix. Thank you for the heads up. Will work on a fix tonight.

As far as pricing, we're not sure yet, but we want to make it as free and accessible to developers and designers as we can, and charge companies, not people - kind of like how Github is free for open-source projects.

Hey, Brendan from Awesomebox here - I've actually never used Bugherd before (though I've heard great things!), so I don't know what it looks like enough to copy. As toast76 says, we also do very different things.

Not quite - Awesomebox works with your real production code, whereas DesignDrop is only for design files like PNGs, JPEGS and PSDs.