1. 3

    Ugh… I know it’s not the point of the article but still hurts me to see sql that’s vulnerable to injections.

    1. 1

      Ah you’re right. Fixed it.

    1. 1

      Well written and interesting article. Looking forward to Part 2

      1. 7

        Deno seems very interesting. He’s trying to rectify his mistakes and adopt typed, async JS.

        URL imports seem somewhat interesting but have one large flaw in my opinion - they drop the singular responsibility of security in exchange for a shared one.

        NPM has a lot of issues, especially security ones, but at least it’s an actively maintained, up to date entity. If something goes wrong someone will notice very quickly and they will attempt to rectify it very quickly.

        With URL imports, however, I’m worried that we’ll lose the quickly part of this. Imagine a scenario in which an early adopter makes a left-pad like module - something trivial that isn’t in the STL but everyone wants. In a few years they migrate away, and become removed from the tech community (but still host their domain/js)

        If this domain gets compromised, every package with that import will be done. There won’t be a central authority that can sink that package or domain - it will be a shared responsibility of every developer, which is significantly more dangerous than the singular responsibility of npm.

        1. 14

          I was amused to note that he cautions against using “cute” code and then goes on to call URL imports cute at around 21:14

          1. 4

            The main thing I’d counter with is that the web has run on URL imports like that, and has managed it fairly well. Spread of imports also means spread of attack targets. NPM is a singular target by comparison, vs the various CDNs, libraries copied locally, and so on that this scheme proposes.

            Overall, it’s a different tradeoff, and so far, this JS runtime is a thought experiment.

          1. 2

            I’ve used Streisand to create a VPN endpoint on a Digital Ocean droplet. AWS, Google Cloud and more are supported out of the box.

            1. 2

              Streisand looks very cool!

              I’ve personally used Algo a lot - spins up a quick IPSEC VPN. I’ll trash it and make a new one every few weeks, really well written and good bit of software.

            1. 13

              Not much has changed since 2012 when this was published, Rust & Go (released in 2009/10) still don’t have any GUI libraries anywhere near as simple as REBOL, instead wrapping an older GUI system or using XML. In fact, most programming languages seem to expect you to make the GUI in HTML/JavaScript/CSS now, 6 years after this post. Even visual programming languages like Scratch rely on replicating textual elements with graphical puzzle pieces. Once you get into Piet or pureData, the language is visual, but I wouldn’t recommend trying to write a GUI app with an esolang like Piet, pureData, on the other hand, lets you create a simple or more complex GUI but it’s nothing you would traditionally consider code.

              1. 3

                Have you tried / what do you think of something like ImGui (especially when exposed to a “scripting” language)?

                1. 1

                  Haven’t seen it before – looks good – and it’s been ported to Rust/Go & Javascript… https://github.com/ocornut/imgui

                2. 1

                  I think that the we are still far away from the ideal library the article mentioned.

                  Electron (for all it’s flaws) get’s fairly close. It’s not as descriptive, but HTML paired with a good CSS framework can get fairly close.

                  There’s nothing that’s true native that comes even close though. I wonder how long it’ll take. Maybe with the advent of UIKit for macOS/iOS we’ll get another paradigm shift?

                1. 1

                  The high count for times that compdef is run indicates that this run is without a cache for compinit. The lack of calls to compdump also indicates that it isn’t creating a dump file. This cache, speeds compinit startup massively. I’m not quite sure how the blog post author has contrived to not have a dump file.

                  1. 4

                    “contrived” is a rather strong word to use here and suggests intent (perhaps to deceive). I’m not sure if it was your intent or not.

                    1. 3

                      This actually is with a dump file. A .zcompdump-MACHINENAME file is created in ~ (see here).

                      The issue is that this is recreated each time the shell starts up. There are multiple places in OMZ that call compinit. In the additional reading at the bottom there is a link that modifies zsh to only recreate it once a day, but I still feel like that’s not ideal.

                      1. 2

                        Can you redefine compinit to a no-op during OMZ loading, and then do it yourself at the end?

                        IMO zshrc should explicitly call compinit so it happens exactly once in a central location.

                      2. 2

                        Maybe he didn’t know?