161–170 of 187 posts
All those extraneous elements to Javascript are a real turn-off. Python: batteries mostly included. Javascript: feels like you need to drag a dozen suitcases along anytime you embark on any non-trivial project.
Be mindful of your blindspots.
So much this. I using Preact and still have to manually fish out files from build folders in Git repos just to have a usable library to import directly, because somehow “npm install” became the status quo.
I've used `tsc --watch` as an almost-no-build-step way to write plain TypeScript with better structure (separate files, etc) for projects where dependencies aren't necessary, which works reasonably well with a few quirks, but I wish there were something more purpose-built for the task. TypeScript running natively in the browser would be amazing but I doubt that'll ever happen.
I've used `tsc --watch` as an almost-no-build-step way to write plain TypeScript with better structure (separate files, etc) for projects where dependencies aren't necessary, which works reasonably well with a few quirks, but I wish there were something more purpose-built for the task. TypeScript running natively in the browser would be amazing but I doubt that'll ever happen.
The problem with build systems isn't the existence of a build step but the necessity of the build system and its configuration. Typescript is baffling-ly complex to use compared to something like python.
I did a talk about the topic of no build web apps recently. The slides are here for anyone interested: https://1drv.ms/p/s!ArEoTVF2ayv3lJg4oECZk2h5eN3I3Q
In preparation for that talk I’ve also adapted create react app’s default project into a no build template, including a variant with routing. That can be found in github: https://github.com/jsebrech/create-react-app-zero
If anyone's looking for something like a framework that works with buildless workflows you might check out the project I work on: Lit ( https://lit.dev ) Lit gives you reactive components, declarative HTML templates, runtime encapsulated DOM and styles, interoperability with frameworks and HTML via web components, and a lot more - with no required build tools at all. We take great care to make sure our libraries are…
We started using it because we knew it could be embedded into any other framework, we are using two others in the company. But are starting to use it for SPA also. Glad to see it growing quickly.
Thinking about possibly reworking our SPA to use Phoenix LiveView most of the abstractions are there already.
Earlier quoted context omitted.
Huh… in Python I feel like the tooling is largely missing.
While the Python ecosystem trends towards a similar state as the JS ecosystem, at least no one yet needs to have any ideas about "tree shaking" and hype that as some kind of "new idea". When one needs to "shake out" code, because it has become too much, one should really think about not getting that code in there in the first place. In the Python ecosystem some of the tooling does not exist, because it is not needed.…
I agree with your sentiment entirely about "When [...] it has become too much, one should really think about not getting that code in there in the first place," but that's really a problem with the NPM community in particular—not something that people who aren't NPM programmers can do anything about (and who, as people who work with JS, are even more annoyed by it than people hailing from communities that use other languages).
> Mind, it is 2023 and we still have no good way to tell the TypeScript compiler to simply spit out JavaScript code, that can immediately be served on a website
I guess it's actually necessary to point out the obvious here: TypeScript is not JS. The fact that TypeScript superficially resembles JS does not make the sins of the TypeScript team JS's responsibility. You could swap "TypeScript" for, say, FartTwist, an imaginary programming language that I just made up and doesn't resemble JS (or anything else that transpiles to JS with tools that have the same problem the TypeScript ones have), and the criticism would be exactly as applicable.
The big problem with the JS ecosystem is that it's filled with people who clearly don't like programming in JS, and yet they advertise themselves as part of that milieu. In fact, enough of them have banded together that they've managed to almost completely commandeer JS's public image, to the point that when JS is mentioned what comes to mind are their shenanigans, inevitably leading to discussions like this one.
Earlier quoted context omitted.
While the Python ecosystem trends towards a similar state as the JS ecosystem, at least no one yet needs to have any ideas about "tree shaking" and hype that as some kind of "new idea". When one needs to "shake out" code, because it has become too much, one should really think about not getting that code in there in the first place. In the Python ecosystem some of the tooling does not exist, because it is not needed.…
python is rarely streamed across HTTP, I believe that's the reason js is treeshaked.
https://en.wikipedia.org/wiki/History_of_Python>
All those extraneous elements to Javascript are a real turn-off. Python: batteries mostly included. Javascript: feels like you need to drag a dozen suitcases along anytime you embark on any non-trivial project.
Frankly, if you're just writing a local CLI tool with Node, it's not really an issue. Most of the build tool features listed in the article aren't needed for a local JS runtime. Node is even getting a built-in testing framework, and Deno can run Typescript without an intermediate step! Build tools for JS solve problems that other languages don't have to worry about. You can't use Python (directly) in a browser which…
Explain that to all the people writing browser extensions which by their very nature have an entirely different set of relevant engineering concerns in contrast to Web apps delivered by HTTP—and yet the same minification tools and compatibility shims still abound for as far as the eye can see.
Earlier quoted context omitted.
> ... we're the only ones that fully work with plain JS Vue (v2, don't know about v3) can also work without a build script, either with a render function, or a "template" (an string that mixes HTML with expressions).
Correct. It's how I use it. I think that it no longer applies with V3.