I couldn’t really make head or tail of it and I’m still not sure, but Google’s announcement linked to the list of incident reports that they said were being mishandled, and I picked out this one at random, and I have to say it definitely seems like they kind of have a point. Certificates were being signed with SHA-1 for about 2 years, as far as I can tell, and most of Entrust’s responses over several months of people asking them “how are you taking steps to endeavor that things like this aren’t still happening or will not happen again” was basically, thank you for concern but fuck off stop bothering me.
The first report I looked at was Entrust refusing to revoke certs because their clients' manual processes would make applying reissued certificates inconvenient.
Quite fun reading, surprisingly - a mid thread revelation that they'd pulled the exact same shit 4 years ago, an attempt by Entrust to kill the issue because unattributed legal advice said they'd misreported the error. And then, just when their chutzpah seemed to be wearing everyone down, a good 'fuck you' from Apple forced them to revoke the certs after all.
I'm not surprised Google had enough & yanked their license to print money.
Seriously. Surely making certificates is one of the absolute apexes of the ratio of how much money you can make versus how much actual work you have to do; in what world did they manage to be sufficiently massive cockheads as to screw that ticket up?
Most of that only applies if you're running your website as a public-facing entity, i.e. open to the general public to browse/use or if you're running it as part of a business.
If it's a non-commercial, private-use site you don't need any of those "requirements".
1996 was the beginning of the chaos. We went from a document that the user's browser parsed and styled to a free-for-all of website designs glued together on construction paper. Accessibility took a step back. You now needed a graphical desktop to view the web. Page content was no longer machine readable and became less portable. Now in a world of dynamic page content generated by javascript you need a v8 browser in crawlers just to index page content.
A lot of comments seem to think that Tailwind is just a way to save a few keystrokes at the expense of legibility and leanness.
For me, the value comes from not having to jump all over a codebase, not having to name so many things, having clearer scopes and pulling things like colors and spacings from a central config.
I know there's a hundred different ways to solve those issues that wouldn't offend CSS purists but ask 10 different people and you'll get 10 different answers with 10 different caveats.
So I use Tailwind to write fuckugly markup in a faster, easily iterated way that will be instantly familiar to anyone who knows Tailwind.
XHR is absolutely ancient. Like, I used it on Internet Explorer 6 era websites. Using a 3x3 table with images in all 8 outer cells to make rounded corners.
It still works but is so old it can't really be updated. It's entirely callback driven so no async. It's not even async by default if I recall correctly, it just hangs the browser.
The Fetch API was designed to modernize what XHR does, and does so well. Now, a simple get request you can pretty much await fetch(...) whereas the XHR one is probably 20-40 lines of code and most people end up using a library to deal with it, or write their own little wrapper for it. It supports promises natively.You can stream very large files without loading it all in memory. There's nothing XHR can do that fetch can't do, and usually does it better too. For most use cases the performance will be the same, network IO is orders of magnitude slower than JavaScript execution. But the API being better probably does lead to better performance by not doing unnecessary things and possibly processing data as it arrives instead of all in one go when the download is finished.
It's a modern replacement because it's literally what it was designed to be. Try both and it'll be abundantly clear why.
The article is very interesting but the fake cursors are infuriating and make it nearly impossible to focus on the content. It's a clever joke but without a way to disable it, the author is just sabotaging his own content.
How does one make this edit permanent? I've been looking to delete the sidebar on fandom, but an adblocker like uBO is not enough, since I need to edit the backgrounds margin. I don't know anything about webdev, and would be grateful for help.
Well, making such a change permanent on a foreign webpage, that's not really something you do in webdev, but I happen to know anyways.
What you want is usually referred to as a "user style" and you can achieve that with e.g. the Stylus extension.
You can create a new style and then paste this into it:
Ah, absolutely no toes stepped on. I've never used Fandom myself, this was just what I could whip up real quick.
If you happen to use Fandom more often, maybe you'd like to publish this in Stylus? Even if it's just as a personal backup.
I mainly didn't do it, because without me using Fandom, the user style could be broken by tomorrow.
P.S.: I think, the first body > .main-container {-block can be removed, as you set the same style in the nested block underneath...
I will never have a bleeding heart for people who chose to surround themselves in products from that terrible company. They've done anti consumer dealings for decades and have lead the way to other similar companies to follow suit with little to no pushback because of it. Jobs was a terrible human. Tim's no different.
Incremental builds are much faster as it often only need to rebuild the specific part that changed. Just re-running the build in VSCode won't help you if the build takes like 5 minutes, but still instant with watch mode.
Hot reload also has some advantages such as not having to reload the page and lose state: it can just update the CSS live so you can quickly iterate on your styles even if you're deep into the navigation at page 10 of a modal window.
We don't need live reload/watch, but it sure is convenient.
Why could a build take 5 minutes? Is it due to the size of your project or the language the bundler is written in (JavaScript being a slower option over Rust)?
The scale of things. Large projects take longer to compile and bundle because they're made out of thousands of files and hundreds of thousands of lines of code.
Yeah, your hello program will go just as fast without a bundler, or a simple bundler. It's when you go big, and use tons of libraries and stuff that it slows down and the advantages become clearer.
That's especially true when using big libraries like React and dozens of plugins for it, frameworks like Next.js, SASS for CSS or CSS in JS, all the JSX, all the TypeScript. It adds up especially if Babel is also involved to transpile for older browser support.
5 minutes is a bit of an extreme use case, but the point is after the first build, live reload would still refresh your code at the same speed. So working on one page you don't need to constantly rebuild the other hundreds of them, just the one you changed. If you target mobile platforms with Cordova or React Native then you also add a whole Android/iOS build + install + restart of the app. The same live reload would work even in that context, making the speed advantage even more apparent.
These things are designed for large enterprise projects, not for your small helloworld sized hobbyist programs.
Depends entirely on the bundler. They all have a watch mode, not all of them do hot reload. Hot reload is cool but full of gotchas, it's a hack but worst case you reload the page anyway. Some probably cache on disk, I think webpack can.
But if you think about it, you either want a clean build for production, or rebuild quickly during development. Watch mode does exactly what you'd do anyway, re-run a build. And IDEs can watch its output to give you error messages.
It's much easier to implement: just emit the code again when the file changes, and let it go through the pipeline. It's already there in memory all figured out, no need to figure a serialization format to put on disk to load back up.
But to circle back to the original question of why use watch mode when you can just rebuild it when saving a file: you're reinventing the wheel, and watch mode scales better and will always be faster. Yes, some people need watch mode.
I expected this to be about consequences of enshittification, where interfaces and design have been run the fuck over by a constant mindless demand to feed Engagemagog. Hard to justify elegant design or retain worthwhile front-end developers when you're just telling them to shovel popups and flyovers into victims' eyeballs.
Instead it's a CSS guy blithely complaining about CSS's reputation.
I notice CSS is widely considered some or all of the following: unmaintainable; subjective; messy; unruly; unpredictable; a footgun; overly complicated; unscalable; and a nightmare.
Well yes, but have you seen how people describe Javascript?
But despite all these claims, CSS is also somehow “not a real programming language.”
It literally isn't. "Same with HTML." Markup is not programming, even if it is code. If it's Turing-complete then that's probably a bug. If you want to get clever with a twee definition based on how a programme is just an agenda for the machine, we have a word for that kind of not-an-excutable table-of-contents coding: it's called markup.
It’s like CSS exists in some bizarre quantum state; somehow both too complex to use, yet too simple to take seriously, all at once.
Being a pain in the ass is not a contradiction.
(Really; you’d probably be astounded how many ways there are to utterly destroy anything on the web with hardly any CSS.)
... why would people be surprised by that, given CSS's reputation? Everyone's dorked with F12 and gone 'now why's it done that?' thanks to instant visual feedback. Hence the reputation.
We might not ever say it, or even think it, but when we cast some people as heroes, we relegate others to the role of the sidekick—even though their labor is no less important, and they do at least as much to push the work toward success.
Your job is literally optional. Sites without CSS are not pretty, but pretty is a want, not a need. The people who make the content of the website are usually capable of half-assing a modicum of presentation... writers moreso than programmers, because engineer art is very not good. We'll figure out that spinner while the video loads, but it'll be purple and orange. If we didn't, though - the video still loads. The blog is still in English. The shopping cart still appears, even if the table is 4000px wide with ridge borders straight out of Netscape.
The idea that other engineers are smart—even smarter than we are—is the kind of stereotype that feels so common and true it’s rarely even questioned.
Now - essentialism is even worse than the author makes out here. Judging a person based on the relative importance of their work is close to bigotry. You don't have to be smart to do Javascript instead of CSS. (Arguably that choice says the opposite.) But we are still comparing the part of the site that does all the stuff, and making that part look nice.
“Here; other people already made this.” (i.e., they already did the real work.) “Now we just need you to fix it up.”
I wish technical debt only happened to markup people.
I'm a scientist, and "Not a real programming language" gives me big vibes of arguing that a thing is a science (usually economics) because they're using "is a science" as a proxy when they actually mean to say that their field is important and valuable.
I've dabbled enough with CSS that I know how much I don't know, and I don't think respect for a skillset is (or should be) measured by whether a thing is a "real programming language"
You cannot write a program in CSS. It is not a programming language.
Look:
Computer science precisely classifies things that are almost computers.
There's a hierarchy that has nothing to do with clout. It's a genuine field of study. It's even one of the freaky ones where the landmark name isn't a computer scientist, but Noam yes-that-one Chomsky. The linguist.
We say a type of machine recognizes a language. Famously, "you can't parse HTML with regexes," because regular expressions are a specific grammar that does not allow self-reference. Added regex features like lookahead only extend it into context-sensitive grammar.
I'm pretty sure HTML is even less than that. This comment sent me sixteen Wikipedia tabs deep to double-check, and I started drinking around number eight. But I feel confident saying you also could not parse a regex, with HTML. Even the delightful wackaloons who get Powerpower to act Turing-complete could only half-ass it out of HTML by including CSS and a human hitting tab-space-tab-space.
It's not a value judgement, when we say CSS and HTML are not programming languages. And we're not just being pedantic toward you. Again: have you seen what we say about Javascript? This is how we are.
I’m a scientist, and “Not a real programming language” gives me big vibes of arguing that a thing is a science
CSS is not a programming language. Neither is HTML.
This, however does not take away from its importance or the skillsets and expertise required to use it effectively.
What a weird belief: thinking the value they bring to a project is tied to whether they use programming languages or not. The majority of people working with programming languages are already bad at it. Why is it being used as a badge of honor?
Yeah, it's definitely a very unique approach I haven't seen before. I've been using the "honeypot" method for years, which has been working surprisingly well.
Apparently the rate of users not using JS is about 0.2% (and has been that way for 10 years), so just applying this solution the the large margins as he’s doing, I’d probably just make an alternate message saying “please enable javascript to contact me” and let that be that.
Eh. These sorts of metrics aren't always accurate. And the source company did the study in 2016, which was a very very different internet, and doesn't go into detail about how they were able to determine this number. I would take that with a grain of salt. I agree that just having a notice somewhere is better than not, though.
Sure, I was just curious and looked it up, that’s the first link I saw. I guess the question is — is it better to theoretically annoy real users who aren’t using JS (and how many are there) or is it better to frustrate and annoy lazy spammers (and how many are there?). On my own sites I really rarely get non-spam email. I’d be fine making a random 10-45 second timer on my contact forms doing this, no one needs to contact me in under 10 seconds on my websites.
Web Development
Top