Today’s JavaScript, from an outsider’s perspective (2020)

• ten-years

  1 62 10.0

  Ten Years Reproducibility Challenge

  

I recently had to work on library I wrote in Go in late 2013. I think it was Go 1.2 back then. (Current release is Go 1.18)

It just worked.

And code was quite readable. I mean it not as a complement to myself, rather the fact that Go is designed to be readable and it pays off.

I only had to add modules support (basically run `go mod init` in the library's folder) to make it 100% modern-version friendly.

That was as close as I could be to successfully complete 10 Years Reproducibility Challenge [1].

[1] https://github.com/ReScience/ten-years

• tetra

  17 513 0.0 Python

  Tetra - A full stack component framework for Django using Alpine.js (by samwillis)

JS tooling has come a long way in the last couple of years, Vite for example is so much better than everything that came before. Esbuild is incredible and clearly the future of all JS build tools.

The trouble is that to people who are only just outside JS ecosystem it’s not very accessible. If you are a PHP, Python or Ruby developer who cut your teeth in the era of jQuery or earlier it can be quite difficult to make the transition.

Combining the modern JS environments with platforms like Django, Laravel or Rails often means having to install and setup from scratch a full Node/NPM toolchain in parallel with your backend toolchain. I believe this is some of the reason for such a disconnect between the the “backend” and “frontend” unless you go 100% JS. I think it's pushed a lot of devs who used to think of themselves as "full stack" towards the backend.

I’m trying to fix this with Tetra (https://www.tetraframework.com) for the Django ecosystem, the plan is to eventually bundle a esbuild/postcss/sass/less toolchain along with built in tools for installing JS dependancies so you can completely live within the Python/Django environment. It will manage all the complexities of JS tooling for you.

The vast majority of developers don't want to think about tooling, they just want to build something quickly and get it out there.

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• meta

  5 113 0.0

  Meta discussions and unicorns. Not necessarily in that order. (by sindresorhus)

ESM is the biggest waste of time in the JS ecosystem. People are trying to move thing to ESM before it's even in a stable enough state. Mixing ESM and commonjs is a PITA. I've been a JS-only dev since 2013, and I've had enough of ESM ideologues.

See https://github.com/sindresorhus/meta/discussions/15 for just ONE example of this mess.

I don't know why it's become this ideological war where people are 'testing the waters' on production-used libraries. It's not the approach I would have taken.

• paperclips

  121 68 10.0 Shell

  Universal Paperclips mirror

This just isn't true, though.

I have quite a few non-technical colleagues who know just enough Python to Get Shit Done.

My father (a writer) taught himself R for research purposes and is productive with it.

Universal Paperclips has a super-basic JavaScript codebase[0] but was a really popular game.

Thing is, if you search "how to do X in Python" you're going to get a bunch of resources aimed at professionals because they're the ones looking for that stuff most of the time. That doesn't mean the resources are prohibitively complex, they're just for people solving a different problem.

[0] https://github.com/jgmize/paperclips/tree/master/docs

• .NET Runtime

  607 14,091 10.0 C#

  .NET is a cross-platform runtime for cloud, mobile, desktop, and IoT apps.

  

I have, but to be honest I've forgotten a lot of the specific debates and their finer points.

I don't have a single, definitive, clear solution -- as pointed out by others -- nobody does. It's not a simple problem.

That doesn't mean that steps can't be taken to improve the situation, perhaps dramatically in some cases.

1) Enforced MFA to publish a crate -- credential theft is semi-regularly seen as an attack vector.

2) Strong links between the "source ref" and the specific crate versions. An example of this done super badly is NuGet. All of the hundreds (thousands?) of Microsoft ASP.NET packages point to the same top-level asp.net or .net framework URLs. E.g.:

https://www.nuget.org/packages/Microsoft.Extensions.Configur...

Links to "https://dot.net" as the Project Website, and "https://github.com/dotnet/runtime" as the repository. This couldn't be more useless. Where is the Git hash for the specific change that "7.0.0-preview.4.22229.4" of this library represents? Who knows...

3) Namespaces. They're literally just folders. If you can't code this, don't run a huge public website. This is more important than it sounds, because wildly unrelated codebases might have very similar names, and it's all too easy to accidentally drag in entire "ecosystems" of packages. Think of the Apache Project. It's fine and all if you've "bought in" to the Apache way of doing... everything. But imagine accidentally importing some Google thing, some Netflix thing, some Apache thing, and some Microsoft thing into the same project. Now your 2 KLOC EXE is 574 megabytes and requires 'cc', 'python', and 'pwsh' to build. Awesome.

For example, in ASP.NET projects I avoid anything not officially published by Microsoft and with at least 10M downloads because otherwise it's guaranteed to be a disaster in 5-10 years. Ecosystems diverge, wildly, and no single programmer or even a small group could possibly stitch them back together again. Either it's a dead end of no further upgrades, or rip & replace an entire stack of deeply integrated things.

4) Publisher-verified crate metadata / tags. You just cannot rely on the authors to be honest. It's not even about attacks, it's also about consistency and quality. All crates should be compiled by the hosting provider in isolated docker containers or VMs using a special "instrumented build" flag. Every transitive dependency should be indexed. Platform compatibility should be verified. Toolchain version compatibility should be established for the both the min and max range. Flags like "no-std" or whatever should be automatically checked. CPU and platform compatibility would also be very helpful for a lot of users. The most important one in the Rust world would be the "No unsafe code" tag.

This would stop "soft attacks" such as the guy spamming C++ libraries as Rust crates. Every such crate should have been automatically labelled as: "Requires CC" and "Less than 10% Rust code".

I'm expecting a lot of arguments along the lines of "that sounds like a lot of work, etc..." Meanwhile Mozilla had a large team for this, millions of dollars of funding, and did not do even 0.1% of what Matt Godbolt did in his spare time...

• deno

  448 92,907 9.9 Rust

  A modern runtime for JavaScript and TypeScript.

  

Try http://deno.land - think of it as sequel to node (written by same guy who created node, aiming to fix mistakes of the past - e.g. deno does not use NPM)

• era5_in_gee

  1 77 2.7 Python

  Functions and Python scripts to ingest ERA5 data into Google Earth Engine

Yeah - I work with Python for my main work dealing with weather & climate data but things still throw me off. It feels like every example I run into is an easy to follow "20-steps + 10 packages + 64GB cloud server instance" process when all I want to do is to download some historical temperature data to CSV.

Example: https://github.com/jwagemann/era5_in_gee#workflow-overview

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

• packj

  38 614 7.2 Python

  Packj stops :zap: Solarwinds-, ESLint-, and PyTorch-like attacks by flagging malicious/vulnerable open-source dependencies ("weak links") in your software supply-chain

  

Packj tool (https://github.com/ossillate-inc/packj) analyzes Python/NPM packages for risky code and attributes such as Network/File permissions expired email domains. It uses static code analysis. We are adding support for Rust. We found a bunch of malicious packages on PyPI using the tool, which have now been taken down: examples https://packj.dev/malware [disclosure: I’m one of the developers]

Suggest a related project