17 Matching Annotations
  1. Oct 2023
    1. as the ecosystem around it swirled, the web platform itself remained remarkably stable
    2. There’s a cost to using dependencies. New versions are released, APIs change, and it takes time and effort to make sure your own code remains compatible with them. And the cost accumulates over time. It would be one thing if I planned to continually work on this code; it’s usually simple enough to migrate from one version of a depenency to the next. But I’m not planning to ever really touch this code again unless I absolutely need to. And if I do ever need to touch this code, I really don’t want to go through multiple years’ worth of updates all at once.

      The corollary: you can do that (make it once and never touch it again) if you are using the "native substrate" of the WHATWG/W3C Web platform. Breaking changes in "JavaScript" or "browsers" are rarely actually that. They're project/organizational failures one layer up—someone (who doesn't control users' Web browsers and how they work) decided to stop maintaining something or published a new revision but didn't commit to doing it in a backwards compatible way (and someone decided to build upon that, anyway).

  2. Aug 2023
    1. This is why I build my personal projects in PHP even though I'm not really a fan. I use PHP and JQuery. It'll work basically forever and I can come back to it in 15 years and it'll still work.

      When people mistakenly raise concerns about the Web platform being fragile, point to this common meme.

  3. Jan 2023
    1. There’s a caveat that we’re aware of—while Hydrogen and App developers only require one runtime (Node), Theme developers need two now: Ruby and Node.

      Well, you could write standards-compliant JS... Then people could run it on the runtime everyone already has installed, instead of needing to download Node.

  4. Aug 2022
    1. I think we can define an "archival virtual machine" specification that is efficient enough to be usable but simple enough that it never needs to be updated and is easy to implement on any platform; then we can compile our explorable explanations into binaries for that machine. Thenceforth we only need to write new implementations of the archival virtual machine platform as new platforms come along

      We have that. It's the Web platform. The hard part is getting people to admit this, and then getting them to actually stop acting counter to these interests. Sometimes that involves getting them to admit that their preferred software stack (and their devotion to it) is the problem, and it's not going to just fix itself.

      See also: Lorie and the UVC

    1. lack of a common powerful hi-level language available on every computer remains. You still cannot write a script file and send it to everyone and expect them to be able to run it without installing something first. The closest we probably have is HTML with JS embedded, since everyone has an HTML browser installed
    1. no matter how ill-adapted it is to our needs

      I dunno. I think the common argument that the Web was not intended to be an application delivery platform is both (a) ignorant of basic facts in subtle ways that are materially relevant to the particular use case described here and (b) poorly applied to this use case, given those particulars.

      I don't like most traditional Web apps or what passes for best practices in the contemporary culture. I don't write them, and I'm not defending them.

      But we're talking about scientific literature here. I'll dispute the general argument as it applies to the specific use case under discussion by pointing out that a document-centric platform is in fact exactly the correct tool for the job in this case. The only thing that could be better is if you were able to write your paper more or less as you ordinarily do for journal publication and then feed the journal article into a machine able to comprehend the methods at a deep level and then simulate what it describes. We don't have that, though. But we can to author documents that are a little more explicit instead. This is not a terrible consolation prize. So we really should start seizing the benefits of the current circumstances, lest the Web platform actually turn into something unsuited for this. (Which, perversely, is most likely to happen as a result of pursuing the vision of making it more suited for traditional software development.)

      Again—by all means, don't compile to asm.js (or WASM, or from TypeScript, etc.). Put it to use on its strengths and in the spirit of its original vision.

    2. Note however that it’s not “any of today’s virtual machine managers”

      I agree. And this very reason (along with the complexity, mentioned in the following paragraph) is what should disqualify VirtualBox.

      The virtual machine manager you should use is the one you assumed would be available when you published this post (and that you were correct about, and that I am using right now to read it): the Web browser.

    3. For the 2013 Web platform, you may hope that its sheer popularity will motivate someone to keep it alive, but I wouldn’t bet on it either. The Web platform is too complex and too ill-defined to be kept alive reliably when no one uses it in daily life any more.

      There's some sleight of hand here, which treats "when no one uses it in daily life anymore" as a given. That (folks continuing to use it) is the stability of the Web platform.

      Besides, even if we suppose that people have stopped using it (dubious), the entirety of what constitutes "the 2013 Web platform" is not necessary—only the parts that are actually used for computation and I/O. That's much smaller.

    1. David Cournape made the interesting observation that no technology less than 20 years old is better than Python in terms of stability.

      Not true. The standardized Web platform is not just more stable than Python, it's probably one of the most stable platforms in existence. It just moves (read: improves) slowly.*

      Most people don't recognize this, because they pack the stable, standardized parts all in the same mental bag as the shiny, non-standardized parts (like Flash, for an example of decades past, or experimental vendor-specific stuff for a more evergreen problem), then end up getting bit in a similar way and blaming the environment rather than communal tendencies towards recklessness.

      It also turns out that the Web's original academic underpinnings are deeply aligned with the goals of researchers looking for a way to work together—even if the final puzzle piece (ECMA-262) didn't come into existence until later in the decade when the Web first appeared. It's still old enough that it passes the litmus test proposed here.

      * for good reason; after all, look at the evidence

    1. I basically think of it as an "executable README". A README or blog post often contains shell commands. So I just copy those into a script.

      Suppose that instead of shell commands, the snippets were JS, and the README, rather than being named README.markdown or README.txt, were actually named e.g. README.txt.htm. it wouldn't be basically like an executable README—it would actually be executable. You could double click it to open, and then read through it and use it to actually do the stuff that the README is documenting (like build the project in question).

  5. Jul 2022
    1. Yes, it’s making it easier than ever to write code collaboratively in the browser with zero configuration and setup. That’s amazing! I’m a HUGE believer in this mission.

      Until those things go away.

      A case study: DuckDuckHack used Codio, which "worked" until DDG decided to call it a wrap on accepting outside contributions. DDG stopped paying for Codio, and because of that, there was no longer an easy way to replicate the development environment—the DuckDuckHack repos remained available (still do), but you can't pop over into Codio and play around with it. Furthermore, because Codio had been functioning as a sort of crutch to paper over the shortcomings in the onboarding/startup process for DuckDuckHack, there was never any pressure to make sure that contributors could easily get up and running without access to a Codio-based development environment.

      It's interesting that, no matter how many times cloud-based Web IDEs have been attempted and failed to displace traditional, local development, people keep getting suckered into it, despite the history of observable downsides.

      What's also interesting is the conflation of two things:

      1. software that works by treating the Web browser as a ubiquitous, reliable interpreter (in a way that neither /usr/local/bin/node nor /usr/bin/python3 are reliably ubiquitous)—NB: and running locally, just like Node or Python (or go build or make run or...)—and

      2. the idea that development toolchains aiming for "zero configuration and setup" should defer to and depend upon the continued operation of third-party servers

      That is, even though the Web browser is an attractive target for its consistency (in behavior and availability), most Web IDE advocates aren't actually leveraging its benefits—they still end up targeting (e.g.) /usr/local/bin/node and /usr/local/python3—except the executables in question are expected to run on some server(s) instead of the contributor's own machine. These browser-based IDEs aren't so browser-based after all, since they're just shelling out to some non-browser process (over RPC over HTTP). The "World Wide Wruntime" is relegated to merely interpreting the code for a thin client that handles its half of the transactions to/from said remote processes, which end up handling the bulk of the computing (even if that computing isn't heavyweight and/or the client code on its own is full of bloat, owing to the modern trends in Web design).

      It's sort of crazy how common it is to encounter this "mental slippery slope": "We can lean on the Web browser, since it's available everywhere!" → "That involves offloading it to the cloud (because that's how you 'do' stuff for the browser, right?)".

      So: want to see an actual boom in collaborative development spurred by zero-configuration dev environments? The prescription is straightforward: make all these tools truly run in the browser. The experience we should all be shooting for resemble something like this: Step 1: clone the repo Step 2: double click README.html Step 3: you're off to the races—because project upstream has given you all the tools you need to nurture your desire to contribute

      You can also watch this space for more examples of the need for an alternative take on working to actually manage to achieve the promise of increased collaboration through friction-free (or at least friction-reduced) development: * https://hypothes.is/search?q=%22the+repo+is+the+IDE%22 * https://hypothes.is/search?q=%22builds+and+burdens%22

  6. May 2022
    1. Can you imagine if the beginner version of Node.js came pre-installed with a GUI for managing and running your code?

      A graphical JS interpreter? That's the browser! And it just so happens that it's already installed, too (everywhere; not just on Macs).

    1. To run it you need node.js installed, and from the command line run npm install once inside that directory to install the library dependencies. Then node run.js <yourExportedDirectory>

      Why require Node?

      Everything that this script does could be better accomplished (read: be made more accessible to a wider audience) if it weren't implemented by programming against NodeJS's non-standard APIs and it were meant to run in the browser instead.

  7. Mar 2022
    1. From the homepage:

      Repla is a macOS app that can[...]

      That's like the complete opposite of "just give me a document that I can double click to open from disk and view in my browser"...

    1. I’m considering updating my Mac to Big Sur just to run this.

      Meanwhile, not only does the scope of this tool not merit the Big Sur requirement, it doesn't even require a Mac. It interaction style is so free of intracies that it could be developed (and distributed) as a single HTML file with a text input and some script blocks.

    1. Around @11:16:

      "What made HyperCard the ubiquitous product it was in the early 90s... was the fact that it was included free with every Macintosh sold. So anybody could use it to create somethnig, then share their creation with somebody else with the confidence that the other person would be able to run it."

      So that was in that day. What is the box today?

      Let me ask it another way: What is available on every computing device[...]?"

      I would encourage us all to find ways to make the system immediately available to users.