Conceiving of technical debt as dirty dishes is popular, although it could always stand to be even more popular.
Also do your dishes. Like, in reality. The ratio how happy it makes others who live with you vs. effort required is arguably higher than any other single act available to you. An enormous number of couples’ therapist salaries are made simply convincing people that doing the dishes is important.
Intellisense and a linter? You still need to pack/turn on/unpack a dishwasher; your code can’t clean itself but tooling can help make it faster for you than without it.
I used to be a “soaker” with the kitchen sink until we had a baby.
Nothing worse than waking up to make the kid some breakfast and having to wash every dish you need to get it done. Now I am steadfast on doing the dishes every night to start the day in a clean kitchen.
I find it weird that they bundle s3 and postgres support directly into a runtime instead of having them as libraries. Looking at the documentation for s3, I see
Bun aims to be a cloud-first JavaScript runtime. That means supporting all the tools and services you need to run a production application in the cloud.
and I get that it’s better to have a native implementation rather than a pure JavaScript one for speed (though I’m skeptic of their 5x claim). But I can’t see this approach scaling. If performance is a concern, then other services you communicate with also need to be fast. In particular Redis/memcached or whatever caching mechanism you prefer, but also ElasticSearch or maybe some Oracle database you need to talk to as well. Should those also be in the runtime? And how do you handle backwards compatibility for those libraries?
I guess this is just a long-winded way of saying “Why aren’t they implementing this as native add-ons and instead force this into the runtime?”. It feels much more modular and sensible to put it outside of the runtime.
My two biggest complaints are mostly to do with the API - one being that s3 is imported from bun, rather than bun/s3 or similar. Python provides a big stdlib, but the modules still have different names. You don’t do from python import DefaultDict, httplib, for example.
The other one is that the file function supports s3 URIs, which is nice from a minimal API perspective, but I also think it’s not ideal to treat s3 the same as local files. s3 has a lot of additional setup - e.g AWS credentials, handling auth errors, etc. So I think it makes sense to logically separate the behaviour for local vs remote files.
I don’t mind new takes on AWS / postgres sdks, though. The SDK is pretty decent compared to some others (e.g Google or Slack), but I think both their AWS and postgress examples there (other than the two issues I mentioned) are pretty nice.
I agree with your sentiment and I am also very confused why I would use the Bun s3 implementation over the whole AWS SDK that I have been using and accustomed to for years now. Sure there could be some performance gains (for just S3) but I don’t see the benefit.
I’ve run into contention on S3 in a Python backend, and it’s really not fun. It’s a very good feature to have this sorted and guaranteed to work fast, it means that Bun can stay competitive with compiled languages for more intensive workloads. To me, this is a production mindset: identify the key components, and optimise them so that they don’t get in your way.
Kind of an aside, but on the topic of ligatures I was reading the docs on https://jotai.org and they use a ligature font in their examples. And I recognized it so it was fine… but seemed like a poor choice.
Like ⇒ looks close enough to => I suppose, but ≡ doesn’t look like ===, and the examples are there to help people type out correct code, not read math.
Obviously doesn’t matter the same way when you are in your own editor. Though I do imagine the ligature feels weird when you type thi and then type the final s and the cursor actually moves backwards.
My take is that ligatures lie to the reader as to what is in the document. I am not going to judge anyone who uses them but they really bother me when I see them in code.
When I look at my groups of “normie” friends and family I find it very, very hard to think of them leaving the big platforms for ones more decentralized. Now, I am inferring this and I haven’t spoken at length about this, but they don’t seem to understand the difference or importance of these alternative platforms. Its just more weird tech shit they don’t want to bother with.
Why go to the alternatives when the big platform is still there, and everyone else is too?
But when I see the strides these communities are making to make it more accessible, and the quality of conversation and content I am seeing on the fediverse, anecdotally, gives me a lot of hope. I can probably convince my wife and a few friends to make the move, but ultimately I think the apathy towards digital life keeps users complacent and exactly where the Facebooks and Twitters of the world want their users to be.
I agree that it’s very hard to teach the theoretical benefits of decentralisation to normies, but the silver lining to how awful the internet has become in 2025 is that we can now demonstrate these benefits in practice.
We can point at Facebook, Twitter, Reddit and all the other platforms and how shittified they have become and how they could personally resist this enshittification if they were using equivalent decentralised platforms.
It would’ve been much harder to have this conversation 10 years ago, at the height of the free money era. But in 2025 you can already see the steam leaking through the seams.
I didn’t realize there was still a debate about this? I feel like the folks who did web development before the dawn of the SPA and these big frontend frameworks all knew this in their bones and felt vindicated (I know I did) when the JS community/ecosystem started pushing for frameworks with SSR.
Not only did we know it in our bones, it ended the period of a few years where talking about SSR labelled you as someone out of touch and refusing to get on the bandwagon. Definitely felt vindication when SSR started being discussed as an alternative rather than derided.
Also turns out one thing is not better than another, they all have trade offs, who could’ve guessed.
At work I am trying to juggle all the wants from the other departments with the finite resources that is my team.
Personally, I am trying to track down why the integration of the Odan session library in SlimPHP, with Twig templates, is not rendering flash messages on the template at all? It looks like the Flash class being called in the twig template is not instantiated with the $_SESSION variables yet when adding messages to the Flash storage they are in $_SESSION.
I’m one of the release managers for PHP 8.4 (I didn’t tag myself as author though, and I should probably update my hats). Ask me anything about PHP 8.4 I guess.
Is there more background / numbers on the JIT work?
The lazy object stuff seems a little niche. Does it really benefit DI if applied broadly, or is it more for manual marking of classes with expensive init?
I love some of these changes! I was joking with some friends of mine this morning that with every PHP release it inches closer and closer to C#. Is C# and the broader “enterprise” OOP world one of the big inspirations for some of these changes that get included in these releases?
Also not about this change but is it really that hard to get Generics into PHP?
There’s some stuff C# doesn’t have (but I haven’t touched it in years, so I might be wrong) like rudimentary ad-hoc sum types (i.e. string|Callable). I think it’s more a general PLT zeitgeist thing; you see a lot of the same forces driving Kotlin, Swift, etc.
Fatal error: Uncaught ErrorException: Symfony\Component\Console\Input\ArgvInput::__construct(): Implicitly marking parameter $argv as nullable is deprecated, the explicit nullable type must be used instead in phar:///shared/backups/php/deployer-7.5.phar/vendor/symfony/console/Input/ArgvInput.php:46
I don’t understand what is so hard to comprehend about a complete lack of interest in a tool. Some people don’t ever want to bother learning a LISP, does that bother this author as well? Some people don’t want to use Linux as their main driver or would prefer a cheap keyboard over a fancy one with mechanical switches.
These kinds of posts have the effect of like “I really don’t understand this rube” - even though he’s explicitly trying to say that’s not his case - I think it still is. Let people who don’t want AI in their development tools not have it and go on with their lives. I don’t like olives but I don’t get lambasted by my wife for not trying some out of the jar like she does.
I think if you have a strong enough belief that it’s important enough to — as in this case — be one of your first questions about a new technology, then it’s important to be informed about that belief.
To use one of your examples, I am not interested in learning a lisp right now, but I don’t go out of my way to avoid looking at lisp code, and if you offered me a job working with lisp, the choice of language wouldn’t be my first concern. I have worked with people who will refuse to touch certain technologies with a bargepole (sometimes lisps, more commonly languages like PHP or Javascript), and almost invariably those people are uninformed and inexperienced with the technologies they’re talking about. The opinion is mainly formed out of hearsay and limited contact.
I think when you’re heavily involved in a technology, those sorts of opinions are the difficult ones to understand because they don’t fit with your knowledge. And not just your own personal preferences, but your knowledge and experience specifically. For example, you mentioned mechanical keyboards — if you came to me and said “oh, I looked into mechanical keyboards, but I wasn’t willing to spend so much money to try it out”, then I’d understand what you were saying — that is a largely true observation about mechanical keyboards. But if you came to me and said “I don’t like mechanical keyboards because they aren’t as ergonomic as a laptop keyboard”, then I’d be somewhat confused by that.
In fairness, in the article as written, we only have the author’s perspective, and I also find the tone of the article a bit excessive. But I do think that supposed technologists often form strong opinions about things with very limited experience, and I can understand the author’s frustration with this kind of behaviour.
I think it depends heavily on what type of tool you’re referring to. I agree that if someone isn’t interested in Lisp, or Javascript, or Rust, that’s typically fine (circumstantially, it could be a problem if e.g. they want to do front-end, but cannot bear to ever look at JavaScript, but for most programmers, it’s fine).
On the other hand, if someone tells me they don’t have an interest, and won’t use version control, I do think they’re wrong, to the point of “I won’t argue with you on your hobby projects, but this is not a responsible way to write production code.”
If they don’t care about tools that enhance code navigation read broadly (I dunno, maybe rg is good enough?), I won’t judge the same way I will with VCS, but I will internally have quiet doubts about their choices.
If they don’t use autocomplete, I’m not inclined to judge, but in my head, I would ask “are you giving it a fair try?” And I would expect that someone would be curious about autocomplete. If you had only tried it once, years ago, I’d suggest you give it another shot.
Anyway, I’m not sure LLMs are even as much of a slam dunk as (normal, non-sparkling) autocomplete. They have higher upside, but also worse failure modes. But I do think curiosity is warranted.
If autocomplete cost $20 a month and required me to automatically submit my editor buffers to some behemoth with a dubious business model, then I don’t think it would take me 15 minutes to nope out of it either.
These things have costs, and not all of them are upfront either. I don’t want crutches in general, but I especially don’t want crutches that I can’t own.
This is a good point and its making me realize that the context of the technology matters a lot. I tried to be broad in my examples but its hard to map that to a technology that comes with so much weight (ethically, technically, environmentally, etc). Like, your example of source control is an interesting one because I do think that is a technology worth investing in and using not only because its a popular way to manage codeabases but because it’s walked thousands of miles in our industry and proven to be good practice. Can we say the same about code-assisting LLM’s? I don’t think we’re at that point yet where the benefit is ubiquitous.
Now I’ve conflated my own opinions with my original point that the example the author gives should not be as shocking as they found it and I think that is largely due to their own perceived usefulness of the tools. The irony I think is that the developer they talked to did try the tool and just didn’t care for the results enough to engage in a lengthy or detailed conversation about it.
That’s so simply effective, quirky, but still consistent. I don’t mind the one they seem to be going with, although it’s a bit boring in comparison (especially with the latest font choice, it feels like it’s starting to become a bit too ‘design by committee’).
No, you’re right, these are the ideal features of a website. One of the things that comes out of building websites like this is that they are inherently more accessible as well.
We worked heavily with GraphQL over the last year (working with Magento 2, specifically). I feel like a proposal like this can take out the need of GQL all together. It seems like a good idea.
Apples vs oranges. This is much, much lower level than GraphQL, which is a specific query language. This proposal is just a cleaner way to send any type of query.
There are various ways that GraphQL reinvents the wheel, and caching is one of them: since every GQL query is a POST, they can’t be cached by the HTTP layer. This would potentially allow caching to be pulled out of GQL and put in the HTTP layer where it belongs.
MVC never felt right to me on the web. I can’t tell if it’s I just don’t like MVC, it doesn’t map well to the web, or I don’t get along with Rails (where all of my web MVC experience is). Services seem like a much better fit. I tend toward a more anemic domain model, favoring services for actual business processes and testability.
It’s not cool to say, but Uncle Bob was right: the web should be an implementation detail, not something that runs ramshod over your whole architecture.
I agree with everything you’ve said. I think the domain model is variable in size depending on the scope of the project. For a simple blog like this? Absolutely tiny domain (more like a few discrete types than any domain interaction). That being said, if you have good interfaces to your services, incorporating them into the domain is dead simple.
I hope I can bring my thinking to more discussions at work where we have a lot of MVC-structured Express.js applications laying around that could benefit from refactoring into a more service-oriented organization.
Getting used to running Fedora 40 over Ubuntu. Made the switch late last week and the subtle differences in how they ship GNOME has caught me up. Thankfully with good dotfile discipline not a lot of my preferences or access keys were lost during the switch.
Other than that I am going to be getting ready for an off-set for all the leadership at my company where we’ll cry together and do personality tests or something like that. I’m not very excited for it.
Going to watch some live baseball for the first time this year! Other than that spend as much time with the family after a long week of my wife being on a work trip.
I’m not one to follow web trends (I just stick with nextjs and npm) but I’ve been interested to try Bun and see what all the hype (and venture funding) is about
You’re likely set in your tools for Node.js but imagine if all those tools just came with Node.js in the first place. In my line of work just having the typescript transpiler built into the runtime is a huge win.
Honestly a compelling argument, but I had hopes for Deno and it seems to be a constant hobby project - a joke I hear is the only production Deno software is the Deno homepage.
There’s also jsr.io that popped up recently too. I may experiment a bit with Bun, assuming Next.js works fine with it!
What makes you say that? I’ve got a good handful of Deno projects in production and am a huge fan at the moment. The tooling, Deno std lib, and npm compatibility make the project pretty compelling for me.
Oh it’s just a general vibe, anecdata not fact, I’m not aware of any businesses using Deno in production but I’m sure there are! What sort of products have you built with Deno currently? I’m quite curious how it stacks up against the rest - particularly in hiring/longevity discussions etc. (which is why I typically tend to advise companies I work with to just stick with the most boring and widely used tools)
Ah gotcha! As far as businesses using Deno, Slack is using it for their new automation platform, Netlify and Supabase for their serverless/functions offering, etc. It has some big deployments out there for sure!
The main Deno application we have in production is a small service that collects analytics on internal tools’ usage and reports it up to Datadog. It’s nothing big or shiny, but it works wonderfully and the repository is one of the simplest in our collection.
And I think your advice is correct, just for the record ;)
I don’t care enough about shell aesthetics so I just stick with bash. I type a command, it runs, gives me feedback, I’m happy.
I use a super minimal RHEL style prompt too that just showes me [$USER@$HOST $CWD]$ where the current working directory is the single level. I use Ubuntu as my main driver the Debian default prompt gets pretty unruly if I’m deep into projects.
Nah I am much more of a lager guy. I love pilsners, blondes. Stouts really don’t do it for me.
have you tried a black and tan/half and half? delicious w/ a burger
I have not but it does intrigue me! I’m not above trying new beers at all I just know where my preferences lay.
Same. I enjoy a good ale too, sometimes a brown ale. Go much darker than that and it’s pretty unappealing.
Conceiving of technical debt as dirty dishes is popular, although it could always stand to be even more popular.
Also do your dishes. Like, in reality. The ratio how happy it makes others who live with you vs. effort required is arguably higher than any other single act available to you. An enormous number of couples’ therapist salaries are made simply convincing people that doing the dishes is important.
My life has greatly improved since I got a dishwasher. What would that be in software terms?
Intellisense and a linter? You still need to pack/turn on/unpack a dishwasher; your code can’t clean itself but tooling can help make it faster for you than without it.
I used to be a “soaker” with the kitchen sink until we had a baby.
Nothing worse than waking up to make the kid some breakfast and having to wash every dish you need to get it done. Now I am steadfast on doing the dishes every night to start the day in a clean kitchen.
Maybe I should do this with code too.
I find it weird that they bundle s3 and postgres support directly into a runtime instead of having them as libraries. Looking at the documentation for s3, I see
and I get that it’s better to have a native implementation rather than a pure JavaScript one for speed (though I’m skeptic of their 5x claim). But I can’t see this approach scaling. If performance is a concern, then other services you communicate with also need to be fast. In particular Redis/memcached or whatever caching mechanism you prefer, but also ElasticSearch or maybe some Oracle database you need to talk to as well. Should those also be in the runtime? And how do you handle backwards compatibility for those libraries?
I guess this is just a long-winded way of saying “Why aren’t they implementing this as native add-ons and instead force this into the runtime?”. It feels much more modular and sensible to put it outside of the runtime.
Deno is doing the exact same thing so they are likely following suit. This is probably one of the ways Oven intends on monetizing the runtime.
My two biggest complaints are mostly to do with the API - one being that s3 is imported from bun, rather than
bun/s3or similar. Python provides a big stdlib, but the modules still have different names. You don’t dofrom python import DefaultDict, httplib, for example.The other one is that the
filefunction supports s3 URIs, which is nice from a minimal API perspective, but I also think it’s not ideal to treat s3 the same as local files. s3 has a lot of additional setup - e.g AWS credentials, handling auth errors, etc. So I think it makes sense to logically separate the behaviour for local vs remote files.I don’t mind new takes on AWS / postgres sdks, though. The SDK is pretty decent compared to some others (e.g Google or Slack), but I think both their AWS and postgress examples there (other than the two issues I mentioned) are pretty nice.
I agree with your sentiment and I am also very confused why I would use the Bun s3 implementation over the whole AWS SDK that I have been using and accustomed to for years now. Sure there could be some performance gains (for just S3) but I don’t see the benefit.
I’ve run into contention on S3 in a Python backend, and it’s really not fun. It’s a very good feature to have this sorted and guaranteed to work fast, it means that Bun can stay competitive with compiled languages for more intensive workloads. To me, this is a production mindset: identify the key components, and optimise them so that they don’t get in your way.
Kind of an aside, but on the topic of ligatures I was reading the docs on https://jotai.org and they use a ligature font in their examples. And I recognized it so it was fine… but seemed like a poor choice.
Like
⇒looks close enough to=>I suppose, but≡doesn’t look like===, and the examples are there to help people type out correct code, not read math.Obviously doesn’t matter the same way when you are in your own editor. Though I do imagine the ligature feels weird when you type
thiand then type the finalsand the cursor actually moves backwards.My take is that ligatures lie to the reader as to what is in the document. I am not going to judge anyone who uses them but they really bother me when I see them in code.
I feel like
thisin this post is in jest? Maybe?When I look at my groups of “normie” friends and family I find it very, very hard to think of them leaving the big platforms for ones more decentralized. Now, I am inferring this and I haven’t spoken at length about this, but they don’t seem to understand the difference or importance of these alternative platforms. Its just more weird tech shit they don’t want to bother with.
Why go to the alternatives when the big platform is still there, and everyone else is too?
But when I see the strides these communities are making to make it more accessible, and the quality of conversation and content I am seeing on the fediverse, anecdotally, gives me a lot of hope. I can probably convince my wife and a few friends to make the move, but ultimately I think the apathy towards digital life keeps users complacent and exactly where the Facebooks and Twitters of the world want their users to be.
I agree that it’s very hard to teach the theoretical benefits of decentralisation to normies, but the silver lining to how awful the internet has become in 2025 is that we can now demonstrate these benefits in practice.
We can point at Facebook, Twitter, Reddit and all the other platforms and how shittified they have become and how they could personally resist this enshittification if they were using equivalent decentralised platforms.
It would’ve been much harder to have this conversation 10 years ago, at the height of the free money era. But in 2025 you can already see the steam leaking through the seams.
I didn’t realize there was still a debate about this? I feel like the folks who did web development before the dawn of the SPA and these big frontend frameworks all knew this in their bones and felt vindicated (I know I did) when the JS community/ecosystem started pushing for frameworks with SSR.
Not only did we know it in our bones, it ended the period of a few years where talking about SSR labelled you as someone out of touch and refusing to get on the bandwagon. Definitely felt vindication when SSR started being discussed as an alternative rather than derided.
Also turns out one thing is not better than another, they all have trade offs, who could’ve guessed.
At work I am trying to juggle all the wants from the other departments with the finite resources that is my team.
Personally, I am trying to track down why the integration of the Odan session library in SlimPHP, with Twig templates, is not rendering flash messages on the template at all? It looks like the Flash class being called in the twig template is not instantiated with the
$_SESSIONvariables yet when adding messages to the Flash storage they are in$_SESSION.I’m one of the release managers for PHP 8.4 (I didn’t tag myself as author though, and I should probably update my hats). Ask me anything about PHP 8.4 I guess.
Congrats on another great release!
Is there more background / numbers on the JIT work?
The lazy object stuff seems a little niche. Does it really benefit DI if applied broadly, or is it more for manual marking of classes with expensive init?
Any personal favourites this release? :)
I’m not as familiar with the JIT or lazy objects, so I’ll defer there.
Database extensions are close to my heart, so the PDO changes should make those nicer.
I love some of these changes! I was joking with some friends of mine this morning that with every PHP release it inches closer and closer to C#. Is C# and the broader “enterprise” OOP world one of the big inspirations for some of these changes that get included in these releases?
Also not about this change but is it really that hard to get Generics into PHP?
There’s some stuff C# doesn’t have (but I haven’t touched it in years, so I might be wrong) like rudimentary ad-hoc sum types (i.e.
string|Callable). I think it’s more a general PLT zeitgeist thing; you see a lot of the same forces driving Kotlin, Swift, etc.Flags to make it php7.3 compatible?)
What BC changes in 7.3 affected you?
Check out “impact analysis and migration paths”:
https://wiki.php.net/rfc/deprecate-implicitly-nullable-types
I don’t understand what is so hard to comprehend about a complete lack of interest in a tool. Some people don’t ever want to bother learning a LISP, does that bother this author as well? Some people don’t want to use Linux as their main driver or would prefer a cheap keyboard over a fancy one with mechanical switches.
These kinds of posts have the effect of like “I really don’t understand this rube” - even though he’s explicitly trying to say that’s not his case - I think it still is. Let people who don’t want AI in their development tools not have it and go on with their lives. I don’t like olives but I don’t get lambasted by my wife for not trying some out of the jar like she does.
I think if you have a strong enough belief that it’s important enough to — as in this case — be one of your first questions about a new technology, then it’s important to be informed about that belief.
To use one of your examples, I am not interested in learning a lisp right now, but I don’t go out of my way to avoid looking at lisp code, and if you offered me a job working with lisp, the choice of language wouldn’t be my first concern. I have worked with people who will refuse to touch certain technologies with a bargepole (sometimes lisps, more commonly languages like PHP or Javascript), and almost invariably those people are uninformed and inexperienced with the technologies they’re talking about. The opinion is mainly formed out of hearsay and limited contact.
I think when you’re heavily involved in a technology, those sorts of opinions are the difficult ones to understand because they don’t fit with your knowledge. And not just your own personal preferences, but your knowledge and experience specifically. For example, you mentioned mechanical keyboards — if you came to me and said “oh, I looked into mechanical keyboards, but I wasn’t willing to spend so much money to try it out”, then I’d understand what you were saying — that is a largely true observation about mechanical keyboards. But if you came to me and said “I don’t like mechanical keyboards because they aren’t as ergonomic as a laptop keyboard”, then I’d be somewhat confused by that.
In fairness, in the article as written, we only have the author’s perspective, and I also find the tone of the article a bit excessive. But I do think that supposed technologists often form strong opinions about things with very limited experience, and I can understand the author’s frustration with this kind of behaviour.
I think it depends heavily on what type of tool you’re referring to. I agree that if someone isn’t interested in Lisp, or Javascript, or Rust, that’s typically fine (circumstantially, it could be a problem if e.g. they want to do front-end, but cannot bear to ever look at JavaScript, but for most programmers, it’s fine).
On the other hand, if someone tells me they don’t have an interest, and won’t use version control, I do think they’re wrong, to the point of “I won’t argue with you on your hobby projects, but this is not a responsible way to write production code.”
If they don’t care about tools that enhance code navigation read broadly (I dunno, maybe rg is good enough?), I won’t judge the same way I will with VCS, but I will internally have quiet doubts about their choices.
If they don’t use autocomplete, I’m not inclined to judge, but in my head, I would ask “are you giving it a fair try?” And I would expect that someone would be curious about autocomplete. If you had only tried it once, years ago, I’d suggest you give it another shot.
Anyway, I’m not sure LLMs are even as much of a slam dunk as (normal, non-sparkling) autocomplete. They have higher upside, but also worse failure modes. But I do think curiosity is warranted.
If autocomplete cost $20 a month and required me to automatically submit my editor buffers to some behemoth with a dubious business model, then I don’t think it would take me 15 minutes to nope out of it either. These things have costs, and not all of them are upfront either. I don’t want crutches in general, but I especially don’t want crutches that I can’t own.
This is a good point and its making me realize that the context of the technology matters a lot. I tried to be broad in my examples but its hard to map that to a technology that comes with so much weight (ethically, technically, environmentally, etc). Like, your example of source control is an interesting one because I do think that is a technology worth investing in and using not only because its a popular way to manage codeabases but because it’s walked thousands of miles in our industry and proven to be good practice. Can we say the same about code-assisting LLM’s? I don’t think we’re at that point yet where the benefit is ubiquitous.
Now I’ve conflated my own opinions with my original point that the example the author gives should not be as shocking as they found it and I think that is largely due to their own perceived usefulness of the tools. The irony I think is that the developer they talked to did try the tool and just didn’t care for the results enough to engage in a lengthy or detailed conversation about it.
This one is my favorite: https://github.com/CSS-Next/css-next/issues/105#issuecomment-2269099876
It truly represents CSS. I love it.
That’s so simply effective, quirky, but still consistent. I don’t mind the one they seem to be going with, although it’s a bit boring in comparison (especially with the latest font choice, it feels like it’s starting to become a bit too ‘design by committee’).
No, you’re right, these are the ideal features of a website. One of the things that comes out of building websites like this is that they are inherently more accessible as well.
I completely agree with your sentiment.
Largely better for security, privacy, & saving data too
We worked heavily with GraphQL over the last year (working with Magento 2, specifically). I feel like a proposal like this can take out the need of GQL all together. It seems like a good idea.
Apples vs oranges. This is much, much lower level than GraphQL, which is a specific query language. This proposal is just a cleaner way to send any type of query.
There are various ways that GraphQL reinvents the wheel, and caching is one of them: since every GQL query is a POST, they can’t be cached by the HTTP layer. This would potentially allow caching to be pulled out of GQL and put in the HTTP layer where it belongs.
MVC never felt right to me on the web. I can’t tell if it’s I just don’t like MVC, it doesn’t map well to the web, or I don’t get along with Rails (where all of my web MVC experience is). Services seem like a much better fit. I tend toward a more anemic domain model, favoring services for actual business processes and testability.
It’s not cool to say, but Uncle Bob was right: the web should be an implementation detail, not something that runs ramshod over your whole architecture.
I agree with everything you’ve said. I think the domain model is variable in size depending on the scope of the project. For a simple blog like this? Absolutely tiny domain (more like a few discrete types than any domain interaction). That being said, if you have good interfaces to your services, incorporating them into the domain is dead simple.
I hope I can bring my thinking to more discussions at work where we have a lot of MVC-structured Express.js applications laying around that could benefit from refactoring into a more service-oriented organization.
Complete non-sequitur, but I would love to know what software was used to create the diagrams. They are very clean and concise.
draw.io for the first two and mermaid for the last one, you can get them here if you want to poke around
Thank you! I highly appreciate this!
Such a poignant statement. You’re not making it easier you’re just shifting where ops are done.
Far too many companies adopt “devops” by discarding all their operational knowledge. There, it’s solved!
Operating is not their core competency.
Its so funny because “ops” is literally in the name “devops”.
Getting used to running Fedora 40 over Ubuntu. Made the switch late last week and the subtle differences in how they ship GNOME has caught me up. Thankfully with good dotfile discipline not a lot of my preferences or access keys were lost during the switch.
Other than that I am going to be getting ready for an off-set for all the leadership at my company where we’ll cry together and do personality tests or something like that. I’m not very excited for it.
Going to watch some live baseball for the first time this year! Other than that spend as much time with the family after a long week of my wife being on a work trip.
Finally! I can try it on my computer!
I’m not one to follow web trends (I just stick with nextjs and npm) but I’ve been interested to try Bun and see what all the hype (and venture funding) is about
You’re likely set in your tools for Node.js but imagine if all those tools just came with Node.js in the first place. In my line of work just having the typescript transpiler built into the runtime is a huge win.
Honestly a compelling argument, but I had hopes for Deno and it seems to be a constant hobby project - a joke I hear is the only production Deno software is the Deno homepage.
There’s also jsr.io that popped up recently too. I may experiment a bit with Bun, assuming Next.js works fine with it!
What makes you say that? I’ve got a good handful of Deno projects in production and am a huge fan at the moment. The tooling, Deno std lib, and npm compatibility make the project pretty compelling for me.
Oh it’s just a general vibe, anecdata not fact, I’m not aware of any businesses using Deno in production but I’m sure there are! What sort of products have you built with Deno currently? I’m quite curious how it stacks up against the rest - particularly in hiring/longevity discussions etc. (which is why I typically tend to advise companies I work with to just stick with the most boring and widely used tools)
Ah gotcha! As far as businesses using Deno, Slack is using it for their new automation platform, Netlify and Supabase for their serverless/functions offering, etc. It has some big deployments out there for sure!
The main Deno application we have in production is a small service that collects analytics on internal tools’ usage and reports it up to Datadog. It’s nothing big or shiny, but it works wonderfully and the repository is one of the simplest in our collection.
And I think your advice is correct, just for the record ;)
The folks at val.town are also using it in production in the current iteration of their runtime.
Oh snap! I didn’t realize val.town was using Deno! I’ll need to take a second look!
Oh nice, that’s much better than I thought, I’m glad Deno is seeing some success in the enterprise world! Thanks 😁
Yeah, never again the bullshit of having to figure out node-ts/ts-node. It should just run.
I don’t care enough about shell aesthetics so I just stick with bash. I type a command, it runs, gives me feedback, I’m happy.
I use a super minimal RHEL style prompt too that just showes me
[$USER@$HOST $CWD]$where the current working directory is the single level. I use Ubuntu as my main driver the Debian default prompt gets pretty unruly if I’m deep into projects.