The problem with the suggestions here is that it puts all your eggs in the same basket. 1Password TOTP? If both your password and the TOTP are in your password manager, you arguably really just have a single factor, delegated to a third party (your password manager). PassKeys? Same problem. Storing your recovery keys in your password manager? You again just have 1 factor.
SMS is bad and should go away, but it isn't so clear what the replacement needs to be for most people.
If you use a password manager, you might not be part of the target group that benefits most from a second factor.
A decent password manager nudges you into using unique passwords per service. Good password managers also offer you a browser extension, which injects the password directly into the DOM instead of using the clipboard, and checks the domain, too. It's not 100% secure, but at that point, 2FA may be a diminishing return already.
> However, assertions that web apps are inherently inferior and that web apps are only written by people who couldn't bother to learn native technologies is at best ignorant and at worst lacking empathy with the requirements and constraints, and in turn with end users empowered with choice.
Well, "inferior" is always a subjective claim. The real problem with Electron, besides perhaps resource consumption, is that web apps are not native apps and native apps have all kinds of idioms, integrations, etc. A selling point of Electron is that it has "native menus." That's it. Just native menus.
They do not have, for example, proxy icons. They usually don't have system-wide services integration. They can't be automated with AppleScript. The print dialog are almost always weird, etc.
There are similar idioms on Gnome, KDE, etc. Think about header bars or Adwaita in Gnome. Or ssh filesystem support in KDE.
All these things make users more productive. If you really know your way around a desktop environment, and you know all the tricks, you can be massively productive with native apps. You'll never be similarly productive, however, with even the best Electron apps.
The mistake the author is making here is conflating a "good" app in isolation with a good app in a desktop environment. An Electron app which is an amazing app in isolation, with thoughtful design and efficient code and useful features, is always a bad app in any actual desktop environment. Putting an Electron app in MacOS or Gnome or KDE is like putting gummy bears in tacos or lasagna. Gummy bears are good. Tacos are good. But they don't belong together.
So where are Electron apps actually good? I'm guessing ChromeOS. Otherwise, they always kind of suck, even the $25k Electron apps at Bloomberg. And while I hesitate to make blanket statements, I have yet to use a single Electron app I actually want to use, ever. They're always, and this is without exception, garbage on any desktop environment I actually want to use. Full stop.
Well, yes and no. I think there would be no Electron Apps if the native desktop sdk/api/frameworks wouldn’t be garbage.
On Windows it’s a total mess, Win32/WPF/UWP and now what ever their fancy is (I think it’s Win32 again?).
Linux the same, so many differ ent things like kde/gnome or whatever. I think without electron there wouldn’t even be many nativ apps for Linux. And MacOS? Well can’t really say anything here because last time I tried doing some native development there, XCode was just too horrible and I stopped. Maybe Cocoa/SwiftUi is ok, I don’t know.
For me it’s like we replaced garbage with other garbage. The one garbage is for developers and the other for end users. I think most end users doesn’t even care, like what’s apple script? I just want to listen to music. I also think the majority of people doesn’t even have a printer anymore?
So the benefits of native apps are just for a small fraction of users. I would love to see more native apps but I understand why developers choose not to do it.
I'd say Electron apps would exist regardless of the native toolkit quality. The business case is that you're probably already building a website, and if that's the case, why not offer native apps too with almost no added development time? The value of Electron is that you don't have to hire development teams for each platform.
And yes, Windows development is a mess. Mac less so. KDE and Gnome have their strengths and weaknesses. Ask around the average Mac, Gnome, and Windows user what they think of Electron apps. Windows users are probably the most positive, because their desktop experience is garbage anyway.
Does that make JavaScript actually better? Win32/WPF/UWP meet Angular/KendoUI/Sencha. React and Vue are slightly less messy, admittedly. But it's still a very fragmented landscape.
The account recovery process for commercial email providers usually involves you photographing your ID. Presumably the post office, in person, would be far less likely to be fooled.
It was happening a lot under Guido too, but IMO, Python was arguably a better language (at least in some ways) 10, 15, even 20 years ago. Python's three super powers were readability, simplicity, and a vast standard library that negated the need for most projects to seek out third party modules.
All three of those have declined. It's less readable than it used to be, it's definitely more complicated (not just complex, complicated), and the standard library is declining rapidly in relevance as it ages.
And it wasn't just Guido. Tim was a big advocate for all three of those super powers when he was more influential. They banned Tim and they censored Guido, so go figure.
> All three of those have declined. It's less readable than it used to be, it's definitely more complicated (not just complex, complicated), and the standard library is declining rapidly in relevance as it ages.
I find it much more readable, and more importantly more expressive. Certain new features are missteps IMO, but I just don't use them. But more importantly, the language has been moving away from cryptic %-encodings and other C idioms.
As for the standard library, that was already happening for a long time, and is inevitable. The world has fundamentally changed. In Python's heyday it was much harder to download and install and use a third-party library, so a rich standard library was an asset. Now it's full of specialized code that handles obscure and increasingly irrelevant data formats; multiple overlapping hacks for binary data; terrible and confusing date support; awkward interfaces that haven't stood the test of time (particularly all the networking stuff; Requests is one of the most downloaded PyPI packages, along with its dependencies which are probably almost never downloaded for any other reason); etc.
Lots of people still seem to think that the 2->3 migration was a mistake. They couldn't be more wrong. The old way of handling "strings" was abysmal, and spit in the face of the Zen. Error messages were confusing and implicit conversions abounded.
Also, just for the record: Guido van Rossum was in favour of the walrus operator. In fact, he co-authored the PEP (https://peps.python.org/pep-0572/), along with Tim Peters.
The walrus operator is nice, except in comprehensions. f-strings are great, except for the `=` debugging operator. Dictionary merging and update operators contradict the "one way to do it" with weird and confusing syntax that's completely redundant to methods that already exist.
Type hints are a sore spot for me. They're good enough when you just don't remember whether an argument is an object or a string, for example, but once you start type hinting deep into data structures, your hints become a mangled soup of nonsense for basically no real benefit. Typing errors are a rare occurrence—perhaps once a year in most projects—yet we clutter our codebases with verbosity to satisfy type checkers instead of prioritizing clarity for developers.
There's a lot that's just straight up redundant. Dicts are ordered now, but is OrderedDict deprecated? No, because it's just slightly different in weird and mostly unimportant ways. `frozenset` is a builtin, for all 3 programmers worldwide who use it. Python resisted match/case syntax for decades, but when it finally arrived, it did so in a way that’s anything but standard—good luck figuring it out without consulting the documentation.
Obviously some improvements are real. Every new version of Python brings valuable enhancements. But just go back to Python as it used to be -- pseudocode that runs. That's just not true anymore. The simplicity has slipped away and will never ever come back.
And the standard library? A very real problem, right now, in computer security is the software supply chain. Remember polyfill from like, yesterday? This is the era when we should double down on having a million dependencies from all over GitHub, from unknown developers with no commitment, because ... npm's hellscape is a model to follow?
I would argue the contrary. There's dependency hell, of course, but there's also dependency risk. If you were evaluating a product right now, and you saw its lockfile depended only on a specific version of the Python Standard Library, that gives you exactly 1 product to evaluate, exactly 1 team of developers to depend on. pip is great and all, but dependency resolvers have quietly let in a hundred trojan horses and a thousand unmaintained dependencies into tons of projects, and no one noticed it was even happening.
Python in 2005, when everyone depended on the standard library, was a safer place than npm is today.
>Dictionary merging and update operators contradict the "one way to do it" with weird and confusing syntax that's completely redundant to methods that already exist.
I find the unpacking syntax elegant. There are yet more unrealized possible generalizations of it that I can think of.
> Type hints are a sore spot for me.... Python resisted match/case syntax for decades, but when it finally arrived, it did so in a way that’s anything but standard
Many people expect match/case to be "a switch statement" but it really is not designed for this purpose. I agree that it's an awkward fit and I don't use it. Similarly, I only use type annotations for documentation purposes.
> Dicts are ordered now, but is OrderedDict deprecated? No, because it's just slightly different in weird and mostly unimportant ways.
Large amounts of existing code are dependent on those ways, because the code was written to use that design. The ordering of dicts since 3.6 is an accidental consequence of an unrelated space optimization. In my view, the team erred by deciding in 3.7 to guarantee that ordering. I have concretely identified a further space optimization which is prevented as a result.
> Python in 2005, when everyone depended on the standard library, was a safer place than npm is today.
The flip side of dependency risk is security risk from lack of maintenance. For example, the standard library `json` module is a frozen-in-time old version of `simplejson` (it even remembers a useless version number). That project is still actively maintained (https://github.com/simplejson/simplejson) but none of those improvements - even if they fix security - will make it into Python except by parallel work by the core dev team. (Or accepting a patch; but that also requires either the maintainer or a third party to notice that a recent `simplejson` change is a security fix, figure out how to backport it to the much older version, and make a PR.)
There are other ways to solve the problem. For example, an organization similar to PyPA could publish a set of "core" libraries, versioned independently from Python but explicitly tested as part of the CPython release process. (That would also allow for fixing the problem that the standard library isn't namespaced - which is at the root of the problem whereby beginners e.g. put their toy lottery project in `random.py` and get an error from a circular import, or - I swear I'm not making this up - having a `token.py` in the current working directory breaks the interactive REPL help - see https://stackoverflow.com/a/75068706).
So, yes, it would be nice to see lockfiles that "depend only on a specific version of the Python Standard Library". Right now, that dependency goes undeclared, and the maintenance work is distributed among people who are also busy with developing the actual language.
Pretty much every heavy traveler I know strives for carryon only. It isn’t always possible and sometimes you check a bag, but if you can do it, the benefits are real.
It’s mostly just that you want to travel light. It gives you more freedom of movement and flexibility to have just one suitcase or backpack. But that means everything from your computer to your prescription drugs to your socks and underwear is in there, so checking it isn’t an option if you travel light.
You're replacing one interpreted language for another.
Yes, Python is among the slower interpreted languages out there, but still. The debate between fast execution and programmer productivity is not a new one. Given Python's popularity, I'd say it's settled.
Yes, they link to examples and all of them run way slower than the equivalent JS version. Most likely because python has to ship its interpreter in the WASM bundle.
If the user experience is significantly worse, I don't care if it was easier for you to write the code.
Runtime and download time are two different things.
Pyodide runs at least ~10MB. That's a lot for a web app to handle, for sure. The use case there is most likely either scientific computing/data science (where JavaScript is just an obvious non-starter), or it's line of business somewhere where someone downloads an ERP app and just runs it. Those are already huge, as anyone who uses the stuff from ERP companies can attest.
No one is seriously proposing that you should use Pyodide, with the whole Python standard library, to add interactivity to a regular newspaper website or something like that.
MicroPython might be a good fit for that though. It's ~100k -- smaller than a lot of JS tooling.
But usually when we say "fast language" or "slow language," we're talking execution speed, not runtime size.
SMS is bad and should go away, but it isn't so clear what the replacement needs to be for most people.