I too spent far too many years in the adtech industry before realising that what I thought I was doing (helping fund cool things on the web) was not what I was actually doing (destroying the web as I knew it.) Having left it behind in the early 10s it's got way worse than I ever imagined, there's effectively no regulation at all now, and certainly no way of knowing where the ads stop and the content begins. Having sat in ad industry self regulation meetings myself I know the author is completely right, they will never do anything about any of the many many problems, so what else is there to do than ban it, nothing else is going to work with the system that currently exists.
I think that's a bad misreading of the article, and life in general. When the author is saying "better" he's talking about the whole makeup of a person, not just a single advanced skill. Being amazing at maths is extremely useful, but it can be quite a narrow area of expertise, and I would imagine the author wants his child to be a good person, not a hyperfocused maths machine with no social skills. The children's achievements are combination or talent, effort and nurture that other children may not have, it doesn't make other children lesser, and they will have talents of their own.
They can be good at math and still have social skills.
All else being equal knowing advance mathematics and having the ability to think through a problem critically and analyze your mistakes is huge benefit and makes you objectively better functional than your peers.
Of course just like everything there are trade offs - like the time your kid spends doing math they wont be running track - and that is fine.
It makes you better at math. That's it. Which means you can function better in environments that rely heavily on advanced math, sure.
It does not, however, make you "better" than other people.
As for "better functional", many of my classmates from university (math majors) were absolutely brilliant at math, and could barely exist in normal life. And they were cognizant of that - brilliant folks are usually aware that they're brilliant along a specific axis, it's the B tier of almost brilliant folks that needs to harp on about how special they are.
>It makes you better at math (...) [w]hich means you can function better in environments that rely heavily on advanced math
Except is also makes you better at basic math, which means you don't get fooled as easily with advertisement dark patterns.
It also makes you better at problem solving and logic, which are very generalizable skills that can have profound effect on your life regardless of other circumstances.
This all enables you to better function in society, making better decisions, and just understanding how the world works.
+1 for this, I may end up buying this anyway but aside from the piano I have a Arturia Keystep Pro hooked up to a few synths that can sequence 4 channels, would be amazing to have this work with that setup and record all the midi channels and be able to select the channels in the app.
This isn't an article for computer scientists, and I think he covers this pretty well:
"While Levy calls him a “world-class computer scientist who has authored definitive texts in the field,” he also describes Raghavan as “choosing a management track,” which definitely tracks with everything I’ve found about him."
"Despite his history as a true computer scientist with actual academic credentials, Raghavan chose to bulldoze actual workers and replace them with toadies that would make Google more profitable and less useful to the world at large."
I'm kind of disappointed, Apple make such a big thing of being green but keep making machines that aren't upgradeable in these tiny form factors. I was really hoping for a more affordable Mac Pro with easily accessible memory/ram and some expansion slots.
I don't understand why people are holding JS to a higher standard than other languages, is it just because it used to be easier?
Knowing nothing about Java, I wouldn't expect to open a Java file and know what every line means. There's a million reasons to find modern web dev complicated but not taking the time to google "js import" is not one of them. Also I wouldn't expect to "just know" how to take a Java program and build it in a way that I could host it somewhere, I'd expect to have to work at it.
I think it's more that depending on your point in time, build process and environment, `import` has changed meaning every couple of years.
I consider myself having deeper knowledge about JS and node than any other language, having spent more total time in it than anything else (except maybe bash).
I have a clearer understanding of what import/require really does in most other languages.
The flow-chart complexity and possible outcomes of what `import` really does in JS/TS are certainly greater than anything else I've encountered.
(I do find go's repository-based approach quite frustrating to work with when forking dependencies but at least it's straight-forward)
I still find the whole gopath/gomodules thing unfortunate but it is what it is at this point (and frankly that’s a bit out scope since we’re talking imports here.. if we’re talking about the state of packaging then JS absolutely has competition; e.g. https://xkcd.com/1987/)
On top of this, a lot of the tooling is just shit. I don't just mean it makes design decisions I disagree with (which is also true of e.g. Maven, or Bundler) or that they're lacking in niceties (e.g. every C development workflow), I mean it's just absolutely poorly implemented CADT-except-they're-actually-25-and-overcapitalized trash.
Yarn blew NPM away on speed with more features and nicer developer workflow. Webpack is on major version 5 and still everyone just uses CRA rather than try to configure it by hand, but then nobody really knows how to debug CRA if something breaks. The entire babel stack is ridiculous. The dominant tools have just been so awful, for so long.
> Yarn blew NPM away on speed with more features and nicer developer workflow.
I dunno if it's still true, but for years into people saying "LOL use yarn, it's a better replacement for NPM" it was still really easy to find packages that broke under Yarn because it lacked some feature or other, or was skipping some obviously-a-good-idea sanity check that NPM did and so crashed rather than proceeding after adjusting its approach, or to venture slightly off the happy path of doing "yarn install" and running into features that yarn didn't support, but NPM did. A venture into the issue tracker in that time period was enlightening, and I don't just mean the sheer count, but digging into some of the issues and why they were happening.
[EDIT] in fact, in the agency I was at at the time, a kind of joke developed that a project wasn't fully underway until you'd been forced to replace Yarn with NPM.
> Within the actual language, there isn't a universal syntax just to use a package.
There is. The issue is one of mindset. You recognize Maven and Gradle as belonging to a sort of "parastandard" set of technology, offering proprietary (albeit free/open source) glimpses of how one could conceivably solve the set of problems that they're meant to be used for, but when it comes to JS, you're elevating the parastandard stuff to the level of being part of "JS".
Neither CommonJS nor NodeJS's `require` nor package.json nor TypeScript nor esbuild are part of JS. You shouldn't give them any privileged status that you aren't willing to give to Maven or Gradle when you think of Java.
I think you're misunderstanding what I'm saying. You're still talking about package managers and build systems. I'm talking only about syntax. TypeScript, NPM, esbuild, Gradle, and Maven are completely separate from what I'm talking about.
I'm not misunderstanding. (The difference between parastandard tech like package managers vs base-level stuff in e.g. the language itself was actually the point of my message, so I understand the distinction.) You're saying that unlike Java, JS at the language level doesn't have imports, but what you're saying is untrue.
It's entirely possible that the projects you're most familiar with aren't using them, but the JavaScript language has native modules, including standardized syntax and semantics for import statements.
Yes, I know JavaScript has native modules at the language level, but they are not universally supported.
Most importantly, there can't/won't be a breaking change for the previous iterations of module import, so we will continue to have many different ways to import.
It's not an issue of whether JS has a "blessed" way of doing it (and it didn't even have that for a long time). It's that there's more than 3 ways to do it, and many of them look similar and have confusing conflicts with compilers/packagers.
Yes, imports in JS are very frustrating. A big part of it is that your imports might be interpreted in, say, four different environments, and you have to consider how those four different environments work, how they can be configured, and pick some way of importing your packages that works in all four.
The four environments I often end up with are: Browser, Node.js, Rollup.js, and TypeScript.
For example, for a long time now, it has been sensible to just use "import" statements in code you intend to run in the browser. For a debug build, you don’t have to bundle, since browsers support import, but the imports have to be relative and have the full pathname. Node.js has a configuration option that allows you to use "import", but it is finicky and it can be surprising how many things will break when you turn it on—the alternative is to use ".mjs" as an extension. TypeScript has specific requirements about file extensions as well, and does not modify them. Finally, Rollup.js is hopelessly configurable.
Consider a simple requirement, “This code runs in the browser, I want to write a test using Jest.” I know it can be done, but I’m spending a bunch of time digging through forum posts to make it work, and understand how to make Jest load the code that already runs in the Browser, because the Node.js environment is so different… and most of the time, I end up writing code just to get something to build.
So the more than 3 ways, off the top of my head:
- Import paths: non-relative? relative? relative with leading slash?
- Import paths: .js suffix? no .js suffix?
- Files: use .mjs / .js suffix? use .js / .cjs suffix?
You wrote, "I was talking about import in JavaScript itself, not build tools or package managers," and keep mentioning things like "the import syntax of the language", so this feels like retconning.
The confounding details you bring up are entirely the result of that idiosyncratic tooling. JS itself has `import`, thus there is no problem of the sort that you describe—at least not as you've described it. (I.e., this isn't to say that there are no problems, only that the way that your characterization of the problem as being one with "JS itself" doesn't match the problem that actually exists.)
To say it again, if you see a problem with JS, that's because you're elevating the parastandard stuff to a higher level than it deserves. If you're able to meaningfully separate "Java" from "Maven and Gradle" in your mind, then you should be able to do the same with "JS" and the NodeJS derpitude.
Maven and Gradle have been around for years, and they are pretty much understood.
Moreover, you can skip them entirely and roll your own in a couple of hours [1]
Meanwhile in JS world? Build tools now change faster than frameworks, and not a single person is concerned with upgrade paths, or working in tandem with other tools.
After struggling to comprehend JS import and modules as much as I did as a single dev, I concluded that it’s my fault - that there’s something wrong with me.
I had to read the MDN guides multiple times and still need to refer to them.
Setting the build system part for my new projects is still the most challenging task.
Why do I have to learn how to build a grand piano every time I want to play a simple melody?
require ‘thing’ in Ruby requires the thing and that’s it.
require in JS should be use i. Node but not in the browser if I remember? Or maybe not? I don’t know, I guess I’ll just try things y til it works.
Python's packaging infrastructure is a mess, but the even the _environment_ surrounding import, let alone the module semantics, largely hasn't changed since the introduction of venv.
For all the other failings of the Python 3 migration, the Python community strongly and rightly rejected 2to3 which would've eventually produced a babelesque mess if continued.
It's holding JavaScript to its own higher standard: <script src="..."></script> is dead simple, and trivial to understand and get working.
NPM, import, etc. seem mindbogglingly complex in comparison, with an enormous number of ways to do each thing, most of which require at least one build step <script> just doesn't, and enormous numbers of third party dependencies, and if you go away for a few months and come back, there are good odds things will be different and broken.
Like Julia, I don't understand JS build systems and packaging etc., which no doubt contributes to the above experience, but I'm comparing to <script>, whose simplicity is almost unbeatable.
> It's holding JavaScript to its own higher standard: <script src="..."></script> is dead simple, and trivial to understand and get working.
The most simple example is almost never a representative example that can be used as a standard to hold the whole language to.
In the same vein, one could say: "See how easy it is to build a C program with `gcc main.c`? Why should I have to figure out how to use make?". And the answer is simple: Most projects that go beyond a toy example have much more elaborate requirements(/whishes), like "I'd like to reuse code that another person has written in the past so I don't have to do it".
C also lacks a sane build system, so if you’re trying to make the point that JS isn’t so bad, comparing it with C isn’t the way to go. Consider that no other language needs a bundler with all of the weird stuff it supports. You might argue that it’s good that JS supports all of these things and that’s fine, but
what you’re really saying is complexity is good which is also fine but incompatible with the “JS is no more complex than other languages” position.
Most languages also don't really have to worry about shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over that doesn't actually support the code you wrote (There are still people running old IE versions and loosing 1% of customers might be really costly at scale). I'm not saying that the current ecosystem isn't an overly complex mess but it does actually solve some problems.
I empathize with the unique difficulties of the web and I don't doubt that the complexity solves for real problems (e.g., old IE versions); however, I take issue with treating all problems as equal irrespective of how niche those problems are. The C and C++ folks make the same kind of argument to justify their abusive build systems--if the build systems made sane assumptions, then it would exclude certain niche use cases. Of course, we all agree that sane tooling excludes niche use cases, but we disagree about whether excluding ~1% of use cases for a dramatically improved experience for the ~99% is worthwhile (and we may even disagree about some of the qualifiers I used in this sentence).
Webpack sure has problems (for example speed) but most of the more niche things that people do aren't actually supported by it but implemented through the plugin system, at which point any category of niche/sane kind of flies out of the window. If you enable people to do weird things people will do weird and maybe unwise things.
The best solution might be to take notes of how people tend to develop js stuff nowadays, scrap javascript completely and use something completely new that doesn't have the issues of javascript. But that seems rather unrealistic at this point.
There is no problem JS transpilers+bundlers tackled that earlier compiler writers had not tackled, better, before.
> shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over that doesn't actually support the code you wrote
What does "plaintext source code" or "over the wire" do to distinguish this from "compiling a binary targeting a minimum supported ABI"? Bundled JavaScript doesn't even have to deal with dynamic linking!
> There is no problem JS transpilers+bundlers tackled that earlier compiler writers had not tackled, better, before.
I'm not sure what I am supposed to do with that statement/answer? It's obviously very easy to just assume that every js developer must be an idiot but that is hardly a fruitful discussion to have.
> What does "plaintext source code" or "over the wire" do to distinguish this from "compiling a binary targeting a minimum supported ABI"? Bundled JavaScript doesn't even have to deal with dynamic linking!
Correct me if I'm wrong on that but it doesn't really matter if something is written in Go, Rust 2015, Rust 2018, Rust 2021, Zig, D or whatever else comes to mind, assuming static linking of course. I can compile it, I can ship it and the binary will work. I can't just ship typescript out, browsers don't understand it. I can't just ship modern js out as I have no idea if the users browser understands the code.
Bundled javascript doesn't have to deal with dynamic linking because it is, in essence, static linking. The whole dynamic linking thing was sort of tried with CDNs shipping js libraries, didn't really work out all that well in practice, relying on some different service to be available for your dependencies is only a good idea until that service has downtime.
In this scenario, the binary is your ES3 or ES5 or what have you.
Compiling Go to an x86 ABI, Rust to the same x86 ABI, C to the same x86 ABI, etc. is an analogous problem to "shipping dozens of plaintext source code files over the wire that then might get executed in an environment you have no control over". It's harder, by order of magnitude and on every axis, than compiling TS, ES2015, whatever, all down to some lesser ES version. And yet these compilers are faster, more effective, and easier to use.
You've missed my point about static vs. dynamic linking entirely. The point is that C compilers did "bundling" for years while supporting dynamic linking, and now you're trying to say JavaScript is tackling some way more difficult problem when it has a much simpler language-to-"ABI" translation process and doesn't even need to support that?
As you say, this maybe isn't a fruitful discussion - but it's a true one. JS tooling developers got seriously deluded about the novelty of their problems and quality of solution at some point ca. 2014, and we will be dealing with the results for another decade or more. At the very least let's start being honest about it.
I tend to agree with the overall thrust of your argument and the conclusion you're driving toward, but it's at least interesting to note that the distribution model of the web puts unique pressure on tools to ship dramatically smaller payloads. In Go or Rust, we ship debug symbols in production builds by default (or whatever it is which give us stack traces on panic), but in JS sourcemaps typically aren't shipped in production builds because they are too bulky. Similarly, there are a litany of caching concerns which apply in the browser world but not natively.
I also think that invoking "C compilers did X" weakens your argument because the C build ecosystem is quite a lot worse than the JS ecosystem and without any good excuses (its ecosystem is not rapidly evolving, there is no distribution model putting comparable pressure on latency, etc).
But in general, I agree that there is a lot the JS world could learn from the native world.
> the C build ecosystem is quite a lot worse than the JS ecosystem
Other than module packaging (and that's admittedly a big "other than"), I don't agree. Esbuild is the first tool I used that's even close to e.g. Make in comprehensibility (~ ease of use x flexibility x ability to debug when something goes wrong). That's a pretty low bar, and I don't know how long esbuild will stay that way.
Agree to disagree I guess. I don't want to go to bat for JS, but I've done more than my share of C and C++ and Make, CMake, Autotools, etc are just fucking nuts, and that's ignoring the fact that they completely punt on package management. JS is painful by the standards of modern programming languages, but C and C++ are on the next level.
"Stockholm Syndrome" is the only way I can rationalize people vouching for C or C++ (or JS, to a significantly-lesser-but-still-not-negligible extent) build tooling.
I'm not trying to argue that it is harder, just different in some ways and ignoring that for the sake of "javascript bad" isn' going to change the point that there are challenges involved. Nevertheless I understand your pint a lot better now, thanks for the explanation.
I think we are both on the same page that the JS ecosystem overall is not in a good shape. But, you know, maybe THIS wave of new shiny tools is finally solving the issues once and for all (not holding my breath though...)
I do, but it's not well supported by a lot of packages. I dig around manually for URLs on unpkg and other JS CDNs, but most libraries' instructions just say "run npm ... or yarn ...". Maybe that complexity's worth it, but understanding what's going on is a barrier for me to use it, just like Julia describes.
I'm very sympathetic to Julia's confusion and your yarn/npm frustration. But consider whether those libraries themselves might also be part of the complexity that are not worth the cost. Julia's trying to use Vue. Vue (and Webpack, and Babel, and the entirety of NPM) nominally exists because it's supposed to improve the developer experience. If instead it contributes negatively in other ways and you have to spend so much time wading through the tangled mess that it confronts you with, what's the point?
Ignoring the nullified value proposition, there are other reasons besides (like security) to reject what the NodeJS/NPM world considers standard practice.
I mainly use big standalone ones that provide enough to be worth it, and far more than I'd build myself. Things like MathJax, JSXGraph, Plotly, and D3 when I properly learn it. Not coincidentally, those aren't too hard to use without NPM.
I feel like JS gets thrown under the bus in discussions, but no body talks about arcane file structures in Java or implicit pathing lookups which have the same kind of "historical path dependence" to why they exist as JS has for require/import.
All languages have their warts and 99% of the time they're all doing the same thing just in slightly different ways.
CTO and lead developer on a focused project are very different jobs - my guess would be he relaxes from the very strategy and soft-skill heavy day job by diving into a challenging problem that keeps his dev chops up and lets him focus on a finite problem.
No idea on Evan Wallace's perspective but there is a possibility that it isn't seen as work. It would like be me solving sudoku or some of my friends building LEGOs or solving extremely hard jigzaw puzzles
This looks really great, something I could use and would pay for when polished but there's definitely a few issues for me at the moment:
* Why go fullscreen and modal? I want to drag in links from docs, email, other browsers, have it side by side while reading PDFs etc. etc. this stops me from doing any of that
* Please let me change the shortcut! I already have Option-Space bound.
* Let me put the browser window anywhere I want when it's in the single page non-fullscreen mode, don't levitate it to where you think I want it
* Unless I'm missing something the process of opening a page then adding it to a workspace seems to be three clicks - open page, hit + (plus) button, select workspace, select workspace/inbox - need to make this one click, maybe just show the inboxes? This also seems clunky, I'd much rather browse, drag that page to the workspace/inbox, continue browsing and adding further pages, then arrange all the pages in the workspace after i've added all the links. Seems a faster workflow.
I agree with everything, except that this is something that can be polished into sth. usable. After trying Bonsai, I think it's a promising proof of concept that demonstrates what should now be implemented properly. A ‘quick’ hack on top of Electron is just really slow and clunky compared to a ‘real’ browser.
I know this is asking a lot, but as an end user with an unlimited budget for big dreams, I'd like to see something like this as a fork of Firefox that eventually gets enough of its changes upstreamed so it can become just an extension for the browser I'm already running anyway.
Anyway, a little addendum:
> Why go fullscreen and modal?
And for when I want it full-screen and modal, at least do it right, please. E.g. it shows up in the cmd-tab task switcher, but that can't actually be used to switch to Bonsai, nor away from it (!!). And, again, it's too slow. (What's with the dramatic fade-out animation?)
Btw., you can drag a link on top of it (at least when option-space doesn't do something else already ;) and the cursor changes to identify a valid drop target, but when you drop, nothing happens.
