Eh… it depends on what you think is good and bad. It’s not clear to me that surveillance capitalism will be a long term good. Gadgets and social media are fun, but digital feudalism will be (is?) a lot less fun and rewarding.
No, it doesn't. The case here is "buy a consumer device, get consumer results". If you were to expect different results, that doesn't mean that the world is wrong, it means that you bought something you didn't want.
I like decorators as a concept... but there have been a couple different implementations now... the TypeScript version is probably the most broadly used, but there were others before it via Babel (formerly 6to5).
I was an early adopter of the original decorators proposal as well as the F#-style pipeline operators. The more time has moved on and other bits made it into JS proper, I'm far more inclined to stick to what's "in the box"... Have even considered just writing straight JS + ESM (modules). Of course, I also like JSX, though not sure of any proposals of how to get that "in the box" as e4x died on the vine and a lot of other efforts didn't gain much traction either.
> All the tools require me to do so much bullshit to get them to even compile. I shouldn't need to compile JavaScript to JavaScript in order to deploy stuff to a webpage.
I've never understood why this is deemed such a big ask by so many people. You can either compile JS-to-JS or have your JS break when it encounters an old browser (which is exceedingly rare, these days, so you don't really need to compile JS-to-JS. Most of the "bullshit" [aka tooling] these days bundles and optimizes your JS).
Many languages have compilers that you need to run. Before running a Java program, you need to compile it. And compiling things with `javac` is hardly simple. You need to populate your classpath, configure all kinds of stuff. It's not trivial. So why is it such a big deal when you need to do the same thing when making a webapp?
To make meaningful, portable applications in JS, you need to use a compiler. That's both due to the varying runtimes your code will encounter, and due to the fact that your application consists of many files that benefit from being compiled together by tooling versus by you, by hand. Configuring such a compiler (webpack, parcel, rollup, etc) can be of varying levels of complexity. Next.js makes starting a webapp trivial. It's what create-react-app should be.
Yeah, if you want to just make an HTML, that's fine, you can just roll some JS and it'll probably work in most browsers. But if you're making an application, then it makes sense to start using some tooling. When has this not been the case in web development? Even before client-side apps really took off, getting your server-driven HTML-emitting application going was hardly simple.
> I've never understood why this is deemed such a big ask by so many people.
It's the “Script” bit of “JavaScript”. Once your scripting language needs compiling, it's jumped the shark. You need to go back to the drawing board and invent something else. “I don't want to compile JavaScript” is the face of it, yes, but at its core, this sentiment rails against the entire bloated, over-developed, under-engineered state of contemporary JavaScript.
Ironically this is the kind of thing that ES6 modules actually solves. It's even better if your tool is internal-facing only so that you don't have to bother with the release time older browser compatibility thing.
ES6 modules are just brilliant, it's like a breath of fresh air in JavaScript development. Your browser sees exactly the same thing as you write, which is such a great simplification. And yeah, you can still bundle/minify for production...
This is amazing. Not to be overly cynical, but I suspect this must be related to the global labor shortage. They must be happy to let people do their own labor whenever possible now, if the difference is providing bad service vs letting people get good service elsewhere or at home.
Either way, this appears to be great. Looking forward to seeing how this plays out!
Much more likely it’s related to increased antitrust and regulatory pressures. Vanishingly few customers likely to take advantage of this, its true value is in the PR.
A lot repair shops have been using screen and replacement part sourced randomly for common repairs.
You’ll see one in every shopping mall, and while franchised ones won’t be much affected, smaller shop should benefit from from wider access to parts (no need to get accepted as a repair shop for instance)
And getting in front of it means they get to dictate the pricing structure - you can bet your spare parts will be beautifully packaged and sold at a decent markup.
Instead of being constructive and contributing positively to humanity, ddevault takes his talents and attempts to play scorched earth at every turn in the road.
There are constructive solutions to this problem. The solutions do not entail breaking literally millions of builds and suggesting that a developer should torch their reputation for, what, $710 (LOL, give me a break, Drew).
What we have here is performative attention-seeking, known clinically as "maladaptive coping." It's a shame to see this stuff day after day voted up to the HN homepage.
If a million builds can break for $700, maybe those builds deserve to break. Then the million developers might actually write resilient software. Where do I send my $700??
How does this fall under the definition of satire?
“the use of humor, irony, exaggeration, or ridicule to expose and criticize people's stupidity or vices, particularly in the context of contemporary politics and other topical issues.”
This is great, especially since the none checkbox can probably be added with minimal overhead on the frontend and no changes to the backend. Great research and post. Would have never occurred to me but makes total sense.
It would still be a good idea to have backend check for this.
- If javascript breaks, (or get blocked by extensions) there should be a check for contradictory answers.
- If on future iterations on the UI (more often than backend) logic breaks, backend help improve how to debug the UI update
People can't handle change. It's pretty sad. I'm not saying we need change, or that FF should be investing in changing the UI (I really think the colorways are just a terrible use of resources), but I think all the UI updates these past few years—regardless of why they were made, for good or for senseless reasons—are fine if not highly enjoyable.
It’s crazy. My guess is they’re trying to tap into the FOMO vibe du jour with all the NFT insanity (“drops” for example) but they don’t even know or understand their own userbase. It’s really, really weird and unsettling.
SourceHut and its founder are the promulgators or a never ended stream of strong opinions and principled edicts that do little but alienate people. Drew’s solution to every problem is blocking and blackholing [0] which makes him seem weak and petty and suggests that by refusing to work constructively with people he’s mostly interested in strongarming and asserting dominance. I find it pretty hard to take him seriously and run from anything he’s associated with, even when I agree. There’s this concept called “non-violent communication” that he would be well-served to explore.
Non-violent communication works if you're talking to an individual as an equal but corporations cannot empathise or be empathised with. It's madness to try.
The open source developer of amfora is about as far as you can get from a corporation, though. And behind every cloudflare reverse proxy connection is a human. Blocking them for nothing other than their choice of Internet route stands antithetical to the foundational spirit of the net, which he is ostensibly trying to protect.
