DEV Community: Voltra

"Back-end as a Front-end" or How admin dashboards can drive your apps

Voltra — Wed, 20 Dec 2023 11:31:28 +0000

A discovery

I was writing a playlist manager app. I had an API server setup, my database setup, and I was working on making a front-end client for it.

One source of my frustration was the back-and-forth I had to do with the API, the synchronization primitives that would be needed to make it a proper distributed system, and how complicated orchestrating everything could be.

And then I remembered a piece of tech I stumbled upon a few months prior: Laravel Filament.

What is Laravel Filament

Filament is a free admin dashboard (called panel in v3) toolkit/framework that sits on top of Laravel. You define your Laravel app as usual, and you have lots of tools to help build your back-office, including "auto"-generation of forms and tables.

"Back-end as a Front-end" isn't limited to Filament, and this post isn't about Filament. It's just that I was using Laravel for my API, so I gave it a try.

What is "Back-end as a Front-end"

An architectural design pattern. It can also be named "back-office as a front-office".

It's the idea that your user's space blends in with your admin's space. That the app is nothing more than the admin dashboard itself.

It's the idea that you might not need a front-end beside the admin dashboard. It's the idea that sometimes, a separate front-end is just redundant.

One pattern that emerges really quickly when you have this in mind: web apps can be built entirely relying on this principle.

Why have a decoupled admin panel and user app when you can just have everything be in one place and managed in the same way?

What is this architectural pattern good at?

It's really good at tying together every part of your application in one place: the back-end.

Your user flow is extremely similar to your admin flow? Use this pattern.

You need job queues? Easy. You need de-duplication? Easy. You need locks? Easy.

You don't even have an API lying around: your area of attack has been reduced.

What can't this pattern do?

Replace all the need for a separate front-end. Not everything can be architectured this way.

Most SaaS can, but most client-facing apps cannot. Blogs, social media apps, etc. they cannot benefit from it.

Admin panels are not the sexiest, most user-friendly and most usable pieces of software in the universe. They have one job, and they usually do it well: administering content.

My first major contribution: More rxjs in vue-use

Voltra — Sat, 28 Oct 2023 16:31:41 +0000

Let me tell you the story of my first (actually relevant) major contribution to an Open Source project: adding more rxjs in vue-use.

My approach to Computer Science

I chose Computer Science because I like writing code, and I like solving problems. My approach to open source and Computer Science as a whole is the following:

Solve a problem, don't create a problem just to solve it

My problem

I was rewriting my music player and had to migrate the existing code from Vue 2 to Vue 3. I also had to, you know, actually finish the damn thing this time.

One thing I like to do when using Vue (or any other framework) is to completely decouple the business logic from the "application logic". I also like to completely decouple the "framework logic" from the business logic.

As such, I had written an AudioPlayer class. Trying to integrate the pieces together, I noticed something: I need an HTMLAudioElement to construct my AudioPlayer, but I can only ever get Ref<HTMLAudioElement|null> if I don't want to use directives.

That problem was easy enough to solve: make a computed property and wrap it nicely into a ReadonlyRef<AudioPlayer|null>.

Then the real issue came up: useObservable only accepts Observable<T> as input. I have a ReadonlyRef<AudioPlayer|null> which can give me a ReadonlyRef<Observable<T>>. I can't make that work with the existing composition functions, but I desperately want to!

So what did I do? I rolled my own!

What's new?

Introducing useExtractedObservable and watchExtractedObservable.

What do they do?

Precisely solve one problem (in two similar yet distinct ways): The lack of interoperability between Vue's composables and RxJS's observables.

How it went

I had wrote a first draft of them for myself, and thought:

If I have that problem, others will.

And thus I forked vue-use, looked at the implementation of useObservable and watch, and adapted them to make the new composables.

useExtractedObservable

Is a fancier version of useObservable that, as the name suggests, extracts the observable from something else (aka watch sources).

You map your extracted data into an observable, and turn that observable as a ref (well, technically really a shallowRef for performance reasons).

import { ref } from 'vue'
import { useExtractedObservable } from '@vueuse/rxjs'
import { interval } from 'rxjs'
import { mapTo, scan, startWith, takeWhile } from 'rxjs/operators'
// setup()
const start = ref<number>()
const count = useExtractedObservable(
  start,
  (start) => {
    return interval(1000).pipe(
      mapTo(1),
      startWith(start),
      scan((total, next) => next + total),
      takeWhile((num) => num < 10),
    )
  },
  {},
  {
    immediate: false,
  },
)

