> Which is a little odd, and the value is questionable, but fundamentally seems...fine? You're a merchant, you're selling pencils on the internet, people are buying your pencils from you.
Why not apply your exact "its fine" standards to Amazon too ? Standards go BOTH ways, after all.
> In November, Amazon sent a cease-and-desist letter to Perplexity over its new Comet browser, which lets users ask an AI agent to find and buy items on Amazon. In a statement, Amazon said third-party shopping agents should “operate openly and respect service provider decisions” on whether or not to participate.
These people want Amazon to "respect service provider decisions" - just like Amazon demands of other people.
Yeah, seems like there’s a big fight brewing over losing the status quo of having control of how humans interact with stuff, as agents come along and make it so we don’t need to wind our way through the digital ad mazes they’ve constructed to do things.
But the incumbents who don’t want to allow this seem destined to lose, this is a tsunami coming, where this is just obviously how things will be done in the future once performance is good enough, and any group who tries to force customers into the old way is just not going to succeed for one reason or another. This is just how the market is shifting.
More proof that a nation with "world reserve currency status" can do whatever the hell it wants until the world decides to move to other currencies. Alas, such nation is using violence (abduction+piracy+war), threats and coercion to ensure that never happens.
> It could be the continued lack of DOM bindings that have been considered a key missing piece for several years now, or maybe something else or more fundamental.
No, it is NOT "something else or more fundamental" - it is most certainly the lack of proper, performant access to the DOM without having to use crazy, slow hacks. Do that and frontend web-apps will throw JS into the gutter within a decade.
Let's not go into that for the millionth time and instead perhaps ask yourself why is TS wildly successful and even before that everyone was trying to use anything-but-js.
Ok, that's fair. My goal with this question wasn't to open a can of worms. But whenever I see a strong averse reaction to JS, I assume that the person hasn't tried using _modern_ JS.
> why is TS wildly successful
From my perspective, it stops me from making stupid mistakes, improves autocomplete, and adds more explicitness to the code, which is incredibly beneficial for large teams and big projects. But I don't think that answers my original question, because if you strip away the types, it's JS.
> even before that everyone was trying to use anything-but-js
Because JS used to suck a lot more, but it sucks a lot less now.
I'm not sure if this is meant to be snarky or if you're saying that the languages you listed have improved over time. If you're being snarky, you've proven my point by saying several random programming languages are better than JS while providing zero justification.
It's a complement to my other answer to you (about your Q on why ppl would not want to learn/use js and would prefer WASM if there was FastDOM ==> because not everyone wants to be multilingual): I was listing a few languages that people are confortable with and would rather use through WASM than learning idiomatic JS/TS ( it's easy to learn the syntax, it takes practice to learn the idiomatic way).
And yes, I do meant that my listed have gotten better, just like JS/TS.
As for why not comp/transpiling to JS? it is my impression that WASM was born out of that ( Compiled to subset of js (asm.js)) and it's an evolution of compiling to JS.
Ah, my bad. I apologize if I came off as too aggressive. I know these comment threads can get heated.
As far as the comp/transpiling thing, I was referring to something like ScalaJS, ClojureScript, Kotlin/JS, etc. I'll admit that the JS output isn't always pretty, but it's still JS. I think that compiling to a Wasm module is different than transpiling, because Wasm is more of a black box.
I think it's fine to ship a `.wasm` file that does some kind of computation and complements the app. But I think shipping a `.wasm` file that builds your UI is like using a drill to install a nail: technically, you could do it, but it's harder, slower, and you'll probably end up damaging something or hurting yourself.
>From my perspective, it stops me from making stupid mistakes, improves autocomplete, and adds more explicitness to the code, which is incredibly beneficial for large teams and big projects. But I don't think that answers my original question, because if you strip away the types, it's JS.
I think it sort of does answer that - if js was not an awful language, there would be no need for TS, even if TS just a band-aid. Even better, if browsers provided a compile target, bytecode/vm spec or whatever instead of a very bad language everyone has to use, we would be spared of close to three decades of evolving tooling that is trying to remedy that bad decision.
> I think it sort of does answer that - if js was not an awful language, there would be no need for TS.
Eh, I disagree. For me, this statement is the equivalent of saying "if Python was not an awful language, there would be no need for mypy" or "if Ruby was not such an awful language, there would be no need for Sorbet". I don't think mypy or Sorbet improves the underlying languages; they just add some additional DX to prevent those aforementioned stupid mistakes.
I wasn't trying to be disingenuous when I asked what was wrong with JS. You've now referred to it as "awful" and "very bad". I have used other programming languages pretty extensively, and JS seems fine to me. When I asked you why it was bad, you hand-waved it away, saying "let's not go into that for the millionth time". When I see statements like that, I immediately think "oh, so this person is just jumping on the bandwagon without providing objective reasons for why this language is bad". If you think that JS is bad and awful, fine, that's your opinion. But whenever I have a negative opinion on something and I'm presented with compelling evidence to the contrary, I re-evaluate my reasons for why I think it's bad and possibly change my mind.
At the end of the day, if you want to hate on JS and hope for a browser compile target that lets you use any other language than JS to build web apps, that's your prerogative. I was a web dev for almost 10 years, and I've seen the improvements to the language and ecosystem over time. So whenever I encounter the "LoL Js SuCkS" mindset, it grinds my gears a little bit.
> For me, this statement is the equivalent of saying "if Python was not an awful language, there would be no need for mypy"
This analogy breaks down because if Python does not fit your preferences or the needs of your project, you can use any other language. You can't do this for JS if you have to write for the browser. Well technically you can transpile but that is leaky so in some capacity it still will be JS. And that is the issue.
> I wasn't trying to be disingenuous when I asked what was wrong with JS.
I'm just tired after decades of this. I will gladly use any language I have ever used profesionally instead of JS (so no VB please, but give me Perl, Tcl, Java, PHP, C, whatever). Just yesterday there was this: https://news.ycombinator.com/item?id=46589658
I have seen the improvements too. And the language is getting better, but by now the whole ecosystem including TS and all frameworks is hopelessly infected. And I don't even see the meaning of giving concrete examples because it's just so overwhelmingly frustrating I wouldn't know where to begin or end.
I don't mean to split hairs here, but considering the wording of "throw something in the gutter", I would argue that "hate" isn't really too far off the mark.
> Wasm with 'fast' DOM manipulation opens the door to every language compiling to wasm to be used to build a web app that renders HTML.
This was never the goal of Wasm. To quote this article [1]:
> What should be relevant for working software developers is not, "Can I write pure Wasm and have direct access to the DOM while avoiding touching any JavaScript ever?" Instead, the question should be, "Can I build my C#/Go/Python library/app into my website so it runs with good performance?"
Swap out "pure Wasm" with <your programming language> and the point still stands. If you really want to use one language to do everything, I'm pretty sure just about every popular programming language has a way of transpiling to JS.
Wasm is essentially a CPU in the browser. It's very barebones in terms of its capabilities. The DOM API is pretty beefy, so adding DOM support to Wasm would be a massive undertaking. So why add all that complexity when you already have a perfectly capable mechanism for interacting with the DOM?
That "perfectly capable mechanism" is one-off JS glue code, which is so cumbersome that approximately nobody actually uses it even though it's been an option for at least 6 years. It would be silly to mistake that for a satisfactory solution.
From my (outsider) perspective, I think the main roadblock atm is standardizing the component model, which would open the door to WIT translations for all the web APIs, which would then allow browsers to implement support for those worlds into browser engines directly, perhaps with some JS pollyfill during the transition. Some people really don't like how slowly component model standardization has progressed, hence all the various glue solutions, but the component model is basically just the best glue solution and it's important to get it right for all the various languages and environments they want to support.
I think maybe you misunderstood what I meant. When I said "perfectly capable mechanism", I meant building the app in JS/TS and leveraging Wasm for additional functionality in your language of choice. I'm also not sure if the "one-off JS glue code" you're referring to is the JS file that languages like Go or tools like Emscripten spit out to get Wasm to work with your app, or the WebAssembly Web API specifically. I would agree that the former is a bit of a dumpster fire.
There's not some conspiracy that's stopped it from happening. Nobody, anywhere, has ever said "DOM access from WASM isn't allowed". It's not a matter of 'allow', it's a matter of capability.
There's a lot of prerequisites for DOM access from WASM that need to be built first before there can be usable DOM access from within WASM, and those are steadily being built and added to the WASM specification. Things like value references, typed object support, and GC support.
but how would you do that otherwise? Genuinely curious cause I looked up both the go docs and source (disclaimer: not a go dev), and there doesn't seem a way to handle that specific kind of error through stuff like `errors.Is`, at least from what I can tell, at least in the os and fs packages
Java has features that Kotlin does not have. Virtual Threads and the API's that support then are effectively incompatible with the Kotlin co-routine libraries.
technically, Kotlin can use VirtualThreads like it can use any other Java Api
(when being compiled to JVM bytecode).[1]
If I remember correctly the Kotlin team was e.g. thinking about implementing a Coroutine Dispatcher with VirtualThreads.
So building a Kotlin service that uses Virtual Threads instead of coroutines is -in principle- possible. But if you've got a Java project using Virtual Threads you could rewrite it slowly -class for class- to Kotlin (and later probably refactor the VirtualThreads to coroutines).
What you have to keep in mind though: if you're creating a Kotlin lib that is meant to be used by Java then the public Api of this lib should include suspend functions!
My company made that mistake at some point, they ordered a lib from an external supplier and since Java and Kotlin are both first class languages and "Kotlin is compatible with Java", they ordered this lib in Kotlin. They learned the hard way that Kotlin suspend methods translate to Java methods returning a Continuation class (!? If I remember correctly. I wasn't part of that project, but heard their story) which is very unergonomic to use manually. The fix was to write a small Kotlin shim lib that wrapped the other lib and replaced every suspend function with a normal function invoking their suspend counterpart in a runBlocking-block (I think). Hardly ideal, but workable. So yes, writing a Kotlin lib that's (also) meant to be consumed from Java requires more thought than one that is only meant to be used by Kotlin. (There is functionality in Kotlin to help with this though, e.g. look up the annotations @JvmStatic, @JvmName, @JvmRecord.)
They never run out of "their" money either. Can keep borrowing until eye-watering values are breached, making out like bandits and then run to the govt for a bailout when the bubble bursts.
I have observed that people who are used to Onenote mainly like it for its inline-box style notes which can be inserted at any point in the page. Obsidian due to its markdown backend can't support this. Unless you painfully mess with tables, you have to stick to linear top-down approach and don't have free-form flexibility.
Ahh yes could be. And people taking notes on tablets with pens perhaps. I hate that because I have the fine motor skills of a 2 year old. My handwriting is still a mess and very slow. Despite this being the only way to get through school in my time.
I always hate when OneNote opens random text boxes when I click somewhere. But yeah some people could like that too.
You have to fix your problems yourself. I say this as a citizen of a nation in South-East Asia. Do not depend or cheer external actors like the U.S. to solve internal issues - they will only use and throw you away. The U.S. is also a nation whose political culture respects only strength - they hold absolute contempt for soft, weak/poor and divided nations. A home-grown dictator is better than a foreign one promising "democracy". It is one of the reasons that the U.S. regularly takes leadership out - they would like nations in their sphere to remain weak, poor and/or fully economically dependent.
You can look forward to U.S. oil companies doing free looting now. Sure, the "trickle down" effect will make some Venezuelan's prosperous but you have effectively given up the resources of your nation and chosen to become subservient slaves. And U.S. billionaires will become even richer.
reply