They keep doing it: https://twitter.com/dmitriid/status/1625756307297914883
7,372 karma · joined February 19, 2008
Because there are a million ways to generate that code (if we're talking about the browser), and they will all break when coming into contact with reality.
- your sizes are in em/rem, and your root font size is off? Goodbye design
- you absolutely need something at the bottom of the screen (think media controls), and you have absolute positioning? Goodbye design for large combinations combination of screen/positioning
- you need something centered on, say, third element from the right? And then another element is added on the left? Goodbye design
- you need something animated? Goodbye design
- etc. etc. etc.
However, for some established patterns you might get away with some standard design choices and some generated code
Welcome to large companies (who may still get more people browsing from IE than populations of entire countries) and government agencies (good government agencies cannot afford not to support a wide array of old, weird, and unsupported browsers)
That's one side of the coin. The other side is that the VM all but guarantees that a crash in a process will not bring the VM down and that you can get a notification that the process died.
Says the person who goes on a rambling rant with cussing, personal attacks, and little to no substance.
Every time you show in anyone's replies this really is all anyone can expect.
I believe you've already had multiple warnings on that from HN moderators.
So, at this point, adieu.
Reminds me of Marie Condo, who eased up on tidying, and it's no longer her top priority, after having kids: https://www.cnn.com/2023/01/30/entertainment/marie-kondo-sto...
Because on iPhone the app is completely sandboxed. Think Docker, with virtualised OS paths, but on OS level. When Apple tried to introduce a very light version of sandboxing, the world was ablaze in pitchforks and torches.
It quite literally is. In there desire to push web components they also pushed quite a few (often questionable) solutions. See 17:59 here: https://youtu.be/y-8Lmg5Gobw
> But I'm glad we do not have to deal with dozens of ways to do OOP in JavaScript anymore.
There never were "dozens of ways". There always was only one: prototype based. And now there's this weird contraption on top that pretends its classes from C++-like languages (C++, Java, C# etc.) but is not.
It is, because classes are a thin wrapper over prototypes, but the whole "classic C++-like" class shenanigans translate very poorly to Javascript. And yet, with maddening bravery browsers have spent 10 years trying to make them work in some capacity (and don't get me started on the whole private members thing, or the autobind proposals, or...)
You do indeed need to understand prototypes to explain this behavior. "Free functions" doesn't really make sense, because it obviates the need for classes.
In mid-late-2000s when the first idea of adding classes to the syntax came up, even Microsoft eventually said: nah, it's a bad idea. It's grafting incompatible concepts onto a language that doesn't need them.
And then Google in their "wisdom" went and forced classes onto the language. Take a guess why you need this for methods to work the way you expect them:
class Logger {
constructor () {
this.method = this.method.bind(this);
}
method (some, params) {
this.do_stuff()
}
/// ...
}Most JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step.
> Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different.
So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so.
Also, JS world is probably unique among all programming languages with such aversion towards anything even remotely resembling compilation. Which is ironic, given that transpilation (aka converting from non-existent and future syntaxes to existing one) is Javascript's bread and butter.
> The optimizations might not be ahead of time, but the net is
> there's still a lot of room for reusing the same "compiled"/parsed work.
As opposed to what? To compilers/transpilers that can, and do, the same thing? And can do significantly more things like run whole-program optimisations. Or, like Solid, can just remove the need for components in the resulting code.
The world already agreed about 40-50 years ago that programming with strings is a bad idea. And now JS purists are willing to die on this hill (while inventing bizarre justifications and increasingly bizarre DSLs for anything remotely complex, see lit-html).
And of course there's nothing wrong, or "worse" with DSL, or compilation. As evidenced by compiled frameworks being blazingly fast: https://krausest.github.io/js-framework-benchmark/2023/table... and
The amount of things that are optional on the protocol level is... basically everything.
If your USB-C plug only provides charging, it's USB-C compliant, and if I understand it correctly, will get a USB-C certification.
Anything you shove into a string and then parse yourself is "compatible with the language". Doesn't make it better or significantly different from systems that do this step earlier.
Funny how this significant blow never happened on the world's most dominant OS where all the restrictions that HN loves to whine about don't exist.
I can't believe people keep saying this with a straight face. It's as if they've never seen an proper native app before (any of the third-party clients to Twitter come to mind before they were axed). Or haven't seen actual good fast implementations like the one Twitter actually bought and surprisingly still kinda maintains (see on desktop, https://tweetdeck.twitter.com/)
Of course it's not. The "lightweight ones" have a cord connecting them to the actual device. The others are bulky and work for a few hours at most. You can't cheat physics.
Of course they are not. The media attention is a short-lived one, and Bung is yet to prove it won't SWAT users: https://simonwillison.net/2023/Feb/15/bing/
Dude. I'm 42
> And that powers quite a bit of compute
On a tiny screen, mostly idle, with most complex things driven by phone.
You want a continuous compute with a large projected screen on your face.
It's not "just a matter of time".
A "straightforward" feature that requires packing cpu, gpu, ram, battery and screen into form factor of glasses.
Meanwhile Android is 70% market share worldwide with that desired "full PWA support". Where are these amazing PWAs?
Ma, look, a segregationist.
Meanwhile frameworks and libs (even those who originally were very supportive of the idea of web components) have moved past WCs and are exploring approaches that WCs will never ever be able to provide such as granular reactivity, seamless frontend-backend integration, or even eschewing components as a rendering primitive entirely.
> React is going to keep winning until the standards furnish comparable ergonomics.
In all honesty, Scoped CSS + Nested CSS proposals coupled with https://open-ui.org would've solved 99% of what web components are trying to be.
Meanwhile we're about 20 years away from WCs as a finished thing: https://w3c.github.io/webcomponents-cg/2022.html