watchExtractedObservable

Is the love child of watch and useExtractedObservable. Instead of getting the new values in a ref, you instead get to react to them via a callback.

import { computed, ref } from 'vue'
import { watchExtractedObservable } from '@vueuse/rxjs'
import { AudioPlayer } from '../my/libs/AudioPlayer'
// setup()
const audio = ref<HTMLAudioElement>()
const player = computed(() => (audio.value ? new AudioPlayer(audio) : null))
const state = reactive({
  progress: 0,
})
watchExtractedObservable(
  player,
  (p) => p.progress$,
  (percentage) => {
    state.progress = percentage * 100
  },
)

cpp-as-is: A taste of the future of genericity, in the past

Voltra — Sun, 10 Sep 2023 14:02:08 +0000

At CppCon 2021, Herb Sutter gave a talk about potential pattern matching in the C++ standard.

One point in particular held my attention: there are many ways to extract or cast values in C++, but that makes it more difficult to write generic code (e.g. a single templated function).

He talked about the P2392 proposal that introduces two new operators: is and as. These features are currently implemented only in Circle.

cpp-as-is (WIP) is a small library that aims to provide these features today (as long as you have C++17 support).

The idea came to me from both re-watching that talk, but also deeply thinking about how I could port to C++ the conversion utilities of Rust and how it has both std::convert::From and std::convert::Into traits when it really only needs std::convert::Into.

