Programmer Matthew Phillips has an “unpopular opinion” that he shared via — where else — the X platform (formally Twitter):
“Don’t use http verbs PUT, PATCH, DELETE. Just use POST for everything,” the creator of web framework Astro and Lucy Lang wrote. His reasons for this, in his own words:
The tweet solicited responses that ranged from “Nope” and “Yes, that is an unpopular opinion” to more nuanced opinions.
Christian Findlay, an Australian programmer who works with Flutter and dotnet, went a step further, responding that he cannot see any benefit to the REST “pseudo” standard at all.
“The only exception would be large-scale systems that need a standard REST API for mass public consumption,” Findlay wrote. “HTTP was designed in different era and the prescriptive verbs don’t make a lot of sense.”
Simon Willison, who co-created Django, shared that he is an also “a member of team ‘don’t bother with verbs beside GET and POST.’”
“I’ve never encountered an API that uses them and thought ‘Great, this will make this API easier to understand and use,” he said. “It’s been way over a decade — I’m ready to say that I haven’t found the value in them.”
Jake Archibald, engineer at Shopify, also added his support to Phillips.
“GET vs POST have meaningful behavior differences in browsers. Use GET for stuff without side-effects, otherwise, use POST,” Archibald wrote. “The other verbs? Nah. I’ve always found it easier to be expressive in the URL than the HTTP verb.”
Maciej Nux, tech lead on a library systems company and a self-described JavaScript native and security freak, pointed out there are security benefits to DELETE/PUT.
“From a security perspective DELETE/PUT is safer because you cannot use them in forms,” he wrote. This blocks some attack vectors (CSRF). You could add some extra layers, but being safer by default is nice.”
“I think you’re in trouble if that’s your attack mitigation,” Archibald responded.
To which Nux countered, ”For me, security is always layers. Layers upon layers. And this one doesn’t cost much. For me at least.”
Several people piped up to say the problem is REST, which, they pointed out, isn’t a standard and is based on an old web paradigm. Not everyone was anti-REST, though.
“I think REST is amazing and beautiful and I wish people would take the time to actually learn how to do it,” Brantly Harris shared. “Unfortunately that has never happened, so I’m coming around to your position. Mostly out of spite, though.”
Yarn version 4.0 was released on Monday. Yarn is a package manager for JavaScript and TypeScript applications and an npm alternative. It’s faster and includes several major changes of note, according to lead maintainer Maël Nison.
Nison wrote that version 4.0 is “significantly faster at installs” than version 3.6
“For instance, here’s the difference in time to install Gatsby and its ~350MiB dependency tree from a cold cache,” he wrote. “The 3x improved performances are due to a new package metadata cache which significantly improves performances of repeated installs…”
A major change for those updating from version 3 is that version 4.0 requires Node.js 18+ to use, Nison wrote. Other noteworthy changes include:
The introduction of a Hardened Mode will cause Yarn to perform two extra validations, which he explains in the blog post are checking that, first, the resolutions stored in the lock file are consistent with what the range could resolve to; and second, that the package metadata stored in the lock file is consistent with the remote registry metadata.
“The Hardened Mode is enabled by toggling on enableHardenedMode, but it’s also automatically enabled when Yarn detects that it runs within a GitHub pull request on a public repository,” the post added as a tip. “This can be disabled by explicitly toggling off enableHardenedMode in your yarnrc file.”
There are also changes to the team’s recommendations for installing Yarn; including there’s no longer a need to rely on yarnPath when installing, because Corepack is shipped with both Node 18 and 20.
Nison also explains the JavaScript constraints, claiming that Yarn is the only package manager to implement a constraints engine.
“If you don’t know it, this feature lets you define a set of rules that your project must satisfy. For instance, the Yarn repository enforces that no two workspaces depend on different versions of any given dependencies, unless explicitly allowed,” he wrote.
The constraints engine was powered by Tau-Prolog, a JavaScript Prolog implementation that will be deprecated due to its complexity. It’s been replaced by a new JavaScript-based engine with optional TypeScript support. Also, Yarn has decided to incorporate all the features and commands it builds now as part of the main distribution, rather than as third-party plug-ins, which are still supported.
“The journey to transition from Yarn 3 to Yarn 4 was a lengthy one, with a whopping 53 release candidates along the way, but we finally made it!” Nison wrote. “Our aim for this new iteration has been to both decrease Yarn’s learning curve and improve your user experience, without the migration feeling overwhelming.”
Node.js was released last week and updates the V8 JavaScript engine to 11.8. It also includes stable WebStreams to help process data in all sizes for browsers.
“If you’re interested in getting access to interesting new features early, Node.js 21 is a great way to test and see what’s coming. Our release schedule specifically covers this. If you’re already in active deployment or if you are planning for it, Node.js 20 and 18 LTS are for you,” Rafael Gonzaga, Node.js technical steering committee member, said in a prepared statement.
Node.js 21 has a new experimental flag to flip module defaults. It also incorporates new security measures, which Gonzaga credited to the work of OpenSSF and Project Alpha Omega.
Node.js 20 has been promoted to long-term support.
