jonomacd

Looks like you are using the wrong models

https://g.co/gemini/share/ffa5a7cd6f46

I'm not so sure. I've run it a bunch of times. It makes a great pelican.

Personally I'm convinced this model is the best out there right now.

https://www.reddit.com/r/Bard/comments/1jjobaz/pelican_on_a_...

And the same thing with gemini 2.0 flash native image output.

https://imgur.com/a/V4YAkX5

It's sort of irrelevant though as the test is about SVGs.

At first, this was true but now it has gotten pretty good. The times it gets things wrong are often not the models fault and just google searches fault.

Yes it is. Including the live features. It is pretty impressive. Basically voice mode with a live video feed as well.

There is such a strong narrative against Google currently. It's really interesting seeing goalpost move and excuses made for this latest leaderboard. The fact of the matter is Google, openAI and anthropic all have excellent models with similar capabilities.

You can make use of htmx-indicator to show that the request is ongoing. From my perspective you have to be careful here. If you are _too_ optimistic and imply a request has been successfully sent to the DB when it really hasn't then users are not going to like that as their requests disappear.

You don't have to hydrate the html as events get triggered from "hx-" attributes on the elements.

Again I don't know if it is the best for their current use case but you could probably make something that is quite elegant in htmx.

There are a few actions that are exclusively client side, like opening a context menu, that I'd use a "sprinkle of JavaScript". There is a recently added htmx attribute "hx-on" that might work well for those cases.

I'd also not discount doing a round trip for some of that. Those GET requests can be very fast and will be cached. Given the poor performance of many SPA's a quick, cache-able GET request might look pretty good.

htmx is built to mutate html from the backend based on server side events. I'm not going to say it is better or worse than svelte for your use case but how you are describing it here is selling it short. I suspect you could make a decent files app with htmx and a sprinkle of JavaScript.

As per your development process, if you use htmx you can serve the template files from disk. Then all you need to do is edit the html templates which your backend reads in. No need to rebuild your golang application. For some changes you wouldn't have to reload the page just click the interaction to get the html fragment from the server.

You would need to rebuild your go application if you are changing parameters input into the template but that is conceptually the same as a client side template needing an API change. This also requires a rebuild.

Ha. Excellent point! I think I need to understand it better myself before I try to write something about it.

I've been building a golang app that serves html via the go standard library template system. It works really well. You can define and execute templates inline so you can define entire pages in html and then wrap a "block" around any reusable bit that you want to serve up dynamically.

Really easy to use.

I love the model. I've been writing a golang app with the standard library template system and it works really well.

One bit I've found slightly unintuitive is the swap and settled states. Took my a while to animate in a sidebar how I wanted. It was my fault for not groking it faster but perhaps some more examples or guides in that regard could be useful.

SPAs make tons backend calls to get data. This isn't particularly different. To me the main difference is it is hard to build an offline app out of htmx as compared to a SPA but so few webapps are offline anyway...

I do as well. I don't see how as they are burning a hell of a lot of money and it still seems quite far from a broad consumer product. But they have probably pushed up the timeline for AR headsets dramatically with the work they have done. Essentially training up people in the technology so when they quit they can go work for Google and Apple who will likely be the ones to eventually productise this when folks have developed the technology enough.

But who knows what they have up their sleeve for v2...

The person who wrote this article has a well known vendetta against magic leap. So that explains that.

Bigtable is a distributed database. It does best effort replication across regions, hence eventual consistency. But within a region it is still distributed across nodes and provides strong consistency.

Yes, I have heard this! Great news they have sorted that out. Might be worth us looking at it again though we are hosted in GCP now so it is less tempting...

This is great feedback. Thanks for this. We have heard the same thing particularly about using multiple clusters. They only started offering it last year though!

Interestingly, for us scaling up doesn't really solve the short term unavailability. It seems to be only somewhat related to load as it does seem to hit more often at high traffic times but we have also seen it at low traffic times.

Putting in that cache is a great move. Cache is challenging for us as we get hits over a very wide range of keys.

Yeah, it does sound like I am really down on the product but it does some things very well. If you can work around the very short lived unavailability it is fantastic.

Yeah, it was quite frustrating trying to figure out what was going on. Up until replication was released, it makes it a real non-starter for a lot of use cases. With replication you can combat the problem and it does give you great performance (when it isn't giving you random errors).

wow...

I should spend more time trademarking generic sentences. Seems lucrative.