One of my favorite "feature" of C++ is how you can basically use the language to introduce new features and "extend the language", without having to change the language (think Michael Park's patterns library).

This library sort of follows that principle. The basic idea is to be able to write the following:

#include <any>
#include <iostream>
#include <optional>
#include <string>
#include <variant>
#include <cpp_as_is/cpp_as_is.hpp>

using namespace cpp_as_is;

template <class T>
void inspect_underlying_int(const T& obj) {
  if (is<int>(obj)) {
    std::cout << as<int>(obj) << '\n';
  } else {
    std::cout << "<nothing>\n";
  }
}

int main() {
  inspect_underlying_int(std::any{42});

  std::optional<int> opt;
  inspect_underlying_int(opt);

  std::variant<std::string, int, float> v{23};
  inspect_underlying_int(v);

  const std::optional<int> opt2{420};
  inspect_underlying_int(opt2);
}

/*
Output is:

42
<nothing>
23
420
*/

Without is and as you have to write quite a few overloads if you want your one function to handle all cases properly. And the worst part is that you have to do it all over again with every single function.

Here, you just use two extension points and you're good to go with using is and as:

namespace cpp_as_is::ext {
  template <class From, class To> struct is_conversion_traits {
    using arg_type = /*From*/;

    /*constexpr*/ static inline bool matches(/*arg_type*/) noexcept;
  };

  template <class From, class To> struct as_conversion_traits {
    using arg_type = /*From*/;
    using return_type = /*To*/;

    /*constexpr*/ static inline /*return_type*/ convert(/*arg_type*/) noexcept;
  };
}

You also have concepts constraints on is and as to make them easier to use and have better error messages:

namespace cpp_as_is::ext {
  template <class From, class To> concept InspectableWithIs;
  template <class From, class To> concept IsConvertibleWithAs;
}

Here's a list of supported conversions (as of now):

T -> T
T* -> T
std::shared_ptr<T> -> T
std::unique_ptr<T> -> T
std::variant<V1..., T, V2...> -> T (and boost alternatives)
std::any -> T (and boost alternatives)
std::expected<T, E> -> T (and boost alternatives)
std::expected<T, E> -> std::unexpected<E> (and boost alternatives)
std::optional<T> (and boost alternatives)
std::future<T> -> T (and experimental, and boost alternatives)

IP Info was a mistake, and how digging for the source of the problem is tricky

Voltra — Mon, 04 Sep 2023 10:03:50 +0000

IP Info is the list of information that is publicly available from just having your IP Address (whether that be IPv4 or IPv6).

Some businesses even use that as their source of income (which I'm pretty sure is illegal).

So what can you get from an IP Address? Well just about any of the following:

Hostname
City
Potentially inaccurate zipcode
Region/State
Country code
(I hope inaccurate) latitude and longitude
Timezone
ASN info
Internet Service Provider info
Security info (such as whether you're using a VPN, Tor, a proxy, a relay, or if you're hosting a server)
Abuse contact info

If you ask me, none of that should be available. Or at the very least, not freely available to literally anyone.

The question that naturally comes to mind is: Why the hell is this even available in the first place?

Well, it's a bit complicated. The RFC 791: IP Protocol doesn't mention any of it. Neither does RFC 997: Internet Numbers, nor RFC 1519: CIDR, nor RFC 1531: DCHP, nor RFC 903: RARP, nor RFC 2460: IPv6.

Clearly, it's absolutely not needed for the Internet Protocol (and related stuff) to be functional.

So what's going on?

I found RFC 8805: A format for self-published geo-location feeds which explains that at least Google (sigh... not again) accepts such a format. Thus IP prefixes can have geolocation baked in those lists. But that's from 2020.

There was an abandoned RFC 1876: Location within DNS that the Investigating the Imprecision of IP Block-Based Geolocation research paper cites, and tells you that alternatives "had" to be used. So it's not in there.

What's the need?

The "need", at least as expressed in RFC 8805, is to be able to better serve content to end users. I mean sure, but that only requires one or max two pieces of info: the country and the region/state. Why the hell is the rest available? Why is it freely and openly available!?

A glimpse at the source?

Turns out that the research paper cited above has one interesting reference: An investigation of geographic mapping techniques for internet hosts.

This 2001 paper doesn't talk about how things have been done, but how things could be done. And once again, it's a case of scientists asking themselves whether they could, before asking themselves whether they should.

You think this is bad? Well I'll give you this treat for you to check out on your free time. The only thing I'll tell you is that it's from 2023...

What did we learn?

The Internet Protocol has been plagued by a lack of security that even IPSec cannot help and fix. Scientists have been very eager to help anyone get more and more information about you from simply an IP Address. Why? I guess we'll never know (spoiler: it's greed or scientific stupidity).

A simple number, used to help in information exchange, now allows people to passively get information about you. A 32 bit number, now gives you access to bytes upon bytes of data on someone.

That there is a lot of unnecessary endangerment, that should have been trivially avoided. Could there be a legal case to be made? I'd like for that to be true. If even scientists are eager to give out your privacy for free, only that could potentially fix the issue (along with making it "more" illegal I guess).

My recommendations?

Never share your IP Address (duh)
Never (accidentally) expose your IP Address (e.g. using any kind of P2P or direct connections)
Use any masking tool at your disposal (e.g. VPN, Proxy, etc...)
Tell your friends, family, etc.

Phone number centric apps are a Security Hazard

Voltra — Mon, 04 Sep 2023 09:06:18 +0000

Let's not beat around the bush, using phone numbers as part of the required information for a user simply tells to the world "Look! I make terrible choices when designing software".

Most of the apps that use them as the primary login/info will also have the tendency of making it visible for the world to see (cc. WhatsApp).

You also have a username on these apps? They don't care, they'll usually show your phone number before they show your username, or show them side-by-side for... reasons?

Most of the time, if they have a desktop client, you can even extract a list of phone numbers from a group fairly easily.

This is an obvious security hazard as, more often than not, the default visibility is "for everyone" instead of "my contacts" which is a baffling choice to say the least.

Exposing your phone number, just like your IP address, can have... unintended side-effects (we'll dive more on that in a future post).

Thus far the issues we have listed are:

Getting your phone number
Accessing information they probably shouldn't have

Hackers can even use your phone number as a means for reverse-lookups. Hell, even regular users can since most apps have a "add from my contacts" feature (which is extremely bad for security).

The other funny thing is... unlike email addresses, phone numbers can usually be re-assigned! Only after your death or any phone number change, sure, but it can still happen.

Therefore anything that uses phone numbers for let's say 2FA has a fundamental design flaw: too many assumptions.

Does it prevent spam? Nope. Does it make sure no one can have multiple accounts? Nope. Does it make sure only the owner has access to their account? Not necessarily.

There is no reason that justifies the use of a phone number beyond sending a verification code. It should never be used as a primary means for identification, authentication or authorization. It should only be used as a secondary one.

Re-imagining Async/Await polyfills

Voltra — Tue, 22 Aug 2023 12:24:11 +0000

One thing I've always been curious about is: why use generators to polyfill async/await?

Sure I can see how that can be convenient, taking into account how they work in JavaScript, but why use that approach when there's much better alternatives?

The solution: Just write promises

It's as simple as it can get. Async/await are syntactic sugar for promise chains, so why not just translate them to literally that: promise chains.

Keep track of the results in a state object, that way you have access to them even in future continuation function.

The only drawback is that you do not get variable shadowing, you get variable overriding. But that could be solved trivially by using a stack-like data structure with push'n'pop mechanisms.

Examples

Let me demonstrate my proposed alternative to things like regenerator-runtime:

Simple linear transformation

async function fetchJson(url) {
  const response = await fetch(url);
  if (!response.ok) {
    throw new Error("KO");
  }

  return response.json();
}

Transforming it should give us:

function fetchJson(url) {
  return fetch(url).then(response => {
    if (!response.ok) {
       throw new Error("KO");
    }

    return response.json();
  });
}

It's pretty much a line-by-line conversion to a simple promise-based solution.

If we want to make the transformation uniform, then it could give us:

function fetchJson(url) {
  const state = {};
  return fetch(url).then(response => {
    state.response = response;

    if (!response.ok) {
       throw new Error("KO");
    }

    return response.json();
  });
}

In need of previous results

async function stuff(input) {
  const response = await api.put(input);
  const extractedData = await extractData(response);
  return {
    response,
    data: extractedData,
  };
}

This should become:

function stuff(input) {
  const state = {};
  return api.put(input)
    .then(response => {
      state.response = response;
      return extractData(response);
    }).then(extractedData => {
      state.extractedData = extractedData;
      return {
        response: state.response,
        data: extractedData,
      };
    });
}

Scope-dependent exception handling

async function stuff(input) {
  const response = await api.put(input);
  try {
    const extractedData = await extractData(response);
    return {
      response,
      data: extractedData,
    };
  } catch(e) {
    throw new ApiError(e, response);
  }
}

This should become:

function stuff(input) {
  const state = {};
  return api.put(input)
    .then(response => {
      state.response = response;
      return extractData(response).then(extractedData => {
        state.extractedData = extractedData;
        return {
          response,
          data: extractedData,
        };
      }).catch(e => {
        throw new ApiError(e, state.response);
      });
    });
}

You'll note that only in the case of error handling do we actually need to nest promises.

Finally

async function stuff(input) {
  const response = await api.put(input);
  try {
    const extractedData = await extractData(response);
    return {
      response,
      data: extractedData,
    };
  } catch(e) {
    throw new ApiError(e, response);
  } finally {
    logStuff(response);
  }
}

This should become:

function stuff(input) {
  const state = {};
  return api.put(input)
    .then(response => {
      state.response = response;
      return extractData(response).then(extractedData => {
        state.extractedData = extractedData;
        return {
          response,
          data: extractedData,
        };
      }).catch(e => {
        throw new ApiError(e, state.response);
      }).finally(() => {
        logStuff(state.response);
      });
    });
}

Or, if we want to avoid using Promise#finally and instead rely on the initial proposed API:

function stuff(input) {
  const state = {};
  return api.put(input)
    .then(response => {
      state.response = response;
      const finallyFn = () => {
        logStuff(state.response);
      };
      return extractData(response).then(extractedData => {
        state.extractedData = extractedData;
        return {
          response,
          data: extractedData,
        };
      }).catch(e => {
        finallyFn();
        throw new ApiError(e, state.response);
      }).then(_$res => {
        finallyFn();
        return _$res;
      });
    });
}

Free Monads for smart optimized code

Voltra — Sun, 13 Aug 2023 17:42:13 +0000

One of the most annoying and complex problem to solve is database querying. When your request is not a simple read or write, it becomes quite complicated to be fully optimal.

Most of the time, it's due to technical constraints (e.g. a library used makes multiple independent requests instead of batching them somehow).

What if we could eliminate the problem altogether?

My proposed solution? Turn your whole application logic into Free Monad program.

Introducing Free Monads: cool monads that help building eDSL.

The whole idea is that you make sort of "programs" that are really blueprints for an execution. What makes it extremely interesting is that you can evaluate the same program differently, it's the evaluator that dictates how things work, not the program. The program only has the "shape" of the instructions.

How is that different from interfaces in OOP you might ask? It's simple, with interfaces you're still operating at a value level. With Free Monad, you're operating at an operation level.

In a way, you can think of Free Monad programs as a sort of weird AST, and evaluators as visitors.

Here's the proposed pseudo code:

function runApp($request) {
  $program = new AppProgram($request);
  try {
    $dbEvaluator = new DbAppEvaluator();
    $queryData = $dbEvaluator->evaluate($program);
    $responseEvaluator = new ResponseEvaluator($queryData);
    return $responseEvaluator->evaluate($program);
  } catch($e) {
    $errorHandlerEvaluator = new ErrorHandlerEvaluator($e);
    return $errorHandlerEvaluator->evaluate($program);
  }
}

How cool would that be?

Things like Database::connect() wouldn't actually give you a connection object back, but a handle to an operation that has been added to the sequence of the program.

Thing like Query::table("x")->select("*")->where($cond) wouldn't immediately query to the database, but be an handler. Then the database evaluator would get all the queries, optimize them, and do as little work as possible.

A whole framework designed like that would eliminate a lot of poor design choices or bad coding practices that lead to poor performances.

Web Environment Integrity: Google strikes again

Voltra — Sun, 06 Aug 2023 06:51:11 +0000

The Web Environment Integrity is yet another Google proposal for making the web worse for everyone but them.

Links of interest:

Issues with the RFC

Request For Comments, a nice way to make proposals and ask for comments and feedback. Well, usually when one comes out it's at least polished enough to feel like a complete unit.

As of today, very crucial and important parts of the RFC are marked as "TODO". Things like, you know, definitions of "web environment" and "content binding", nothing that important /s.

Hell, even whole sections are missing like "Browser Acceptance Criteria" and "Privacy considerations" which gives off strong "I'll leave the morality of it out of the talk" vibes (no that is not a parody, it's an actual serious talk, you should definitely check it out).

The biggest issue with the RFC is, if you're like me, the first time you read this and looked at the API you certainly thought: "wow... that's actually useless":

Craft a token and... encode it in base64? No asymmetrical encryption? Just Base64? Wth!?
Cool, but how can it be verified?
The token is crafted on the user's device and verified on another?
What is the use exactly?
What prevents it from being spoofed or polyfilled?
This is to fight against fingerprinting? But that introduces a wayyyy better way of fingerprinting users, on a literal MAC address/machine level
You can't remove the need for an anti-virus software on each machine
Making a "web anti-virus solution" is the single dumbest and most useless idea ever! Sure let's give any website a way to inspect (the integrity of) your memory, that sounds like a great idea!

And of course, these questions are absolutely not addressed in the RFC. All you can read is something that feels like someone's draft of an RFC (that needs to be finalized before being published), not an actual RFC. Which probably means that whoever was behind this idea thought of it last minute and pushed it way too hard to have it go out ASAP.

And with the explainer, all the evil is unveiled

You see, before reading the explainer (which is dumb, why external explanation for an RFC) you were already thinking about how this is terrible, a DRM-ization of the web, etc.

But within the first few lines of the explainer, you actually understand that one of the main goals of this is absolutely not to protect users in any way, but to make sure ads are shown to real users and never bots.

It's pretty much a Comic book Villain (or politician) tactic: pretend to do things for others' interest, but in reality you do them for your own.

Goals

Allow web servers to evaluate the authenticity of the device and honest representation of the software stack and the traffic from the device.

That's a mouthful way of saying "we want website to be able to very accurately fingerprint your device". How's the EU doing btw?

Offer an adversarially robust and long-term sustainable anti-abuse solution.

Now that's just absurd and wishful thinking at best. There's a reason anti-virus and anti-cheat software run at system startup and in a different "context" than other programs... You can't do that from inside a web browser.

Plus, that would only cover mid-execution corruption. You couldn't detect prior-to-execution corruption like, let's say, a computer full of malware?

Don't enable new cross-site user tracking capabilities through attestation.

Sure, try to act like you won't use that in GA or GTM at all. How's the EU doing btw?

Continue to allow web browsers to browse the Web without attestation.

Oh thank god, you actually admit yourself that your proposal is a waste and totally useless since you can just skip it...

"Non-goals"

Enforce or interfere with browser functionality, including plugins and extensions.

Oh I'm sure it won't interfere...

In addition to Manifest V3, you'd also like to further kill extension/plugin users and developers? Wow. You really hate adblockers huh? Despite them being a minority in the vast user base? Are you looking for pennies under the couch Google? I have 4 bucks in my pocket if you want.

Enable reliable client-side validation of verdicts

Yes, "reliable client-side" the famous oxymoron. Thank you for "clarifying" that. I hope Google doesn't connect to their production databases directly from the browser...

Access to this functionality from non-Secure Contexts.

What do you not get about "non-Secure"? Are you serious?

Use cases

Detect social media manipulation and fake engagement.

So it's not about users. Got it. And how do you plan on doing that exactly?

Detect non-human traffic in advertising to improve user experience and access to web content

So it's not about users. Got it. And how do you plan on doing that exactly? I'm pretty sure I can make Selenium do things and it'd go through your wide net.

Detect phishing campaigns (e.g. webviews in malicious apps)

How exactly?

Detect bulk hijacking attempts and bulk account creation.

How? Oooooh, by fingerprinting of course!

Detect large scale cheating in web based games with fake clients

See the above about execution contexts of anti-cheat and anti-virus software...

Detect compromised devices where user data would be at risk

There's no reason a malware-infested system couldn't spoof that. It's not an anti-virus...

Detect account takeover attempts by identifying password guessing

Literally how? Do you have any idea of the intrinsic unsolvability of the problem you claim this would solve? Why do you think 2FA/MFA exist? Google literally has one of the strictest ones out there, how do you fain ignorance like that?

Does the explainer, explain or address anything?

No lmfao. Read it for yourself, it's pretty funny how it makes everything worse than the RFC already did.

The final words

You cannot circumvent the Blind Trust Issue. (i.e. the fact that any trust is always blindly given, otherwise it'd be knowledge)

Hell, the whole thing relies on a 3rd-party attester which is an even bigger joke in and of itself.

It's not even like HTTPS, DNS Sec, or whatever intelligent and well thought out security thing. That one is just useless junk if you're not Google Ads.

The only way to circumvent the Blind Trust Issue is to turn trust into knowledge, that much is obvious. The only issue is that you can't have knowledge about a site being compromised (e.g. downloading a renowned browser), that your IP packets are not being intercepted (network layer), that your TCP packets are not being logged or intercepted (ISP), that your machine doesn't have spyware built into the OS, that the software you use is what it's advertised as (that's why we need reproducible builds), etc...

It's the same thing with "Decentralized Web". You don't eliminate the need for trust at all, you just move it elsewhere.

A novel idea for (more) deterministic recommendation engines

Voltra — Wed, 17 May 2023 11:20:59 +0000

The idea comes from the fact that the search engine of YouTube is pretty decent, but the recommendation one isn't.

If only we could used that search engine for recommendations...

That's where Algorithmic Reduction comes in. If we can express our recommendation problem as a search problem, then we can just use the search engine to get our recommendations.

What's a recommendation engine anyway? Basically (or mathematically), it's a function that takes a User and returns an ordered list of Item.

What's a search engine? Basically (or mathematically), it's a function that takes a SearchQuery and returns an ordered list of Item.

What if we could turn a User into a SearchQuery? Then the recommendation engine would simply be the composition of the transformer function and the search engine.

Given that most website collect statistics about their users, this shouldn't be such a daunting task. And given how search engines are usually more deterministic than recommendation engines, then even if that transformer function is a heuristic, this approach should give extremely satisfactory results.

Potential pitfalls:

Recommendation engines nowadays have a very strong bias towards how recently an item has been visited by the user (you get more recommendations on the latest 15 videos you've watched). You might want to stray away from that tendency

The misery of Hacktoberfest's reward merch

Voltra — Wed, 08 Feb 2023 17:52:42 +0000

As you may know, one of the rewards you can choose from for participating in Hacktoberfest is the merch.

As some of you may also know, in the EU (or at least in France), there's a customs' tax for products coming from the US (and a few other countries).

And instead of ticking the "Gift" box (which makes sense, as that's what this essentially is), they always tick the "Others" box, which forces you to pay Customs Taxes for something you got for free, which is annoying af.

That's two years in a row, who knows if I'll want to keep this going.

What is e.defaultPrevented and why library authors MUST use it

Voltra — Fri, 06 Jan 2023 12:58:00 +0000

Event#defaultPrevented is, as per MDN, a flag available on an event to know whether its default action was prevented (regardless of whether Event#preventDefault was called, but calling it will set the flag to true).

Why do library authors need to use it? Because a listener added by the user calling e.preventDefault() will not prevent your listeners from being called.

@dogstudio/highway is one such library that doesn't check for that, and thus preventing the default behavior of an anchor will not prevent further navigation.

Using e.defaultPrevented is here to ensure everyone can safely add listeners and execute them only if they should.

Should browsers make the check for you? Maybe, but it might get freedom away for some use cases. In the meantime, please check for the flag.

Dear "developers" who insist they don't need HTTPS, or SSL certificates

Voltra — Sat, 29 Oct 2022 11:29:26 +0000

Please invite me somewhere we can share the same network, you know, so you can showcase your brilliance and websites that don't use HTTPS while I steal every piece of personal data I can.

Seriously, security is not a fucking joke, stop dicking around...