1. 38
  1.  

  2. 4

    Anybody else thinks it’s a bit strange this is written in rust? also esbuild is written in go, I think. I mean.. should that not be kind of a red flag for javascript?

    1. 14

      I mean Lua is written in C. CPython is written in C. Ruby… the list goes on.

      I heavily embrace writing compilers and parsing tools in languages that can let you eke out performance and are probably better suited for the task!

      Javascript has loads of advantages, but “every attribute access is a hash table lookup (until the JIT maybe fixes it for you)” seems like a silly cost to pay if you can avoid it for the thing that you really really really want to be fast.

      Honestly I think the “write stuff in the language it is meant for” has cost so much dev time in the long term. It’s definitely valuable for prototyping and early versions, but for example templating language rendering not being written in tooling that tries to minimize allocations and other things means that everything is probably 3-5x slower than it could be. I get a bunch of hits on a blog post because people just search “pylint slow” in Google so much.

      Meanwhile we have gotten many languages that are somewhat ergonomic but performant (Rust, to some extend Go or Java as well. Modern C++, kinda?). Obviously Pylint being Python means recruiting contributors is “easier” in theory, but in practice there’s a certain kind of person who works on these tools in general, and they’re probably not too uncomfortable with using many langauges IMO.

      1. 8

        Could you elaborate why this is strange?

        1. 1

          to me it’s a bit strange that javascript is such an old language but it’s either not so optimized/fast enough for people use it to build/compile javascript, or people don’t want to use it even though they are building a build tool for it?

          1. 17

            Javascript has been going through a lot of optimizations, feature additions etc but it’s still a high level interpreted language. Compiling Javascript itself (or anything else) efficiently isn’t really among the primary goals of the language. I see no problem at opting for compiled languages optimized for performance for such a task. This does not diminish the language in my eyes because this is not what the language is designed for. Javascript may be terrible for a lot of reasons but this is not really a red flag for me.

            1. 7

              See Why is esbuild fast? for some fundamental JavaScript flaws for this kind of workload.

              1. 1

                Thanks for that, it’s interesting, though that was kind of my point.

              2. 4

                Age of the language doesn’t make it fast or slow, neither make it more or less optimised. Rust and Go will be faster than JS mostly, because these do not need to have support for many of the JS features, that make it hard to compile to native code - runtime reflection on anything for example.

            2. 8

              Producing code that executes quickly is just one of a large number of possible goals for a language. It is especially a goal for rust, but it’s not a priority for javascript.

              This is perfectly normal. Languages that do prioritise speed of execution of the produced code make other trade-offs that would not be palatable to javascript use cases. The fact that someone is writing a bundler for javascript in another language is more a sign of the value that javascript brings, even to people familiar with other technologies.

              1. 3

                JS is pretty fast when you stay on the optimal path, which is very tricky to do for anything bigger than a single hot loop. You usually need to depend on implementation details of JIT engines, and shape your code to their preference, which often results in convoluted code (e.g. hit a sweet spot of JIT’s inlining and code caching heuristics, avoid confusing escape analysis, don’t use objects that create GC pressure).

                OTOH Rust is compiled ahead of time, and its language constructs are explicitly designed to be low-level and optimize in a predictable way. You don’t fight heuristics of GC and JIT optimization tiers. It’s easy to use stack instead of the heap, control inlining, indirections, dynamic dispatch. There’s tooling to inspect compiled code, so you can have a definitive answer whether some code is efficient or not.

                Rust is a more fitting tool for high-performance parsing.

                1. 3

                  Is v8 being written in C++ a red flag too?

                  1. 1

                    Or SpiderMonkey in C, C++, and Rust

                  2. 1

                    Not really. Idiomatic JS code for this kind of workload will generate a lot of junk for the collector, and there’s also the matter of binding to various differing native APIs for file monitoring.

                  3. 3

                    I just tried Parcel 2 on one of my side projects already using Parcel 1 and it’s definitely an improvement. I tried it multiple times during the beta but couldn’t get it to work (issues with d3.js) so I’m glad they managed to fix it. The bundled js it produces is now half what it was before thanks to tree shaking.

                    What I love is that Parcel 2 allowed me to actually remove some of the (already almost non existant) config that I had with Parcel 1, and I finally got rid of Babel. So the zero config promise of Parcel 1 still stands with Parcel 2 !

                    1. 2

                      Anyone know how this compares with https://vitejs.dev?

                      1. 14

                        Parcel is older than Vite, it was developed before ES Modules were available in the browser. Parcel’s killer feature was to simplify (usually outright eradicate) the bundler configurations and let developers start building on top of a React / Vue / similar SPA frameworks right away. The setup tax you needed to pay before starting development on top of such frameworks was arguably the biggest problem of the bundlers at the time. (See “Webpack fatigue”) Thanks to its features Parcel is a great and simple alternative to tools such as CRA (Create React App).

                        Vite has a fundamental difference from other bundlers such as Browserify, Webpack, Rollup and Parcel in being a “native ESM based dev server”, while the others are categorized as “bundle based dev server”. (Ref) Please see the figures on the reference to note the architectural difference. But you have to also note that this applies only to development environments. They still recommend to make single bundles for production.

                        Even if this ESM based serving method only benefits the development cycle, it is still a big improvement. Quoting from the “problems” section of their docs:

                        We are starting to hit a performance bottleneck for JavaScript based tooling: it can often take an unreasonably long wait (sometimes up to minutes!) to spin up a dev server, and even with HMR, file edits can take a couple seconds to be reflected in the browser. The slow feedback loop can greatly affect developers’ productivity and happiness.

                        Indeed a faster feedback loop greatly benefits development. So I guess this is the killer feature of Vite. Offering devs much faster feedback loops by leveraging new tech such as esbuild and ES Modules.

                        But apparently Parcel v2 did some optimizations on that front as well. Quoting from their announcement:

                        Massive performance improvements, including a new JavaScript compiler written in Rust, and a more parallelized architecture that takes advantage of all of your CPU cores.

                        Whether their Rust based compiler can rival Vite’s underlying esbuild, we will see. Here are a couple of benchmarks published by Vite which includes Parcel v2 as well. Though I don’t know if the benchmarks are fair or not. Maybe somebody can enlighten us regarding that.

                      2. 1

                        So this says in the main page that it support script tags.

                        I for one, never really understood what exactly is so evolved that needs a whole “build tool” for what is essentially concatenating a bunch of sources. But I digress… If I add a script tag to my html file, what is left for these things to “build”? It already works as it is.

                        1. 7

                          If you don’t want to use NPM then there’s little reason to, but if you do then dependency resolution for the usual JS package managers is not compatible with how the browser wants it done.

                          Lots of folks also want some kind of transformation of their code, like typescript or JSX to JS or modern CSS or JS to something that old browsers can use.

                          If you’re writing a lot of JS or using a lot of dependencies then the code size can become significant, too. Tree-shaking and minimisation can help a lot there.

                          1. 3

                            These days these tools aren’t really the same as concatting a bunch of files together, they need to understand the modules’ structure, and the global graph in order to do “tree shaking” and prune unreferenced objects / methods / classes etc.

                            1. 1

                              Did you read the feature list? If you have and you see nothing in it you need, perhaps this post is not for you.

                              1. 1

                                Yes, I did. My question includes a feature from the list.

                                The feature list does claim that it works for html files with script tags. I was just asking for clarification on what it exactly does in that case.

                                It appears that nothing? What does “build” mean in the context of an HTML with a couple of script tags? I am not being sarcastic. I could not find answers to these questions in th website.

                                1. 3

                                  “Build” in this case means that you can take an HTML file like this:

                                  <script type="module" src="../js/index.js"></script>
                                  

                                  where index.js is:

                                  import { Application } from "stimulus";
                                  import FromSessionController from "./controllers/from_session_controller";
                                  ;; ...
                                  

                                  and Parcel will produce an HTML file:

                                  <script type="module" src="/static/index.1183aed8.js"></script>
                                  <script src="/static/index.d1d74906.js" nomodule="" defer></script>
                                  

                                  where Parcel has:

                                  1. Compiled any experimental features/syntax into JS that can run in todays browsers
                                  2. Combined all of the JavaScript files required by my app into a single file (index.1183aed8.js)
                                  3. Minified the JS

                                  It’s also created a slightly different version index.d1d74906.js for browsers that don’t support JavaScript modules.