> I just can't fathom doing anything large scale without access to real tools, real abstractions. I mean, in JS, abstraction means using separate JS files that

> I just can't fathom doing anything large scale without access to real tools, real abstractions. I mean, in JS, abstraction means using separate JS files that people actually believe represent real modules or something! Yeah, separate files are not actually abstractions. Separate directories doesn't mean that something is a module. I'm not sure what you mean by that, but ES6' module system is not markedly different in practice from, say, Python's. > Like, the idea of passing so much stuff around as strings or JSON 'objects'. Just use Typescript and enjoy strongly-typed everything. > Let's see, I need a graph. But instead of writing an actual graph that uses pointers and objects that are actually separate nodes, I'll use the DOM. It'll be like a tree, except it's made of text. I'll make a 'tree' of objects with the DOM. Or maybe I'll use JSON, which is also just text. I'll write some other tools that allow me to insert JS into these 'objects' so that I can modify them. Yeah, it won't be weird that I combine my data structures and my code, because I'll just use more JS to parse the file and then write another file that will actually be fed to the browser. Text transformation as application development is just totally batshit. Well, JS doesn't particularly force you to use the DOM as storage. A standard Redux + React solution has a store with a given data model, that is rendered in possibly completely different ways by its React view. > In fact, despite all the shiny new toys, the fact that text is used for just about everything makes it all seem like a huge technical debt factory. Again, Typescript (or Flow) is a solution to your problem, here. Basic JS is terrible, and I intend to never write a single line of it if I can help it, but strongly typed JS lets you get things done.