While there is nothing inherently wrong with this. It does have vibes of Mayers and the Yahoo logo. The ship is going down but we have a fresh new look!
Is it just me or does it seems very odd that GrapheneOS only runs on a phone produced by the company that makes Android. Meaning that ironically, it isn't a Google alternative.
I know the reasons are technical, but still, it means I have no interest in it as somebody who is actively de-googling myself.
Note that Google is in active talks with an major Android OEM for a few months already to help them meet the requirements for a subset of their future devices. They are very optimistic about that.
My personal experience is Remix has all kinds of problems akin to the issues in the blog post, including the mess that is remix -> react router v7. When I worked with Remix a year ago logging and middlewares were also a disaster. For example it didn't have middlewares, and had no way to create a LocalContext from the host (e.g. Express or whatever you use) that first starts handling the request down through the remix app.
I also had the impression they would probably follow the Vercel style, framework as a business model, with it being sold to Shopify.I don't really know where it's all going, but it is not the sort of thing I would tie myself to.
I don't think any of the examples in the article contradict the Zen of Python. Even if there's one simplest and clearest way to do it in Python, there's nothing stopping people from using a more complicated solution that they got used to while working in a different language. They might not know to look for a simpler way, because they're used to working in a language where their way is the simplest.
CPython core devs. Specifically talking about the CPython code base. Hence, the namespace comment, which doesn't really make sense in a purely python context.
> than in any other programming language
After reading the article, I couldn't believe anyone designs their systems like that. His "solutions" seemed to be the obvious way to do things.
$ python -c 'import this' | grep way
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
There are many layers to this, but the most important thing to point out is that having only one obvious way is just a preference (or ideal). In practice, any deliberate attempt to prevent something logical from working is counter-productive, and there is really no way to control what other people think is or isn't "obvious". And we all sometimes just expect things to work very differently than they actually do, even in ways that might seem bizarre in retrospect. We can't all "be Dutch" all the time.
But let me dig into just one more layer. Pay attention to the hyphens used to simulate em-dashes, and how they're spaced, versus what you might think of as "obvious" ways to use them. I'm assured that this is a deliberate joke. And of course, now that we have reasonably widespread Unicode support (even in terminals), surely using an actual emdash character is the "obvious" way. Or is it? People still have reasons for clinging to ASCII in places where it suffices. Then consider that this was written in 2004. What was your environment like at that point? How old was Unicode at that point? What other options did you have (and which ones did you have to worry about) for representing non-ASCII characters? (You can say that all those "code pages" and such were all really Unicode encodings, but how long did it take until people actually thought of them that way?) On the other hand, Python had a real `unicode` type since 2.0, released in 2001. But who do you know who used it? On yet another hand, an emdash in a terminal will typically only be one column wide (just as an 'm' character is), and barely visually distinct from U+002D HYPHEN-MINUS. (And hackers will freely identify "dash" with this character, while Unicode recognizes 25 characters as dashes: https://www.compart.com/en/unicode/category/Pd) Reasonable people can disagree on exactly when it should have become sensible to use actual emdashes, or even whether it is now. Or on whether proper typography is valuable here anyway.
It certainly reflects the process I've gone during some difficult conversations, at least when I did them well. And I've certainly done the other approach where I just dug my trench and they dug theirs; oh lord, is it a terrible approach!
I think even a bad difficult conversation is better than no difficult conversation so just giving the managers I work with some tool to compel action is valuable.
I'm not a fan of the SPA, or at least in practice, but there is something very attractive about going with a solution that everybody knows.
At work we are building a new "website like" frontend and it is a SPA (that internally operates as a MPA) built with React. The main reasons are we: know this setup well and know when hiring we will find people who know this setup as well. Beyond that, it will allow us to build out more application like features in the future if needed.
This approach has been popular in the industry for over 10 years now. Whereas most of the current discussion and tech on the frontend feels like churn and betting on the next thing. A lot of people just want tools that are mature and can get the job done regardless of them being the best tool under specific criteria.
It's clear to me that the frontend conversation space is broken. Not even just the ecosystem being a mess.
Boiling down the conversation I see in the article, it just seems to be: the browser as a HMI vs the browser as a an application runtime. Depending on what you want to do one might be a better fit than the other. But the points it puts forward are fluff arguments like "it's a breadth of fresh air" or "it loads faster".
It's difficult to articulate the source of just how broken the discussion space is; nor have I made a particularly strong argument myself. But I think it's important to keep pushing back on conversations that position framework's like they are brands winning hearts and minds. Ala the fashion industry.
The fashion industry is the best analogy I've seen so far for frontend frameworks. It's obvious that the amount of technical rigor involved with declaring something "content-driven" and "server-first" is approximately zero.
Astro is trying to position itself in opposition to things like Next.js or Nuxt wich are specifically marketed as application frameworks?
And the architecture is more suited to something like a content site, because of the content collections, built-in MDX support, SSR, image handling, and server routing?
They are referring to static non-interactive content (basically images and text) in sites like blogs, marketing site, docs, etc. as opposed to highly interactive, and dynamic components, think Facebook, Figma, etc.
> But the points it puts forward are fluff arguments like "it's a breadth of fresh air" or "it loads faster".
Fluff arguments do exist, but you can also measure. The site is static with minimal JS on the one page, and a bit more JS on the other page, so nothing surprising in the numbers, and nothing you can say was achieved thanks to the magic of Astro, but I wanted to shared them:
Write some straight HTML pages and serve it from bog standard Apache. Heck, get really fancy and do some server-side includes for your CSS or something.
It's really fast, you can edit it with Notepad, and you can probably saturate your bandwidth with a consumer level PC.
It's fluff because, well, our expectations are so unbelievably low. By the time you've bolted on every whizbang dingus leveraging four different languages (two of which are some flavor of Javascript), your twelve page site takes a couple of minutes to compile (what?), and it chokes your three load-balanced AWS compute nodes.
Web applications are hard. I get that. Web sites? They were, by design, incredibly simple. We make them complicated for often unclear reasons.
I appreciate what the Astro folks are trying to do, and it's very clever. But your basic Web site need not require freaking npm in order to "return to the fundamentals of the Web".
Astro will generate those HTML pages you can serve 'from bog standard Apache'.
You can then use all of those npm packages to do whatever processing on your data that you want to do to generate the content and the pages and then just serve it as HTML.
I'm a backend dev, but Astro is the first time a front end framework has made sense to me for years. It fits my mental model of how the web works - serving up HTML pages with some JS just like we did 20 years ago. Its just that I can have it connect to a DB or an API to pull the data at build time so that I can have it generate all of the pages.
But astro literally generates straight html which can be cached wherever you want...
As for build time, I don't have a clue - I haven't used astro (and don't plan to. Datastar + whatever backend framework you want is better). But I'm generally in favour of the direction they're bringing JS frameworks.
Potentially using the git hash as a seed would make sense, so for a given snapshot of code it is always going to be deterministic. When the git hash changes (i.e. your code) then that would result in a different set of test inputs running.
Using a git hash still has the problem of a co-worker's changes (which alter the git commit) causing an unrelated property to fail.
Hypothesis has a nice option, to pick the seed for each property by hashing that property's code. It's a nice idea, but relies on Python's highly dynamic nature; so may not be easy/possible in other languages (especially compiled ones).
Just as an anecdotal experience. It doesn't necessarily go without saying.
The most memorable discussion I had around PBT was with a colleague (a skip report) who saw "true" randomness as a net benefit and that reproducibility was not a critical characteristic of the test suite (I guess the reasoning was then it could catch things at a later date?). To be honest, it scared the hell out of me and I pushed back pretty hard on them and the broader team.
I have no issue with a psuedo-random set of test cases that are declaratively generated. That makes sense if that is what is meant by PBT. Since it is just a more efficient way of testing (and you would assume this would allow you to cast a wider net).
This dilemma is of course trivially solvable by persisting a (presumably randomly generated) RNG seed with each test run. You just have to ensure that your RNG is configured once with the seed at the beginning of each test run.
