Don't forget that he's also shaming everyone for complexity while his own work brings untold complexity to the web platform through dozens of Javascript-only standards around Web Components.
7,372 karma · joined February 19, 2008
Now that's commitment to backward compatibility (and they can't have it any other way, they won't rewrite half of facebook just because their own framework changed).
The increase in resources available since 200s is measured in orders of magnitude. Are there similar increases in software features that warrant the increased bloat?
> I still remember how bad it was before electron as a windows user. Half the apps that seemed cool(omnifocus, bear notes) had mac only desktop version, other(1password, evernote) had a native windows version that felt ugly and unpolished.
Now all apps are ugly and unpolished
Quoting myself: "the achievement is still nothing short of miracle" ;)
No one cared about the "non-nerd" until these two came along. Because sure "you can alway select <one of thousands distributions> and <build/compile/config your own stuff>", but this doesn't scale.
Even if this started as a way to keep being relevant in the world of competing OS-level stores and shenanigans (IIRC Steam for Linux started shortly after Windows Store was announced), the achievement is still nothing short of miracle: there are actually games you can play on Linux now.
That's what Javascript got surprisingly right IMO: you can target the latest bleeding edge features, and still be able to compile and run them on 20-year-old browsers through code re-writing (aka transpilation) and polyfills [1]
I often wish this was available for other languages, too.
[1] Well, not all features because some if them are notoriously hard to polyfill (IIRC Proxies are one such unpolyfillable feature). And there's the huge issue of the entire world relying on just one guy: https://github.com/zloirock/core-js/blob/master/docs/2023-02...
> Maybe in 4-5 years this will finally be a solved problem...
Of course it won't. And of course it won't be HTML.
Thing is, Webkit wanted to start with HTML and with all things declarative [1] Google wanted to "move fast".
Result? The need a few dozen more standards to patch deficiencies in WC design, and most of those standards involve piling more and more Javascript on top. See this 2022 status report: https://w3c.github.io/webcomponents-cg/2022.html
So now we are in year 12 of this catastrophe, and you are expecting it to end in another 4-5?
If you want to build non-JS sites, web components won't save you. They require JS. They cannot work without JS.
You're much better off using Next, Nuxt, SvelteKit, SolidStart, Marko... Anything that doesn't use them.
[1] https://twitter.com/rniwa_dev/status/1352322006448947203?s=2...
While it really is bad, it offers things that need to be reimplemented by everyone from scratch if they go with Canvas, WebGL or WebGPU such as:
- accessibility
- text rendering (including proper font rendering, LTR text, multilanguage text, text selection etc.)
- even smaller things like tabindex
To quote Rich Harris, the author of Svelte, on the whole web component saga: "It's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1]
[1] https://twitter.com/Rich_Harris/status/1513668040784814084
Besides, if you need components, web components are probably the last thing you want to reach for.
Edit: Also, none of the major frameworks, and very few of the new frameworks target web components for many reason fully ignored by browser vendors. They can "consume" them (that is embed them in code), but at most compile to web components, reluctantly. And still provide components and SSR, and have for years.
Not likely
> Each individual external service will easily have tens of conditions
You will likely not propagate those to the end user, but log and return a single error for many of those cases
> A common misconception, but no.
A common misconception is that tests are documentation in any shape or form.
> Tests would serve no purpose if you had no reason to document expected behaviour.
You do not document behaviour with tests. You write the tests to make sure your app conforms to documented behaviour.
As documentation tests are useless because they are a collection of separate and disparate scenarios and cases lacking any context or continuity. If anyone ends up looking at tests for documentation on how your app or service behaves, I have bad news for you.
> Your documentation doesn't end there
Thts is literally the dead end of documentation. Well, the actual dead end is "code is documentation" and "types are documentation". Neither of them are. Documentation is documentation. Comments are documntation. Design docs and specs are documentation.
Tests, and especially the way most practices propose tests should be written, could not be farther from documentation.
> The invented practices you have presented throughout the discussion no doubt lead to writing useless tests.
Indeed they do.
> It is, however, not clear why you hang on this invention of yours – outright ignoring what you are being given.
So you have fabricated this idea that I am ignoring something and is now attempting to make me defend this fabrication of yours.
Definitely not hundreds. But yes, they need to be tested
> The successful case is usually the most understood behaviour, most visible, and easiest to recreate.
Tests are not written to document behaviour, but to validate that your program does what it's supposed to do. If you don't test successful cases, you don't even know if it runs correctly.
> If you are going to skimp out on documenting some aspects of your code because you hate future developers, the most understood aspect is where you are best to skimp.
I see you have the erroneous assumption that tests are documentation.
> It is certainly backed up every time I have worked with developers who put no effort into making their code testable, making it way harder than it should be to test certain cases afterwards.
This is slightly orthogonal to being able to write testable code etc. Most tests are trash to begin with, and most testing frameworks give next to zero help in designing and running actual tests you would really want.
I couldn't care less if a team mate wrote "untestable code" in some modules. In 99% of the time that code is some repetitive boilerplate anyway. Ironically, this is the code that everyone prioritises to make testable.
And then you want to test all that in concert... Ahahaha good luck. Even starting up a local rest service with mocked dependencies to test is a royal pain in the butt in most cases, and has nothing to do with testability of some small pieces of code.
> that's what TDD – and, really, testing in general – is all about: Documentation.
Tests are not documentation, have never been, and can never be viewed as such.
Testing is literally about testing: to test that your program behaves correctly given some requirements. It literally is in the name. You write tests not to educate your co-workers, but to make sure your program doesn't crash and burn the moment you push it to prod.
> Nobody advocates writing useless tests. Future readers should be able to learn something useful from every documentation item you write.
Again:
1. Tests are not documentation. Have never been, will never be.
2. Existing testing practices all but enforce writing useless tests, prioritising duplication, hundreds of unit tests etc. over what' actually needed.
> Nobody wants to read documentation that is one big ball of mud.
All tests are inevitably a ball of mud because they lack context, and they are not documentation.
The expected "attribute" is correct data being returned.
> Hell, you can likely not even bother testing the so-called "happy path" because, really, who cares what happens during success?
wat?
> If it's a REST endpoint that aggregates data from multiple external services, you probably want to see a "retry after" response sent to the client if any of those external services are temporarily unavailable. So write a test that asserts that, then write code that does it.
So again you want me to write a meaningless test that will be duplicated anyway during the actual proper test. See https://news.ycombinator.com/item?id=34765360
> However, in reality most people simply don't have the wherewithal to plan for things like being able to test unavailable remote services if they don't have a test case in front of them forcing them
This is a weird statement that is definitely not backed up by reality.
> there is something to be said about the TDD approach as a general rule, deviating only after you fully understand the tradeoffs.
The problem is, everyone advocates writing multiple useless tests, including TDD proponents. You can't learn "tradeoffs" until you look past the dogma. Once you've looked past the dogma these "tradeoffs" most of them are not tradeoffs, but trivial things that you would do anyway.
Functional requirements describe observable behaviour. You can't write any meaningful tests for that behaviour until a lot of your code is written.
Yet somehow in all the discussions there's this unexplaned leap from "you have the requirements" -> "well you just write a unit test for your function first, and then code it".
My functional requirements come in the form of "Given publisher A in Country B and contract requirements C the service must return D for a subset of products E", for multiple combinations of A, B, C, D, and E. And where each of those may and will require lookups in external services and databases.
No. I usually write functional/integration tests after I've written most of the code.
> TDD promotes that you start with just one.
And that one will be absolutely entirely useless. Because what would be that "first one test"?
Let's assume it's a REST or GraphQL service that returns aggregated data from multiple external services. Until you have more-or-less functioning code (including all model definitions, client definitions, data transforms etc.) you can't even write a "first test for observable behaviour". Also here: https://news.ycombinator.com/item?id=34765360
Most of the stuff we do is trivial [1]. Unfortunately no one really teaches testing or shows what needs ot be tested. Hence the prevalent "write hundreds of tests perhaps some of them will actually be useful". And most available examples, and most available advice is that: write many many useless tests.
I have a perfect example from the Java + Spring world. It's common to have a Controller + Service + Facade + external service client definition.
So I've seen countless times when tests are written as follows:
- external service client is mocked, multiple unit tests for the Facade to make sure it returns data
- Facade is mocked, multiple unit tests for Service, to make sure data is returned
- Service is mocked, mutiple unit tests for Controller, to make sure ata is returned
They are all the same tests, and can be easily deleted and replaced by a single suite of:
- external service is mocked, including invalid responses and timeouts. The actual rest service provided by the app is tested for all the scenarious that were quadruplicated in the unit tests above
You don't need to be a "kent Beck level expert" to do that. However, almost literally nothing teaches you to do that or helps you write those tests. Almost literally everything is hardwired to write small useless unit tests.
[1] Except UIs. I have no idea how to test UIs, and I don't think anyone does :D
That's a very bad attitude that is all but enforced by TDD proponents.
It's very easy to see which tests are useless and which are not. So you end up with people writing thousands of unit tests and little-to-no integration or functional tests because:
- "TDD told me so", and
- Testing frameworks are written by people who adhere to the same philosophy
Whereas there's very little utility in those "too many tests" while they give you a very false sense of security.
My requirements are in terms of observable program behaviour, and that is what needs testing. Not the hindreds/thousands of tiny one-off tests in between. And... you can't test that observable behaviour with TDD until you've written a solid chunk in between.
Until last year the spec for dialog was in such a state that Chrome (the only ones implementing it) argued that it should be removed.
IIRC literally none of the issues were fixed but suddenly it got shipped in all browsers.
No you don't. Apple routinely files hundreds of patents (any major company does that). It doesn't mean those patents will end up as a shippable product.
All you know is the never ending rumor mill.
> these devices are already real and shipped.
Of course they are not
> As for batteries, that’s been solved 1-2 years ago.
Of course they haven't. There's literally no battery + cpu + gpu tech that you can put in an AR device lightweight enough for extended use.
All "lightweight" ones use a cable to connect to an external device.
The rest are bulky and heavy. Because you cannot bullshit your way out of physics and biology by pretending "this has been solved".
> I don’t understand why you keep doubling down on a subject that you know nothing about.
There's objective reality and there's wishful thinking
They don't, not really. See this thread by former Mozilla exec on how Google sabotaged Firefox: https://twitter.com/johnath/status/1116871238922776576
Don't forget that even here on HN devs will bemoan the lack of Chrome-only non-standards in other browsers and say those browsers "hold the web back".
Microsoft didn't have search monopoly, mail monopoly, video hosting monopoly and an army of loyal devs who just love every non-standard feature thrown over the wall.
Youtube alone helped kill IE 6: https://www.androidpolice.com/2019/05/02/the-story-of-how-a-...
I'm not wrong. I just don't call wishful thinking "the future", "reality" etc.
> Let’s also not be disingenuous. those “fantasy interfaces” are working prototypes and not just movie CGI
Prototypes are not "actual usable interfaces that are used by real humans for any extended periods of time". Note how his own company uses none of these interfaces.
> There are also real world products like NReal
Ah yes. A pair of galsses with 46 degree field of view that you need to connect with a cable to the actual device where all the processing and control happens.
> what Quest headsets and the new Apple headset will support
Ah yes. The new Apple headset that you know literally nothing about will one hundred percent will have this... Even though it's rumoured not to be VR device
> Bulky headsets are the past and present. That isn’t the future, or even the near future
Oh? We've solved the question of batteries? Of compact CPUs and GPUs capable of processing this? Etc. And all this is coming in near future?