111–120 of 229 posts
Earlier quoted context omitted.
As the "webpack" guy on my team, these numbers look extremely compelling, but I also know Webpack does a lot for us (e.g., through Webpack v4, it includes browserfied node libs as needed). Beyond node libs, there's a long tail of niche things that need to be taken of... am I trading coverage of that long tail for speed?
You still need webpack for production build :). So all is good.
I wonder why all these new bundlers don't provide a webpack-compatible API to entice new users. I can't take the risk of investing in a new tool only to find that I can't migrate the last 20% key features that I need. I also don't have the bandwidth to constantly switch between vite, webpack, parcel, etc. every time I switch to a different project.
I wonder why all these new bundlers don't provide a webpack-compatible API to entice new users. I can't take the risk of investing in a new tool only to find that I can't migrate the last 20% key features that I need. I also don't have the bandwidth to constantly switch between vite, webpack, parcel, etc. every time I switch to a different project.
So, ultimately I think the answer is to say, "No, solve my problem, not yours."
Earlier quoted context omitted.
> Any time you lose waiting for webpack to run you will get back 10x over by not fighting with your tooling because it doesn't handle a set of use cases you have. Generally I think this is good advice for tools--stick with the mature thing. But my former company's webpack builds were 30+ minutes for a relatively simple site. No doubt something was misconfigured, but you really have to be a webpack expert to get any s…
> my former company's webpack builds were 30+ minutes for a relatively simple site I’m genuinely curious what simple site would cause a 30+ minute build? Is it just one of those things that grow over time?
Earlier quoted context omitted.
Why is that funny? How is it conceptually different from any of the variety of scripting languages that call out to C bindings or binaries?
It’s funny because in order to compile/minify JS it passes said JS to golang which spits out JS to be run under JS. I’m not allowed to be amused by the circularity? Get a grip.
(p.s. JS is not compiled)
Earlier quoted context omitted.
Hate to break it to you but Clojurescript, Elm and the whole paradigm of "compile to JS" languages are part of what is broken about the javascript ecosystem. So much unnecessary complexity and energy wasted making javascript pretend to be something it isn't and to make it do things it was never meant to do, pressing a small, simple and powerful scripting language into the service of the profane eldritch abomination t…
I dunno, I feel that’s like saying that Lisp and Haskell are part of what’s broken about the machine code ecosystem. ClojureScript and Elm aren’t compile-to-JS languages for the sake of doing something weird, there’s just literally nothing else that will run in a browser (except wasm but probably best not to get into that). Different programming languages exist for a multitude of valid reasons, the compiled output is…
It would be if machine code were another high-level text-based language completely unrelated to either Lisp or Haskell with its own semantics, execution model and type system rather than a more directly machine-readable format of those languages themselves.
Javascript is fundamentally different enough from a bytecode for any arbitrary language that, at least to me the distinction matters. I can accept that it works well enough that most people don't care, even though I suspect most of the use cases for doing so (error checking, type checking) could be better served with linters or editor tools for JS itself.
But the decision to avoid actually writing javascript at all costs has contributed a great deal of complexity in the JS ecosystem, which translates into the bloat in the web that everyone complains about, because all of that javascript is wasting time and cycles simulating other languages.
Earlier quoted context omitted.
>Super excited about the future of JavaScript tooling ecosystem with more focus on efficiency and speed. Well they can't get worse than now... 234mb for a friggin hello world app
Would you count the size of the JVM when you do Hello World in Java?
Webdev truly is one of a kind. Not only do you have your source code, you also have your build code, oddly dictating the organization of your source code. For extra fun, some libraries don't build with build system a, others require build system b, when you're lucky enough to have a working mix, changing build systems is better to be avoided. Of course periodically the officially blessed build system for your used li…
I see you have never worked on a C/C++ project.
Earlier quoted context omitted.
It’s funny because in order to compile/minify JS it passes said JS to golang which spits out JS to be run under JS. I’m not allowed to be amused by the circularity? Get a grip.
Python is a C core that takes Python code and spits out bytecode to interpret and run said Python. What esbuild is doing is not much different than any other interpreted language. (p.s. JS is not compiled)
(p.s. I'm aware)