QOI is just a format that’s easy for a programmer to get their head around.
It’s not designed for everyday use and hardware optimization like jpeg-xl is.
You’re most likely to see QOI in homebrewed game engines.
QOI is just a format that’s easy for a programmer to get their head around.
It’s not designed for everyday use and hardware optimization like jpeg-xl is.
You’re most likely to see QOI in homebrewed game engines.
Are you not made primarily of water?
The syntax is only difficult to read in their example.
I fixed their example here: https://programming.dev/comment/12087783
I fixed it for you (markdown tables support padding to make them easy to read):
markdown | table |
---|---|
x | y |
|markdown|table|
|--------|-----|
|x |y |
Chromium had it behind a flag for a while, but if there were security or serious enough performance concerns then it would make sense to remove it and wait for the jpeg-xl encoder/decoder situation to change.
It baffles me that someone large enough hasn’t gone out of their way to make a decoder for chromium.
The video streaming services have done a lot of work to switch users to better formats to reduce their own costs.
If a CDN doesn’t add it to chromium within the next 3 years, I’ll be seriously questioning their judgement.
I’m under the impression that there’s two reasons we don’t have it in chromium yet:
Google already wrote the wuffs language which is specifically designed to handle formats in a fast and safe way but it looks like it only has one dedicated maintainer which means it’s still stuck on a bus factor of 1.
Honestly, Google or Microsoft should just make a team to work on a jpg-xl library in wuffs while adobe should make a team to work on a jpg-xl library in rust/zig.
That way everyone will be happy, we will have two solid implementations, and they’ll both be made focussing on their own features/extensions first so we’ll all have a choice among libraries for different needs (e.g. browser lib focusing on fast decode, creative suite lib for optimised encode).
That’s 41 degrees for everyone who doesn’t measure things in bird per gun.
What to know about blue supermoons:
I’ve got to say, seeing this:
https://github.com/zed-industries/zed/network
instead of something like this:
https://fork.dev/blog/posts/collapsible-graph/
or this:
https://miro.medium.com/v2/resize:fit:4800/format:webp/0*60NIVdYj2f5vETt2.png
feels pretty damn legacy to me.
My long bet: The EU will force Google Search + Ads, to separate from Youtube within a decade.
Did you purge and update your filters?
Note: I’m not talking about turning filters off then back on, I’m talking about updating the version of each filter itself.
it looks like JS/TS with arrow functions.
JS/TS already has arrow functions.
That’s not pro, that’s just reckless gambling.
It sounds like to me that you’ve taken your knowledge of your commonly used languages for granted, and assumed a new language would be just as easy. But if you watch a developer who is dipping their toe into that ecosystem for the first time you’ll find them making mistakes and running into footguns you didn’t know were possible.
Regardless of the language, not having a proper guide leaves devs susceptible to the incorrect blogospam that’s out there, where engagement is rewarded over correctness.
Ignore all of the blogospam.
The two things you need to know:
Here’s my shortened version of number 2.
The beginning:
The false start:
The resumption:
async
/await
/Promise()
syntax sugaring, to make asynchronous programming easier
(rest/spread operator) syntax sugaring, to make destructuring and variadic functions easier??
Nullish coalescing operator syntax sugaring??=
/&&=
/||=
Logical assignment syntax sugaringThe current state of things
Language-wise
Runtime-wise
Standard workflow
Tooling wise
For your simple fibonacci example:
console.log()
and see result in browser’s console.Deno.serve()
and see result in network requests/responsesconsole.log()
and see result in terminalThis comment just seems weird no matter which angle I try to approach it from.
immature tooling ecosystem
It’s over a decade old now. I wouldn’t call that immature.
Looking at your linked comment…
following a basic tutorial somehow ended up spending multiple seconds just to transpile and run “Hello, World!”.
hello.ts
containing: console.log("hello world");
deno run hello.ts
(time taken to run command: 0.037s)[…] 3 different ways of specifying the files and settings you want to use […] 3 incompatible ways to define and use a “module”
Yes, that tends to happen as ecosystems evolve over time. Typescript allows developers to use modern standards-compliant modules, while maintaining backwards compatibility for older code.
embracing duck typing means […]
One of typescript’s strengths is that its type system isn’t all or nothing. Typescript will support duck typers, but it isn’t forced or limited to that. You can add as much or as little typing as you want. In theory, this means that the language supports simple beginners up to experts creating turing-complete theorem solvers at compile time. In practice, this means a much smoother onboarding and porting experience.
Have a “generalized fibonacci” module taking 3 inputs […]
I’m not sure if this is the basic problem challenge or the hello world example was. It seems a bit ambiguous as to what you really want, but it’s easy to create a module that takes inputs and produces outputs while running on backend servers, in browsers, and in CLIs.
“the means” in this case would be authoritarian repression.
“The means” always has to be something bad for the “ends” to try and justify reaching for “the means”.
I’m curious why people would downvote a request for port forwarding?
I thought I loved ts-node, since it’s a good patch over some annoying issues in node.
But I retried deno a few months ago (after having first tried it when it first came out) and I realised that I only ever liked ts-node, and that I actually loved deno.
Deno just ran ts as if it was ts-node without needing a dependency, or startup time, or any prior setup, and it did it so fast I thought something was wrong. It was great.
This doesn’t seem overly useful.
It’s a list taken out of a bunch of books with no regard for how something can be the best path in one language and a smell in another language.
Look at this page for example: https://luzkan.github.io/smells/imperative-loops
It suggests using functional loop methods (
.map()
,.reduce()
,.filter()
) instead of using imperative loops (for
,for in
,for each
) but completely disregards the facts that imperative loops also have access to thebreak
,continue
, andreturn
keywords to improve performance.For example: If I have an unsorted list of 1000 cars which includes a whole bunch of information per car (e.g. color, year manufactured, etc…), and I want to know if there were any cars were manufactured before the year 1980, I can run an imperative loop through the list and early return true if I find one, and only returning false if I haven’t found one by the end of the list.
If the third car was made in 1977, then I have only iterated through 3 cars to find my answer.
But if I were to try this with only functional loops, I would have to iterate through all 1000 cars before I had my answer.
A website with blind rules like this is going to lead to worse code.