Echo JS 0.11.0

This article is just wrong... it seems to be confusing `async function` and the `async` module in npm.  Do *NOT* follow this article's advice...

Should I just delete the link?

It does seem to come up for me.  Maybe a server caching hiccup.

Cool... though I'd probably prefer WireGuard if I'm rolling my own VPN setup at this point.

This is mostly about automated UI / Regression tests with selenium (and similar).

While JS is my favorite language... and it's more broadly available than pretty much anything else.  It's also probably the most widely used (by nature of web dev).  All of these things said, it's a poor language for a beginner to learn programming concepts with.

IMHO, if you are visually oriented and/or starting from a designer or front end perspective, JS might be the best choice to start with (this assumes you have some HTML and CSS knowledge to leverage).  If you are coming from ground zero and want to learn programming, Python is probably the best language to start with.

Python was created as a learning language and has expanded into many areas.  The learning content for Python is very broad without diving into hardware/cs concepts to get your feet wet.

I say this as someone that loves JS, and doesn't really know any significant Python at all.

I really appreciate github's actions, and it's imho better, if similar, than Azure's new pipeline .yaml format.  Will probably migrate some of my npm packages from travis.

In case anyone is doing a publish to npm proper…
https://gist.github.com/tracker1/fdd5ceab8f532afc3a05ab9c0bddebc1

Interesting simple approach, should probably check and see how  big the import gets.  Seems to depend on amonad that has a tslib dependency (not dev dependency).

(also posted on the medium article as a comment)

First, I think that flow is pretty much a dead end. I know that it's backed and used by Facebook, so will probably be around for a while, but have the distinct impression that TypeScript has won out on this, and that the broader npm module systems have more thorough support for TS. TS has over 8m downloads a week, while Flow has around 16k.

Second, on if it's worth it, depends on how many developers and of what skill level you are working with. Beyond this, what kind of structure you enforce not to mention other potential aids/rails like code coverage for testing, etc. TS does allow for a nicer refactoring workflow, you break things and fix the breaks when you refactor. JS requires a more judicious approach, which isn't bad if you start with a clean directory/module structure and keep your code testable. To that last part, code coverage and testing help ensure, but do not guarantee a cleaner approach.

Personally, I find that I don't gain from having typed code in JS. That said, I can see the advantage on some projects/teams that are less experienced, or more likely to have different approaches on a project lifetime. It is not a replacement for clean or testable code. Aside, I'm also not a fan of the class approach in general and prefer more function based modules/libraries that act on general objects (can use interfaces in TS).

Tend to follow a similar structure... a minor difference though...

    / - baseline configuration
    /scripts
      /npm - node/npm configured scripts
      /ci-cd - scripts for env/ci-cd
    /client - client application
      /index.js - main entry
      /index-ssr.js - server-side render entry
      /feature - all client features
        /wwwroot - assets deployed in root (favicon etc)
        /app - application wide components
        /api - api client abstraction
        /feature-name - components/logic/reducers/etc
    /server - server/api application
      /index.js - main entry point (see: npm os-service)
      /feature - all feature structures
        /webserver.js - main server start
        /static.js - statically mounted resources, reverse proxies, etc
        /middleware - middleware
        /routes - routes for api
        ...

If there are multiple configuration targets, I'll have a /configuration/configs/TARGET-NAME directory for those configs/assets.

It's in TypeScript at this point (glad for that, got tired of squiggly lines in VS Code), but still a ways away, not in any browser proper at this point, and will need Babel/TypeScript etc for a few years after that.