The role of CEOs is to receive praise for every achievement, but also blame when things go wrong. It's a high risk, high reward position that most people can't handle.
Since it's not possible to blame AI, no ChatGPT can't be used to replace the CEO of Microsoft.
This. The problem lies with blame attribution. We humans have been accustomed to think everything from that perspective. As Yoshua Bengio points out in Machine Learning Street Talk podcast: "social system hasn't evolved to keep up with the technology".
A lot of people moved from Flask to FastAPI because the latter is built for async workloads by default. So, people expected massive performance improvements because the word async was associated with performance.
In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic, while having negligible to zero performance improvements. Proof that most people are terrible at choosing tech stacks.
Then, AI came into the scene and people were building APIs that were essentilly front-ends to third party LLM APIs. For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation. Then people realized that can can simply access OpenAI's API instead of calling another front-end API first. But now they're already invested in FastAPI, so changing to another framework isn't going to happen.
Either way, I like FastAPI and I think Sebatian Ramirez is a great dude who knows what he wants. I have respect for a person who know how to say no. But it's unfortunate that people believe that Flask is irrelevant just because FastAPI exists.
> In reality, people ended up having to deal with weird bugs because asynchronous Python isn't the most ergonomic
That is an understatement. I loathe working with async Python.
> For example, people could build an API that will contact OpenAI before returning a response. That's where FastAPI truly shined because of native asynchronous views which provides better performance over Flask's async implementation.
TO be fair there are lots of other things that require a response from an API before responding to the request and therefore async reduces resource usage over threads or multi-process.
> TO be fair there are lots of other things that require a response from an API before responding to the request and therefore async reduces resource usage over threads or multi-process.
Agreed. However, these are rare and many people have been abusing asynchronous views instead of delegating the task to a background worker when multiple external requests are required. Showing a spinner while polling a synchronous view is dead simple to implement and more resilient against unexpected outages.
I agree with this. For real life stuff, Flask (or Django for that matter, my preference) is preferable over FastAPI. I used FastAPI recently for something that needed super fast (relatively speaking) async. And you just need to build a lot of stuff yourself which wastes time, comparatively speaking. If I had known, I'd probably have done it in Django and rather used Daphne or something.
Interesting. But is it also not just that Flask was build more for making websites in general, and FastAPI for making REST APIs specifically? I would say that if you want to make a REST API, that FastAPI is easier and more convenient to use.
Yes, I assumed this is what they were ignorantly pointing towards.
Indeed, Csrf tokens are an ancient concept. WordPress, for example, introduced nonces a couple years before rails. Though, it does appear that rails might have been thr first to introduce csrf protection in a seemingly automated way.
True, it does seem like Rails introduced configuration-free token based CSRF protection, which "solved" CSRF for traditional server rendered apps.
I believe the new technique is easier to use for SPA architectures because you no longer need to extract the token from a cookie before adding it to request headers.
I agree with this post, but how do we convince decision makers to use simpler solutions? Here's what happened to me not long ago:
A person contacted me to build a tool that will have a single user. After some questioning, the person said they would likely have up to 3 users for this tool at some point, and no more.
So I suggested we use Python and a SQlite database. When I reached out after not having heard from them for 2 weeks, they said that they went with a more experienced programmer because the latter suggested MongoDB, a separate ReactJS front-end, and micro services with Golang. All deployed to AWS, of course.
In the end, I lost the gig because I wanted to save the client time and money.
The guy speaking at 3:35 reminds me of a recent blog post by a certain tech celebrity, where he was recalling his recent visit to London and was unhappy to find less white people that he remembered from his previous visit.
I used to love the Django ORM when I didn't know any SQL. Then I had to learn SQL so that I could model data properly, and optimize access patterns.
These days I hate working with the ORM because it uses weird abstractions that make your life harder as you try to do more complicated stuff with your data. I had a small bug lately where a queryset would aggregate twice because I filtered an aggregated queryset, and this caused it to aggregate again on top of the previous result. I wouldn't have this bug if I was writing my own SQL, or if I used a query builder instead of an ORM. This is just a small example, I have many more annoying things that will cause me to use SQL directly instead of an ORM for my next project.
Basically, the HTMX code says: "when this span is clicked, fetch /rebuild/status-button, extract the #rebuild-bundle-status-button element from the returned HTML, and replace the existing #rebuild-bundle-status-button element with it".
The Datastar code instead says: "when this span is clicked, fetch /rebuild/status-button and do whatever it says". Then, it's /rebuild/status-button's responsibility to provide the "swap the existing #rebuild-bundle-status-button element with this new one" instruction.
If /rebuild/status-button returns a bunch of elements with IDs, Datastar implicitly interprets that as a bunch of "swap the existing element with this new one" instructions.
This makes the resulting code look a bit simpler since you don't need to explicitly specify the "target", "select", or "swap" parts. You just need to put IDs on the elements and Datastar's default behavior does what you want (in this case).
Note that for this example you can get the same behavior (assuming the endpoint hit isn't using using SSE, which IMO Datastar over emphasizes) in HTMX via a combination of formatting your response body correctly and the response headers. It isn't the way things are typically done in HTMX for Locality of Behavior reasons, not because it's impossible.
in Datastar the locality of behavior is in you backend state...
datastar.Patch(renderComponent(db.NextRow))
imho, a single line is the ultimate LOB pattern. idk, ngmi
Datastar keeps the logic in the backend. Just like we used to do with basic html pages where you make a request, server returns html and your browser renders it.
With Datastar, you are essentially doing kind of PWA where you load the page once and then as you interact with it, it keeps making backend requests and render desired changes, instead of reloading the entire page. But yo uare getting back snippets of HTML so the browser does not have to do much except rendering itself.
This also means the state is back in the backend as well, unlike with SPA for example.
So again, Datastar goes back to the old request-response HTML model, which is perfectly fine, valid and tried, but it also allows you to have dynamic rendering, like you would have with JavaScript.
In other words, the front-end is purely visual and all the logic is delegated back to the backend server.
This essentially is all about thin client vs smart client where we constantly move between these paradigms where we move logic from backend to the frontend and then we swing back and move the logic from the frontend to the backend.
We started with thin clients as computers did not have sufficient computing power back in the day, so backend servers did most of the heavy lifting while the thin clients very little(essentially they just render the ready-made information). That changed over time and as computers got more capable, we moved more logic to the frontend and it allowed us to provide faster interaction as we no longer had to wait for the server to return response for every interaction. This is why there is so much JavaScript today, why we have SPAs and state on the client.
So Datastar essentially gives us a good alternative to choose whether we want to process more data on the backend or on the frontend, whilst also retaining the dynamic frontend and it is not just a basic request-response where every page has to re-render and where we have to wait for request to finish. We can do this in parallel and still have the impression if a "live" page.
Thanks, brings me back to my youth when I was being accused of cheating or being a bot in Counter-Strike :)
If you still don't get it, Datastar is essentially like a server-side rendering in JS, for PWAs, but it allows you to use any language you want on the backend whilst having a micro library(datastar itself) on the frontend. Allowing you to decouple JS from frontend and backend whilst still having all the benefits of it.
I mostly agree with this. TS works great in large enterprises where developers don't trust each other. But if you're working on your own, or in a small team where you can easily agree with each other, TS just becomes unnecessary overhead.
At least, that's my experience and I don't like it when people say that everyone must absolutely use TS when they don't know anything about your situation.
Since it's not possible to blame AI, no ChatGPT can't be used to replace the CEO of Microsoft.