willchen

Thanks, I've filed an issue: https://github.com/google/mesop/issues/359

There's similar things in other languages like https://www.gpui.rs/ and https://github.com/linebender/xilem.

Mesop also drew inspiration from frameworks like LiveView (for Elixir/Phoenix) https://hexdocs.pm/phoenix_live_view/welcome.html which have demonstrated the viability of building server-driven web UIs for a number of years now.

Thanks for the question! Streamlit is definitely more mature and I think it's a great tool for many use cases.

Where I think Mesop shines is that you get a lot of flexibility, just by writing your UI in Python. For example, Mesop has an out-of-the-box [chat component](https://google.github.io/mesop/demo/), but if you need to customize it, you can actually just copy the [chat.py file](https://github.com/google/mesop/blob/main/mesop/labs/chat.py) and customize it however you want.

In comparison, Streamlit is great to get started with, but once you're trying to do some complex customizations, you'll often need to write your own React/TypeScript component.

I think the other thing is that Mesop has a [different philosophy for building UIs](https://google.github.io/mesop/blog/2024/05/13/why-mesop/) (e.g. based on functions) which results in a distinctly different developer experience. This is, of course, subjective, but I think the Mesop approach scales well as your app grows (e.g. thousands of lines), which even internal tools and demos oftentimes do.

You can customize the UI quite extensively using our Style API https://google.github.io/mesop/components/style/

If you like tailwind, I think you will like this as it's essentially like writing inline styles, but with a Pythonic, strongly-typed API.

Accessibility is important and the good thing is Mesop is built on Angular Material components (https://material.angular.io/components/) which has invested in supporting a11y. Mesop components are likely missing aria-* attributes, but it's pretty easy for us to add them (essentially plumbing them from Python into the Angular components), so please file an issue on our GitHub repo to let us know what we're missing, thanks!

This is definitely something we've discussed and I think Python -> WASM is an exciting innovation. Right now, there's some challenges with how large of a WASM binary a typical Python app will compile to (e.g. bundling the std lib) and the initialization time [1].

I think supporting Python -> WASM could be one of the options we support, but there's probably always a need to support Python on the server, simply due to the ecosystem (e.g. dependencies) that's around it.

[1] https://pyodide.org/en/stable/project/roadmap.html#reducing-...

Yeah, I think the "simple things easy and hard things possible" is a good way of framing this. I've written a blog post about the design philosophy of Mesop and how it differentiates with existing frameworks: https://google.github.io/mesop/blog/2024/05/13/why-mesop/

Re: flet - flet intentionally takes a more imperative approach whereas Mesop embraces a declarative UI approach (as popularized by React, et al). I think the declarative UI approach scales better as apps get more complex, but I think the best way to see the difference is to look at some of the examples and see which approach you like more.

Re: nicegui - at the high level, there's definitely some similarities with the component-centric UI model. The data binding/state management works quite a bit differently and Mesop's approach provides stronger type-safety and, IMO, is more Pythonic, but that said, there's a lot of good options in this space and I think it's neat to look at all the innovation that's happening here, and ultimately, some of this is based on aesthetics and how you like to code your UIs.

Might want to check out: https://flet.dev/docs/cookbook/packaging-desktop-app/

I haven't used it personally (this is separate from mesop), but it looks like a way to program desktop guis (among other platforms ( in Python

OK thanks. I've filed an issue here: https://github.com/google/mesop/issues/345 if you could share with us a repro (the Mesop code you're running) on the issue, that would be helpful in debugging this.

If you take a look at the "table" example on the demo gallery: https://google.github.io/mesop/demo/ it shows how to use Pandas w/ Mesop, so I'm not sure what's going on.

All the python code, including requests are executed on the server

Take a look at https://google.github.io/mesop/internal/architecture/ for an explainer on how the client-server interaction works and let me know if you have any questions!

Could you share the error you're getting locally?

Re: calling backend, yeah you can use requests or anything else (e.g API client libs, talk to DB directly). The beauty is that you're just writing regular python code

Yeah, you can definitely deploy it to share with others. Check out our deployment guide (https://google.github.io/mesop/guides/deployment/) which shows you how to deploy Mesop apps to Google Cloud Run, but you should be able to deploy it on pretty much any service that takes a container.

For example, the demo gallery (https://google.github.io/mesop/demo/) itself is a Mesop app which is hosted on Cloud Run

I think the problem with bundling chromium is that it wouldn't be evergreen, which means it doesn't have the latest security fixes, etc .

I think the +1 button was a really nice feature and something they should've done a while ago, but it's hard to draw the line.

If everyone contributes their pet UI feature (e.g. custom theme, use XYZ monospace font), then there will be dozens of features that only 0.01% of users use, but it increases the overall complexity of the product and maintenance burden.

A bit confusing that there's blue, underlined text that look a lot like links.

Perhaps this was posted too early and should actually link to more in-depth docs?

Looks very exciting! I've used firebase for some small weekend projects and it's been very productive for me.

I'm curious, what's the react native support like for Firestore / firebase in general?

Citation?

Very interesting DB service. If I'm reading the docs right it sounds like you can't do JOINs across documents?

https://docs.microsoft.com/en-us/azure/documentdb/documentdb...

Congrats on the release. Could you summarize the pros and cons of picking Relay Modern vs Apollo Client?

It's possible. I got a job as a software engineer at Google despite having a degree in Economics and only knowing Javascript. I spent a lot of time studying data structures & algorithms on my own but it's do-able.

I installed the extension and it's incredibly easy to use. I tried it on a personal site, google.com, etc and it's interesting to see the various performance metrics for each site. I'd be curious to see what the highest PWA (progressive web app) score someone saw for a major website (for reference, I got 44/100 for google.com).

I've noticed some open source projects (particularly Angular 2) follow this convention where they never actually "merge" the PR, but rather rebase it into their main branch and have a message in the commit to close the PR.

The advantages seem to be that you get a cleaner git history, and you can keep all the "in-between" / WIP commits that tell the story. Is this done through an automated tooling or is someone manually rebasing it into master? It seems to be a really useful practice so I'm curious how people do it. It would be great if GitHub could offer this natively, as I think many power Git users appreciate the benefits of rebasing over merging.

Does anybody else feel like GitHub has released more features in the last month than the last 6 months? I'm not sure if it's just a coincidence with all the attention they've gotten on HN, but these improvements are much appreciated!

That's cool! Have you ever tried them before?

I looked at them once before, and there's nothing super close to where I live (would need to drive to pick it up), but I'd definitely consider using it if there was someone who cooked within walking distance of me.

I can definitely see the potential of awkwardness, especially if you know the neighbor already, etc. But like Airbnb, I think reviews go a long way to ensuring good quality in the long run.

As someone who's ordered from spoon rocket dozens of times over the past two years, I'm definitely sad to see it go.

A quick timeline (from what I can remember):

- Initially started out in Berkeley / Emeryville area by a couple of Berkeley alumni who had previously launched a food delivery startup focused on midnight munchies (aka, unhealthy food for college-type students). Each meal was initially only $6, tasted quite good, and delivery only took ~15 minutes.

- Expanded to Oakland area (first Downtown, then eventually other areas like Lake Merritt). Meals were still only $6, taste was usually good but sometimes wasn't as good. Delivery was still fairly fast (usually <15 minutes), but could take up to 30 minutes.

- Expanded to SF. Meals became more expensive and had variable pricing (I think it was first $8, $10, then $12, depending on which dish). A delivery fee ($2.50) was created. Food quality dropped (usually was OK, but not as good as it used to be); meals could take up to 1hr to get delivered (usually under <30 min though)

- Started their elite food delivery plans which provided free meal delivery and a bit of extra credit, by agreeing to pay upfront each month (e.g. $20).

Thoughts:

- From a business perspective, I think SpoonRocket (SR) made a lot of the right moves. While a lot of people say "disruptive innovation" loosely right now, I think SR actually did it by: 1) focusing on a low-end market that wasn't well addressed (e.g. college students), 2) used a technology to rapidly improve the experience for this low-end market (e.g. using Google Maps to efficiently route drivers to deliver on-demand meals), and 3) go upstream in the market to gain market share in higher-end consumer segments.

- So why did SR fail? I'm speculating here, but I think it's because scaling all these type of on-delivery startups is really, really hard work. Unlike Google or Facebook which could effortlessly scale up across the world with its technology-heavy solution, scaling up a company like SR requires hiring a linear amount of employees like drivers and support staff. As others have noted, it's difficult to get the economics right for an inherently low-margin business with a high labor component.

- Can other food startups succeed? I'm willing to bet most food startups probably won't survive this fundraising crunch if it extends another year. As far as I could tell, SR was ran as a very lean operation where they tried to batch deliveries, produce a small set of meals in large quantities, and focused on efficiency (e.g. calling you two minutes ahead of time to minimize delivery driver's waiting time). If SR couldn't make the economics work, I'm not sure how others could. Perhaps by going more high-end than SR, and charging a higher price (a la Munchery) or is it perhaps by selling a lot more quantity?

- Lastly, what I'm hoping for is the "Airbnb" of food, where regular people could cook meals and sell them to neighbors on a marketplace with reviews, pictures, etc. Of course the economics would be challenging like any food business, but that's the kind of service that I could see myself regularly using. There's also the regulatory side (after all Airbnb itself has followed the policy of 'asked for forgiveness, rather than permission') Who doesn't like the sound of buying a home cooked meal from a neighbor?

I think this is a really exciting project and will definitely be paying attention to it over time. There's been so many "Javascript fatigue" articles and I think projects like these help solve issues stitching up many small npm libraries together to make a cohesive web app. Even if you're familiar with all the libraries in the React/Redux/Webpack ecosystem (and I'm not - I've only used React & Redux for small side projects), I think there's a tremendous value in knowing that these sets of libraries at these versions are compatible with each other.

While it's nice to have small dependencies that you can swap out over time as your use case evolves or as the ecosystem progresses, most of the time I'd just like to use the "standard stack" for a given platform. As someone who primarily uses Angular, one of the main benefits I see of Angular's 'kitchen-sink' approach is that you get a lot of standard functionality right out of the box (e.g. routing, i18n, animation) without having to research the best community package for that particular functionality. However, I think it's the narrow focus of React on the 'View' layer that's made it so widely adopted, because it plays well with an existing stack.

Having a project like this seems like the best of both worlds - libraries like React can focus on excelling in a single concern and developers still get a curated set of standard functionality so they can setup a complete web app.

Good documentation! :)

Educational back-and-forth, although unnecessarily biting.

TL;DR - Aphyr thinks Damien Katz never read this: https://en.wikipedia.org/wiki/Consensus_%28computer_science%...

Fair point. For RethinkDB, I think there's a good business case for getting it tested sooner than later (on both sides). For aphyr who's leaving Stripe, I think it would be reasonable for RethinkDB to compensate him for an unbiased study, given that they have $12M+ in funding. A positive report could generate a lot of attention for RethinkDB and give confidence to larger enterprises who are very hesitant of trying anything remotely "new" or "experimental" in the DB space.