18 ms·

You don't need a build step

328 points by vancroft 4y ago

kldavis4 4y ago
My understanding of this is that this is trading a build step for just in time (JIT) compilation, which seems, ok? But it seems to me that you've just moved the problem around and I'm sure there are additional trade-offs (as with anything).
- dboreham 4y ago
  "Build" in JS circles usually means transpile, not a replacement for JIT which will still happen at runtime. In addition to that, often there are other concerns addressed at build time such as linting.
  - kldavis4 4y ago
    yeah, exactly. So I wonder if ultimately they want to have the browser handle transpiling things like typescript? And I definitely think there are other concerns (such as linting) that you want to happen as part of your development pipeline.
    - kamikaz1k 4y ago
      Browser doesn't transpile, and if you're transpiling in the browser in your own JS, you're doing it wrong...generally Point of transpiling is improving DX, so it has no business being done during users browser render.
      - kldavis4 4y ago
        Sorry - I miswrote that - I meant the browser directly compiling (JIT) typescript
    - whstl 4y ago
      There is an ES39 proposal to allow type annotations in Javascript, that would allow the browser to handle TS/Flow files without needing a compile step: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations (That's only to allow the type annotations to be there, not to have static checking in the browser) IMO: I would love to see this implemented. Linting and typechecking should be ran before committing code or deploying, but I want to be able to stop transpiling/bundling in all cases.
      - deckard1 4y ago
        that sounds needlessly wasteful. You can trivially strip TS out of JS before sending off to the client. You're still going to need to check TS in the build/CI step (i.e. the time consuming part) before doing anything so you've gained exactly nothing.
        whstl 4y ago
        "You can trivially strip TS out of JS before sending off to the client" To quote you, that sounds needlessly wasteful to me. Also I prefer not needing to deal with SourceMaps or different source when debugging. So it's quite the contrary: I gain a lot. Different strokes for different folks.
        moritzwarhier 4y ago
        I understand your reasoning but it seems to be focused more around developer time rather than bundle size and user experience if I am not mistaken. The ratio between built code size and source size can easily reach orders of magnitude in TypeScript projects with exhaustive types. Sending all that code to the user is wasteful, and this wastefulness is multiplied by X end users, as opposed to the development process which is centralized. From a money perspective the picture is different of course. I would still love to be able to execute TS directly in the browser, but this is purely a DX thing.
        deleted 4y ago
        [deleted]
    - temp_account_32 4y ago
      I feel like this is what everyone actually wants. Typescript in the browser (at least for me personally) would be awesome, and if they made TS into a separate language with its own runtime, that would be like the holy grail.
  - deleted 4y ago
    [deleted]
msoad 4y ago
> And to be make your Fresh app more performant, all client-side JavaScript/TypeScript is cached after the first request for fast subsequent retrievals. My understanding is that the client side JS is a result of backend compilation. How does this work if the backend is dynamically generating those JS files? `getPosts()` can return a different JSX based on what `getPosts()` returns. No?
- brundolf 4y ago
  (At least in React) the JSX gets transpiled to function calls, which are then run at render time with a particular set of data. That first transpilation step will always come out the same and can be cached.
dom96 4y ago
I tend to stick with script tags as much as I can. Really the problem are all the frameworks pushing people to create a build step. Their excuse is optimising the code size, but for most cases that matters little, I don't mind including all of tailwind or font-awesome. So please, if you own a framework like this, make sure a script tag with a CDN link is easily copyable.
- djbusby 4y ago
  How can you get all of tailwind? I've been struggling on that one, always have to run some tool to get a built CSS file. And any change then needs build before refresh. And I cant look at a file with 1000s of definition (which I want to do)
  - gremlinsinc 4y ago
    i think if you use tailwind, not to use the actual package loses a lot of what it can do, I don't think you get all the features/functions for ..um only delivering the parts required (having mind fog this morning lol)... I'm not sure if it's tree-shaking, but how they look at every file w/ tailwind in and only bundle up the needed css. However, maybe it works in deno? I don't know.
- hbn 4y ago
  Are you talking about the CDN version of Tailwind? If so, the docs specifically say that's not for production use. A lot of very useful features require a build step because it generates classes on the fly based off what you typed in the HTML.
  - dom96 4y ago
    I bet you lots of people are ignoring the "don't use this in prod" advice. Why doesn't Tailwind just offer a for-production CDN link? I understand that the build step provides features, but what if I don't care about those features?
    - 4y ago
ChicagoDave 4y ago
Pretty sure we were building code to validate it and unit test it before releasing it. This article is strictly about JavaScript. What about all the server-side rendering frameworks? Huge assumption that everything is built one way.
- deleted 4y ago
  [deleted]
vhiremath4 4y ago
The decoupling of URLs that host your dependencies and the URLs that host your application feels like an important uptime measure currently. If the URLs that host your dependencies go down in an NPM world, you can't build and deploy new code but your app is still up. It seems, if the URLs that host your dependencies go down in a Deno world, your app goes down if those dependencies have not yet been cached (even on the server). Am I missing something? This might not be terrible if it becomes the standard to host your own mirror internally.
- DotaFan 4y ago
  On Android we do the same with help of Gradle. It retrieves library from a remote source and caches it. If there is no cache, next time your Gradle tries to build, it will download the library from a remote source. If remote host fails, you can not build your app. One of popular host providers had issues couple of times in last year, and it wasn't nice. https://github.com/jitpack/jitpack.io/issues?q=is%3Aissue+sort%3Acomments-desc+is%3Aclosed https://github.com/jitpack/jitpack.io/issues?q=is%3Aissue+so...
- gremlinsinc 4y ago
  Deno should have like a mirrors.manifest.js file that stores your dependency links, and mirrors, should one source go down... that way it wouldn't be such a problem, the only big issue might be ensuring the sources don't have a rogue link or two from bad actors, where they do something nefarious like build a useful package then swap it out for a bad version later on, and put only on a mirror so when things go south it triggers, of course there could be bots/queues that periodically take md5s of the code, or just whenever version changes occur, so that would stop that.
  - crdrost 4y ago
    This exists and is part of the deno executable; see [1] for more info. 1. https://deno.land/manual@v1.31.1/tools/vendor https://deno.land/manual@v1.31.1/tools/vendor
  - qbasic_forever 4y ago
    Deno puts a hash of the dependency contents in a lock file so it can ensure the contents of a dependency haven't been changed unexpectedly: https://deno.land/manual@v1.29.2/basics/modules/integrity_checking https://deno.land/manual@v1.29.2/basics/modules/integrity_ch...
franciscop 4y ago
So basically Deno has its own bundler that lets you not have a local build step and it gets bundled dynamically per-route as requested by users, right? This is very different from industry standards and possibly has many new concerns from devs, none of which are addressed in the article since it's treating the system as a perfect solution, which makes sense since it's a marketing page ("content marketing"). If it was a 3rd party article, I'd be interested in things like: - How do you measure bundle size and make sure it remains small? (e.g. make sure that a PR doesn't accidentally import a massive dependency) - How do you measure bundling speed/performance, does it add significant time to the first request? To subsequent requests? Is it linear, exponential, etc. with the number of LOC? Again like in the previous point, how do we make sure there are no regressions here? - How does this work, well, with absolutely anything else? If I want my front-end in React? Vue? etc.
- mattlondon 4y ago
  From the article: "Fresh renders each page on the fly and sends only HTML" So the bundle size is zero.
  - kamikaz1k 4y ago
    Fresh supports islands, so it also does send JavaScript for the interactive bits. If you have a react (default is preact) island then that'll be bundled and sent down.
  - IncRnd 4y ago
    > unless an Island is involved, then only the needed amount of JavaScript will be sent as well It's not just HTML but also JS that gets sent.
- deleted 4y ago
  [deleted]
- brundolf 4y ago
  It sounds like (it is a little vague) there is no bundling at all, the only thing Deno does magically at request time is transpiling TypeScript/JSX to browser-compatible JS. Beyond that I think the idea is it relies on native ES module imports (and import-maps), both of which are browser standards
pictur 4y ago
Deno didn't have a structure that caught my attention in its early stages. But now i see it going in the direction i need logically. I guess I need to start experimenting with a side project.
groestl 4y ago
[flagged]
- pictur 4y ago
  I think that the absence of a compilation phase does not prevent the establishment of infrastructure for e2e testing. If you can only be sure that the application is running when the build is successful, then there are probably other big problems there.
- whstl 4y ago
  No, they don't have to. Deno supports Typescript. And Typescript supports Typechecking without a build process. Linters, tests and other tools can also be run without a build process.
  - groestl 4y ago
    What exactly is "a build process" for you. For me, it is a process which results in an artifact. An artifact that is, in the best case, automatically tested, optimized, signed, and ready to be deployed. Compilation is a rather small part of it. But since I need to run all the other things anyway, why not compile there, and remove entropy from runtime.
    - jamesgeck0 4y ago
      "build process" is defined in detail in TFA. You're arguing about something so entirely orthogonal to the point of the article that I can't help but wonder if you've actually read it.
      - groestl 4y ago
        I did read it, and I find the title misleading.
    - deleted 4y ago
      [deleted]
codemonkey-zeta 4y ago
So Deno is relying on native ESM imports in production code? Isn't that exactly what Vite _doesn't_ do, because of poor performance? When you run the vite dev server it uses ESM, but when you build it uses rollup, because serving ESM is slow and with larger apps the client browser is going to make a bazillion requests. Wouldn't you rather traverse the dependency graph one time and bundle your code into modules so that everyone who visits your site doesn't force their browser to do it over and over again? Sure those dependencies will be cached between views or refreshes, but the first load will be slow as shit, then you still need to "code-split", just now you're calling it "islands".
- silviot 4y ago
  Deno is an alternative to node and npm. You can have a Deno http server serving content to a browser. But the browser won't care how the server runs, as long as it can speak HTTP. You can also use Deno to run your bundling tools, but again, what happens in Deno stays in Deno and does not reach the browser.
- TheRealPomax 4y ago
  That sounds like an assumption that's not actually been tested recently. Downloading a 2MB bundle or 100 separate files is an equally poor experience, but the separate files at least let you download only the parts that changed over time, instead of having to download a completely new 2MB bundle every time someone changes a single letter in one of 100+ files and a new bundle with a new integrity digest gets rolled out. I'd rather have an equally slow experience on first load, and then much better performance forever, compared to having something that constantly invalidates the entire cache.
  - cjblomqvist 4y ago
    I'm not sure what recent means, but I'm fairly sure (sorry, no references - only from memory) that it's been tested quite a lot, and also relatively recently (1-2 years?) by Evan (the guy behind Vite). Even with newer versions of http just transferring lots of small files is noticeably slower (few percent if I remember correctly).
xiphias2 4y ago
I thought this will be an article about adding import maps to deno, which would be great. I hope builders start adding it (at least to dev instances) to decrease the magic. I was trying to use import maps, but it's not trivial go create actually. There are always problems with Node lagging behind browsers though that makes developing hard (no WebSocket support by default for example, crypto module is also not included)
- eyelidlessness 4y ago
  Deno does support import maps out of the box. For Node there’s a loader[1] you can use (though a glance at the GitHub issues suggests it’s incomplete). 1: https://www.npmjs.com/package/@node-loader/import-maps https://www.npmjs.com/package/@node-loader/import-maps
  - xiphias2 4y ago
    Does it generate import maps for me automatically? That's the hard part. I'm using Vite with Sveltekit, which is great because it compiles files separately, but still doesn't generate import maps, but uses imports with relative and absolute filenames.
    - eyelidlessness 4y ago
      I don’t use Svelte of any kind so I’m possibly out of my depth, but I don’t know what I’d want to automate with import maps. I don’t think Deno addresses any use case like that but I’m hesitant to say so because I really don’t know what need I’m even addressing.
mattwad 4y ago
So, if I'm using URLs for dependencies, effectively I can't code while I'm offline? I know it's not the norm, but there have been plenty of times I needed to work without internet.
- schemescape 4y ago
  I’m fairly certain Deno caches the downloaded artifacts locally. There’s also tooling for downloading all dependencies: https://deno.land/manual@v1.29.1/tools/vendor https://deno.land/manual@v1.29.1/tools/vendor
- whstl 4y ago
  No. Deno supports vendoring, caching and locking of dependencies just like other ecosystem. They are not fetched every time you run the app.
jesse__ 4y ago
Sounds to me like we've round-tripped back to PHP, circa 2009. Bout time!
- whstl 4y ago
  There are good things and bad things about PHP. This is one of the good things.
  - jesse__ 4y ago
    Definitely! I'll make a small edit to my comment to make it clear I'm not dunking on the idea
- mattgreenrocks 4y ago
  That's the vibe I got from browsing the Fresh documentation. However, I don't see it as a bad thing! Concepts feel like they fit together much more nicely than what I've seen in a lot of web tools. As someone who is a bit of an outsider to webdev, it looks like enough power to make most webapps I'd want to make. I think the only question in my mind is what the benefits/drawbacks of Deno+Fresh vs something like SvelteKit.
- praisewhitey 4y ago
  more like PHP circa 1999 honestly
redox99 4y ago
I'm not sure why so many are interested in not having a build step. You'll still want to have a step that runs typescript to check for errors, a linter, maybe your tests and other stuff. Or do people just want to YOLO it and let it crash in prod?
- deleted 4y ago
  [deleted]
haolez 4y ago
Maybe they could add a new transpiled language as well, like Civet[0] or ReScript[1]. Not every project needs to be a C#/.NET clone in TypeScript :) [0] https://civet.dev/ https://civet.dev/ [1] https://rescript-lang.org/ https://rescript-lang.org/
irrational 4y ago
I hate hate hate that modern web development requires a build system. No build system would probably get me to convert to Deno.
- sixstringtheory 4y ago
  > I hate hate hate that modern web development requires a build system Why? For any sufficiently complex software system, a build system serves as a reducer whose input is something that is more convenient for developers, ie huge codebase with tons of utilities and annotations, and whose output is something more optimized to run on the end users' devices. It's good to do such optimization because there will be, at least for a successful project, many orders of magnitude more EUs than devs. And an automated solution can do much more optimization than any team of devs could ever hope to do manually. And that's before you get into obfuscation, although I can't tell whether that's necessary more for user security or just protecting IP. (Not a web dev, I write in a compiled language in my day-to-day.)
  - rakoo 4y ago
    Because the need for a tool that bridges the impedance mismatch only hides the impedance mismatch even more, it allows developers to be even more remote from end users than before. It doesn't even start to question why we have an impedance mismatch in the first place. It keeps engineers in their position of those-who-know, and end-users in their position of those-who-need, preventing appropriation of technology. As software engineers we ought to question if we're going in the right direction, and "more complexity" is not something I agree is better
    - noahtallen 4y ago
      In what other similar user-facing system would that be the case? There is an impedance mismatch just in the fact that a UI is much different from code itself. There is a mismatch between what your parents can learn to use (UI) vs. what computers can understand (code). Most other UI projects are compiled (native apps), and they don’t even need to care about sending that final executable over the wire very quickly, or even other web optimizations a bundler might do like code splitting. These systems become complex because the web is a much different deploy target than, say, iOS.
rsp1984 4y ago
> What exactly needs to happen to make server-side JavaScript run in the browser? That sounds like an oxymoron to me. I have honestly no idea what they mean by that. To me, a browser is client-side software, so saying you want to run server-side JS on it doesn't make any sense. They mention it several times in the article but I simply can't follow. Could someone with a deeper understanding ELI5 this to me?
- Ygg2 4y ago
  A bit simplistic of a take, consider games. First client server games made server deal with logic, exclusively. Modern (post Quake) games make server authoritative but allow server logic to run locally. What modern JS app do is something hybrid client/server rendering. It's akin to moving/transmitting code from server for faster rendering. I think they use it for offline web apps and to fix problems with server side rendering (usage of resource, time to first render).
  - agumonkey 4y ago
    We're going to have locality optimizing migrating code.
- pphysch 4y ago
  It doesn't make a lot of practical sense, but basically they want to reuse substantial amounts of server code as client code. A fundamental misunderstanding of the client-server model, methinks.
  - aheieosnssisowi 4y ago
    You can't see a good reason to validate form inputs client side and use the exact same validations server side?
    - pphysch 4y ago
      That's nonsense. There are many validations that you don't trust to client to handle (or will require API calls, making "exact same" an unreasonable expectation). Ultimately, frontend validation is for UX and backend validation is for security. Different concerns, different capabilities, different code.
joshmanders 4y ago
Yes JIT building on route request sounds super non-wasteful and better. /s
- pier25 4y ago
  AFAIK there's some caching going on.
leerob 4y ago
IMO, this post doesn't discuss the tradeoff of removing the build step. What a “build” is has been obfuscated. When you deploy an app, you now need to convert TypeScript into JS, and then the JS needs to be turned into an optimal representation for V8 to process. For example, Fresh has a “build process” whose cost is paid for by the user [1]. You want to do these things before the user hits your page, and that’s the nice thing about CI/CD. You can ensure correctness and you can optimize code. In the interest of losing the build step, a tradeoff is made for worse UX for developer experience (DX). Rather, I would recommend shifting the compute that makes sense to the build step, and then give developers the optionality to do other work lazily at runtime[2]. [1]: https://github.com/denoland/fresh/blob/08d28438e10ef36ea5965efc712b3d785b0a2aec/src/server/bundle.ts#L15 https://github.com/denoland/fresh/blob/08d28438e10ef36ea5965... [2]: https://vercel.com/docs/concepts/incremental-static-regeneration/overview https://vercel.com/docs/concepts/incremental-static-regenera...
- KyleJune 4y ago
  In addition to this, the bundle files generated at runtime are stored in memory in a Map. If you have a server and want to have multiple processes for handling requests, each of those processes will have a copy of the build artifacts in memory. Any requests that get routed to newly started processes will have their response delayed by however long it takes to generate the bundle. So users would experience seemingly random delayed load times due to runtime bundling. I think it would be better to do bundling in your CI/CD. esbuild supports incremental builds, so using that + code splitting would be one way of speeding up builds. With their current bundling design, if they believe bundling is fast enough for users to not be negatively impacted, wouldn't it also be fast enough to not slow down development/deployment by having it in a build step?
robust-cactus 4y ago
The history here is a little misleading. Client side bundling happened before node/npm. It's a performance optimization to reduce the number of requests the browser has to make. Typically people were just concatenating files. Concatenating was a painful dependency management challenge for larger code bases. Subsequently there were module systems like requirejs that also sought to fix some problems like these and ran without a build step in dev. Browserify really changed the perspective here and people started to think a build step wasn't sooo bad. I do think, based on the requirejs code that commonjs/browserify didn't really need to be compiled anyways. Also fwiw, the technique mentioned here is a way a colleague and myself introduced babel to a large company as well, we just transformed + reverse proxy cached in dev. And fwiw, webpack basically does this anyways these days.
deleted 4y ago
[deleted]
LunaSea 4y ago
Deno is the "these go to 11" of the Node.js world. Creating a whole fork simply to not build TypeScript, reinvent a worse package management system and a useless security harness.
- yoavm 4y ago
  That's quite a harsh statement... What's so bad about package management? And what's useless about the security harness?
  - LunaSea 4y ago
    > What's so bad about package management? Hard coding URLs is significantly worse than having a package.json file: - you don't need to write the full URL to import a module - you have a quick overview of which modules are installed and for which reason (dev dependencies) - you can easily create an immutable list of dependencies > And what's useless about the security harness Because most apps will have to enable all flags (file system and network) anyway and because huge security holes like symlinks breaking out of the harness were present not too long ago.
    - hobofan 4y ago
      - URL-based dependencies also have some additional security issues in the most common usage scenarios (see my recent flagged post: https://news.ycombinator.com/item?id=34937327 https://news.ycombinator.com/item?id=34937327). - You also lose all ecosystem upgradability, as everyone is using pinned versions instead of SemVer ranges
      - tracker1 4y ago
        How many things have been broken by doing that in practice though? I mean seriously... in node/npm, I've seen way too many times where a minor version broke things in practice... so we go to patch level by default, usually safer... In the end, we still wind up needing tools, like with github to alert to issues that require larger bumps.. Oh, your application hasn't been updated in a year, and you now have two major versions of LibraryX to run through... Next thing you know, you've spent literally three weeks to update your node/npm/react project... and even then, some packages were too painful to update, so you just deal with the warnings anyway. And, now you've concentrated targets to the latest minor/patch versions in packages... where if everyone is pinned, the targets are mostly unknowned from outside without deeper inspection. Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with.
pachico 4y ago
Regardless of if Deno solves or not the issue, this article clearly depicts how broken the entire user experience is.
deleted 4y ago
[deleted]
andrewmcwatters 4y ago
The dumbest thing about people building JavaScript to me is that you burn all of the energy and labor of building with almost none of the meaningful benefits. No one is building and ending up with bundles that are reducing the bloat of the web, you can’t tree-shake your way out of bad practices. Articles and real lived experiences show us that the web is still bloated. And why are we transpiling anything? If people want to flirt with building, I wish JavaScript engineers would just build an implementation that compiles to machine code intermediate representation. Which is it? Do you want to be a scripting language or a programming language that compiles to something? It’s so gross to me.
- geysersam 4y ago
  > Which is it? Do you want to be a scripting language or a programming language that compiles to something? It’s so gross to me. This is ridiculous. Just aesthetics. JS compiles to machine code when you run it "just in time". It's even relatively efficient considering it doesn't need static typing. The "build step" is just for reducing the size of the payload. It is possible a binary representation would make it even smaller but not by much. Not worth the added complexity
  - tracker1 4y ago
    A bit older, but both worth a read, and most of this is still relevant today... https://www.amazon.com/High-Performance-Web-Sites-Essential/dp/0596529309 https://www.amazon.com/High-Performance-Web-Sites-Essential/... https://www.amazon.com/Even-Faster-Web-Sites-Performance/dp/0596522304 https://www.amazon.com/Even-Faster-Web-Sites-Performance/dp/...
  - deleted 4y ago
    [deleted]
jstummbillig 4y ago
I am perplexed by the focus on this. Clearly there are excellent devs working on Deno — but what setups are you running that the actual build is holding your productivity back? Developing in node/ts or rails I don't think it would move the needle in the slightest for me. It's simply not an issue outside of my brain finding beauty in any kind of optimization. Is that all this is?
- andrewmcwatters 4y ago
  Developers creating problems they can solve later and call it progress.
- samjmck 4y ago
  When you’re trying to run a quick script or just want a “playground” environment where you can test your code, it holds you back. For example: I’m making a web app with Svelte in TypeScript and I’m trying to test a part of its code. To do that, I have to build the app first because TypeScript needs transpiling which in turn needs bundling etc…
  - yencabulator 4y ago
    With SvelteKit, vite dev will hot-reload things on the fly as you save files. Definitely not worth this amount of brittle complexity to avoid.
- inglor 4y ago
  Deno has a hard time innovating and the reason adoption has been low in my opinion is that Node is good enough and has a lot of these features anyway (esm, easy ts support, https imports, web apis like fetch etc). They are trying to innovate and coming up with differentiators and reasons to use the platform. If you had to ask me when I met Ryan 5 years ago in JSConf EU before he introduced deno - I would have assumed they'd have 30% market share by now (of server JS) but Node has been able to "catch up" to complaints quickly enough (I think) and Deno's selling points like edge computing and fast startup aren't super important for msot devs in most use cases in practice and there are other runtimes for different clouds (like cloudflare workers). That said - it is still really good they are trying to innovate and while I find the marketing speak shitty and somewhat in bad faith - I still think it's really good they're innovating and I'm very much in favor of that and hope they find something important enough to solve to get big.
kaleidawave 4y ago
https://github.com/denoland/deno/issues/1739 https://github.com/denoland/deno/issues/1739 just crossed 4 years. if they want people to do transpiling inside their own tool create an API so we can use our own tools rather than ones behind their black box. Would be a much better use of their time than writing this nonsensical bs
evmar 4y ago
I worked on JS infra for Google. One thing we found in this space is that when your apps get very large in terms of number of source files, there is a developer-impacting load time cost to the unbundled approach. That is, your browser loads the entry point file, then parses it for imports and loads the files referenced from there, then parses those for imports and so on. This process is not free. In particular, even when modules are cached, the browser still will make some request with If-Modified-Since header for each file, and even to localhost that has time overhead cost. This impact is greater if you are developing against some cloud dev server because each check costs a network round-trip. However this may only come up when you have apps with many files, which Google apps tended to do for protobuf reasons.
- moritzwarhier 4y ago
  Google apps always seem to stand out with an especially large amount of requests. Does Google use a proprietary module system for these runtime imports? I've only seen this from afar when using the Maps JS API.
  - inglor 4y ago
    This is the "don't download code you don't run" and "don't ask for data you don't need yet" with smart prefetching and caching. Mostly facilitated using an internal 3 letter framework in Google. If you want a de-googled approach for "only code you need" check out qwik by Misko Hevery who worked on a bunch f JS related things and a few others. The concept is "resumability". (not sure if that's what you entirely meant since your example was the maps api)
    - moritzwarhier 4y ago
      Thanks for the tip, I'll look at quik! My only experience with the approaches you mention so far has been code splitting and dynamic imports with webpack. Yes my example was a bit misleading as it's probably not specific to the maps JS API. Just remembered my casual observation of the network requests when embedding Maps using the JS API. Also saw that there were lots of tiny cacheable requests and overall great performance.
pier25 4y ago
Of course Deno has a build step. The difference is you don't have to configure it and it happens on demand rather than aot. It's definitely an improvement but the title is misleading.
- draw_down 4y ago
  [dead]
- tracker1 4y ago
  Probably one of the more rational takes I've seen in this discussion... I happen to prefer the Deno approach, while I really do appreciate the efforts for better node.js compatibility, if only because of the sheer volume of modules out there. I do think that new libraries should probably go the other direction with Deno first and Node/npm as a separate build target. I've started also reaching for Deno first for a few shell scripting chores where I need more than bash... #!/usr/bin/env -S deno run ... Which has been pretty handy.
Fauntleroy 4y ago
They make you read an entire article about how bad build steps are, only to present you with the (no less appealing) alternative of JIT compliation with URLs. This does nothing to improve the "sea of dependencies" problem they spent so much time pointing out as a bad thing.
jhatemyjob 4y ago
Great clickbait title, makes people wanna jump in the comments and say the OP is wrong. I mean if we wanna get really pedantic about it then yes there will always be a build step no matter what you do, one could argue saving the file and alt-tabbing to the browser is a build step, but that's not the point is it? The idea is to lower that friction as much as possible and JIT is perfect for that
avereveard 4y ago
sure these framework may do just in time transpilation and compression, that doesn't mean you don't have a build step. copying the code to the server becomes the build step. except now you have no chance to lint the code before shipping it "but I can lint it on my machine" good, then you have a build system, and you may as well just get the optimized stuff on the server, since server startup time depends on your code size at some point or another, and you pay for that.
ashishb 4y ago
In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years. In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!
- nikanj 4y ago
  It’s been [2] days since I had to fix our npm install. One package (not ours) suddenly fails to build about 40% of the time. Looks like a parallel access problem, node-gyp poops with ”Unable to access foobar.tlog” because some other step is using the same file Fixed elegantly by adding a while(failed){npm install} Because trying to debug the build for a package you didn’t create just isn’t worth it
- Vaguely2178 4y ago
  Very few languages operate under the same constraints as js. When you ship js you can't guarantee the version of Ecmascript that the client will be running, or the standard library of DOM functions that will be available (which differ slightly from browser to browser), so you end up transpiling your code to the least common denominator. You also have completely different performance requirements compared to most other languages. If I ship a python app I don't have to worry about reducing the length of variables names to shave off a few bytes, or bundling multiple files together to reduce the number of http requests. Other languages don't need to dynamically load code via http requests, they generally run under the assumption that all of the code is available before execution. The closest comparison outside of the browser would be to the container ecosystem, which also runs code in an environment agnostic way, and there's plenty of complexity and volatility there (podman, buildah, docker, nerdctl, k8s, microk8s, k3s, k0s, nomad, docker swarm, docker compose, podman compose, et cetera).
  - ashishb 4y ago
    > The closest comparison outside of the browser would be to the container ecosystem And as someone who has worked on both, I can tell you that the container ecosystem is way better and way more deterministic. `Dockerfile` from 10 years back would work today as well. Any non-trivial package.json written even a few years ago would have half the packages deprecated in non-backward compatible way! There is another similar ecosystem of mobile apps. That's also way superior in terms of the developer experience. > Other languages don't need to dynamically load code via http requests, they generally run under the assumption that all of the code is available before execution. And that's not what I am objecting to. My concern is that the core JS specification is so barebones that it fragments right from the start. 1. There isn't a standard project format 2. There isn't a single framework that's backward compatible for 5+ years. 3. There isn't even an agreeement on the right build tools (npm vs yarn vs pnpm...) 4. There isn't an agreement on how to do multi-threaded async work You make different choices and soon every single JS project looks drastically different from every other project. Compare this to Java (older than JS!) or Go (newer than JS but highly opinionated). People writing code in Java or Go, don't expect there builds to fail ~1-5% of the times. Nor are the frameworks changed in a backward-compatible way every few years.
fauigerzigerk 4y ago
I'm certainly not the foremost expert in JavaScript build systems, but this just seems wrong. Reducing build times (or eliminating the build step) by moving things to runtime is a great idea for a debug build/mode. But why is it a good idea not to have separate release build to optimise for runtime performance?
pentagrama 4y ago
> [graph] > Interest in Node.js grew since its inception. They should mention the source of this, I guess is Google Trends.
jongjong 4y ago
This article is spot on. As a developer, I don't want to see the build step. As soon as you expose the mechanics of the build and transpilation process to developers, you add a ton of complexity; for example, it opens up the possibility of transpiler and JS engine version incompatibilities. Devs should only need to concern themselves with one number; the version of the engine which runs their code. If they need to worry about the engine version and the transpiler version separately, it makes code less portable because you can't just say "This library runs on Node.js version x.x." It sucks to come across a library which works on your engine version but relies on a newer version of TypeScript... It's like hoping for the planets to align sometimes.
habitue 4y ago
certainly, in terms of writing scripts, deno seems nicer. Like, if I want to write typescript that just runs and does something, without having to carry around a node_modules folder, etc, deno seems like it might be nice
throwaway14356 4y ago
I think new features move into the browsers pretty fast nowadays? The new stuff introduced is overly hipster. The old stuff still needs a lot of polish. We keep getting the means to do all kinds of new things but it (by lack of better words) progresses forwards. The sum of things adds up to greater things. The (almost) opposite approach is to look what people are doing then make a single thing that does that directly, without 100 weird steps. Update it to make it better just like modules do. Everything html does looks like it was slapped together in a weekend. If you look at the spec it is obvious a lot of work went in but the default behavior never fails to disappoint. Some examples out of hundreds: we wanted a range selector and a slider, we got a slider and they called it range. How do I do a range now and make it look the same as the slider? Oh, I write both from scratch? lmao Half of json's greatness is in how sad the xml tools are but if I compare both to sql I wonder how I get any work done at all! Imagine a form was just a json. Like json in and json out. Dynamically creating form fields and populating them from a deeply nested json, allowing the user to add fields, then trying to get the json toothpaste back into the tube was a truly hilarious adventure. I eventually just set the attribute value to the value of the form field then stored the html in the db. Did you know js has an xpath implementation? Not that one could use it but there it is. haha I really think with some love we could just go back to writing html/js/css directly. Maybe it is just that I fail to see the point of nodejs.
btbuildem 4y ago
Putting JS in the backend was a tragic mistake born of laziness and ignorance. It should not be a surprise that everything else that followed suffers the consequences of these root traits as well. JS was barely acceptable when it was caged in browser-land, and we'd all be better off had it stayed there. FE development has some unique challenges, but in my experience a lot of people who work in this domain try to find their own solutions to problems that have already been solved decades prior. There's a reason the build chains are fragile and a nightmare to configure, that package lists are out of date the moment they're published, and that it takes a sustained effort to maintain a project viable even if you're not adding features or fixing bugs. It's absurd, and it's the status quo. To take this into other areas of development (like BE for example) simply because that's what you're familiar with... it really is a special kind of masochism.

328 points by vancroft 4y ago

My understanding of this is that this is trading a build step for just in time (JIT) compilation, which seems, ok? But it seems to me that you've just moved the problem around and I'm sure there are additional trade-offs (as with anything).

dboreham 4y ago
"Build" in JS circles usually means transpile, not a replacement for JIT which will still happen at runtime. In addition to that, often there are other concerns addressed at build time such as linting.
- kldavis4 4y ago
  yeah, exactly. So I wonder if ultimately they want to have the browser handle transpiling things like typescript? And I definitely think there are other concerns (such as linting) that you want to happen as part of your development pipeline.
  - kamikaz1k 4y ago
    Browser doesn't transpile, and if you're transpiling in the browser in your own JS, you're doing it wrong...generally Point of transpiling is improving DX, so it has no business being done during users browser render.
    - kldavis4 4y ago
      Sorry - I miswrote that - I meant the browser directly compiling (JIT) typescript
  - whstl 4y ago
    There is an ES39 proposal to allow type annotations in Javascript, that would allow the browser to handle TS/Flow files without needing a compile step: https://github.com/tc39/proposal-type-annotations https://github.com/tc39/proposal-type-annotations (That's only to allow the type annotations to be there, not to have static checking in the browser) IMO: I would love to see this implemented. Linting and typechecking should be ran before committing code or deploying, but I want to be able to stop transpiling/bundling in all cases.
    - deckard1 4y ago
      that sounds needlessly wasteful. You can trivially strip TS out of JS before sending off to the client. You're still going to need to check TS in the build/CI step (i.e. the time consuming part) before doing anything so you've gained exactly nothing.
      - whstl 4y ago
        "You can trivially strip TS out of JS before sending off to the client" To quote you, that sounds needlessly wasteful to me. Also I prefer not needing to deal with SourceMaps or different source when debugging. So it's quite the contrary: I gain a lot. Different strokes for different folks.
        moritzwarhier 4y ago
        I understand your reasoning but it seems to be focused more around developer time rather than bundle size and user experience if I am not mistaken. The ratio between built code size and source size can easily reach orders of magnitude in TypeScript projects with exhaustive types. Sending all that code to the user is wasteful, and this wastefulness is multiplied by X end users, as opposed to the development process which is centralized. From a money perspective the picture is different of course. I would still love to be able to execute TS directly in the browser, but this is purely a DX thing.
        deleted 4y ago
        [deleted]
  - temp_account_32 4y ago
    I feel like this is what everyone actually wants. Typescript in the browser (at least for me personally) would be awesome, and if they made TS into a separate language with its own runtime, that would be like the holy grail.
- deleted 4y ago
  [deleted]

msoad 4y ago

> And to be make your Fresh app more performant, all client-side JavaScript/TypeScript is cached after the first request for fast subsequent retrievals. My understanding is that the client side JS is a result of backend compilation. How does this work if the backend is dynamically generating those JS files? `getPosts()` can return a different JSX based on what `getPosts()` returns. No?

brundolf 4y ago
(At least in React) the JSX gets transpiled to function calls, which are then run at render time with a particular set of data. That first transpilation step will always come out the same and can be cached.

dom96 4y ago

I tend to stick with script tags as much as I can. Really the problem are all the frameworks pushing people to create a build step. Their excuse is optimising the code size, but for most cases that matters little, I don't mind including all of tailwind or font-awesome. So please, if you own a framework like this, make sure a script tag with a CDN link is easily copyable.

djbusby 4y ago
How can you get all of tailwind? I've been struggling on that one, always have to run some tool to get a built CSS file. And any change then needs build before refresh. And I cant look at a file with 1000s of definition (which I want to do)
- gremlinsinc 4y ago
  i think if you use tailwind, not to use the actual package loses a lot of what it can do, I don't think you get all the features/functions for ..um only delivering the parts required (having mind fog this morning lol)... I'm not sure if it's tree-shaking, but how they look at every file w/ tailwind in and only bundle up the needed css. However, maybe it works in deno? I don't know.
hbn 4y ago
Are you talking about the CDN version of Tailwind? If so, the docs specifically say that's not for production use. A lot of very useful features require a build step because it generates classes on the fly based off what you typed in the HTML.
- dom96 4y ago
  I bet you lots of people are ignoring the "don't use this in prod" advice. Why doesn't Tailwind just offer a for-production CDN link? I understand that the build step provides features, but what if I don't care about those features?
  - 4y ago

ChicagoDave 4y ago

Pretty sure we were building code to validate it and unit test it before releasing it. This article is strictly about JavaScript. What about all the server-side rendering frameworks? Huge assumption that everything is built one way.

deleted 4y ago
[deleted]

vhiremath4 4y ago

The decoupling of URLs that host your dependencies and the URLs that host your application feels like an important uptime measure currently. If the URLs that host your dependencies go down in an NPM world, you can't build and deploy new code but your app is still up. It seems, if the URLs that host your dependencies go down in a Deno world, your app goes down if those dependencies have not yet been cached (even on the server). Am I missing something? This might not be terrible if it becomes the standard to host your own mirror internally.

DotaFan 4y ago
On Android we do the same with help of Gradle. It retrieves library from a remote source and caches it. If there is no cache, next time your Gradle tries to build, it will download the library from a remote source. If remote host fails, you can not build your app. One of popular host providers had issues couple of times in last year, and it wasn't nice. https://github.com/jitpack/jitpack.io/issues?q=is%3Aissue+sort%3Acomments-desc+is%3Aclosed https://github.com/jitpack/jitpack.io/issues?q=is%3Aissue+so...
gremlinsinc 4y ago
Deno should have like a mirrors.manifest.js file that stores your dependency links, and mirrors, should one source go down... that way it wouldn't be such a problem, the only big issue might be ensuring the sources don't have a rogue link or two from bad actors, where they do something nefarious like build a useful package then swap it out for a bad version later on, and put only on a mirror so when things go south it triggers, of course there could be bots/queues that periodically take md5s of the code, or just whenever version changes occur, so that would stop that.
- crdrost 4y ago
  This exists and is part of the deno executable; see [1] for more info. 1. https://deno.land/manual@v1.31.1/tools/vendor https://deno.land/manual@v1.31.1/tools/vendor
- qbasic_forever 4y ago
  Deno puts a hash of the dependency contents in a lock file so it can ensure the contents of a dependency haven't been changed unexpectedly: https://deno.land/manual@v1.29.2/basics/modules/integrity_checking https://deno.land/manual@v1.29.2/basics/modules/integrity_ch...

franciscop 4y ago

So basically Deno has its own bundler that lets you not have a local build step and it gets bundled dynamically per-route as requested by users, right? This is very different from industry standards and possibly has many new concerns from devs, none of which are addressed in the article since it's treating the system as a perfect solution, which makes sense since it's a marketing page ("content marketing"). If it was a 3rd party article, I'd be interested in things like: - How do you measure bundle size and make sure it remains small? (e.g. make sure that a PR doesn't accidentally import a massive dependency) - How do you measure bundling speed/performance, does it add significant time to the first request? To subsequent requests? Is it linear, exponential, etc. with the number of LOC? Again like in the previous point, how do we make sure there are no regressions here? - How does this work, well, with absolutely anything else? If I want my front-end in React? Vue? etc.

mattlondon 4y ago
From the article: "Fresh renders each page on the fly and sends only HTML" So the bundle size is zero.
- kamikaz1k 4y ago
  Fresh supports islands, so it also does send JavaScript for the interactive bits. If you have a react (default is preact) island then that'll be bundled and sent down.
- IncRnd 4y ago
  > unless an Island is involved, then only the needed amount of JavaScript will be sent as well It's not just HTML but also JS that gets sent.
deleted 4y ago
[deleted]
brundolf 4y ago
It sounds like (it is a little vague) there is no bundling at all, the only thing Deno does magically at request time is transpiling TypeScript/JSX to browser-compatible JS. Beyond that I think the idea is it relies on native ES module imports (and import-maps), both of which are browser standards

pictur 4y ago

Deno didn't have a structure that caught my attention in its early stages. But now i see it going in the direction i need logically. I guess I need to start experimenting with a side project.

groestl 4y ago

[flagged]

pictur 4y ago
I think that the absence of a compilation phase does not prevent the establishment of infrastructure for e2e testing. If you can only be sure that the application is running when the build is successful, then there are probably other big problems there.
whstl 4y ago
No, they don't have to. Deno supports Typescript. And Typescript supports Typechecking without a build process. Linters, tests and other tools can also be run without a build process.
- groestl 4y ago
  What exactly is "a build process" for you. For me, it is a process which results in an artifact. An artifact that is, in the best case, automatically tested, optimized, signed, and ready to be deployed. Compilation is a rather small part of it. But since I need to run all the other things anyway, why not compile there, and remove entropy from runtime.
  - jamesgeck0 4y ago
    "build process" is defined in detail in TFA. You're arguing about something so entirely orthogonal to the point of the article that I can't help but wonder if you've actually read it.
    - groestl 4y ago
      I did read it, and I find the title misleading.
  - deleted 4y ago
    [deleted]

codemonkey-zeta 4y ago

So Deno is relying on native ESM imports in production code? Isn't that exactly what Vite _doesn't_ do, because of poor performance? When you run the vite dev server it uses ESM, but when you build it uses rollup, because serving ESM is slow and with larger apps the client browser is going to make a bazillion requests. Wouldn't you rather traverse the dependency graph one time and bundle your code into modules so that everyone who visits your site doesn't force their browser to do it over and over again? Sure those dependencies will be cached between views or refreshes, but the first load will be slow as shit, then you still need to "code-split", just now you're calling it "islands".

silviot 4y ago
Deno is an alternative to node and npm. You can have a Deno http server serving content to a browser. But the browser won't care how the server runs, as long as it can speak HTTP. You can also use Deno to run your bundling tools, but again, what happens in Deno stays in Deno and does not reach the browser.
TheRealPomax 4y ago
That sounds like an assumption that's not actually been tested recently. Downloading a 2MB bundle or 100 separate files is an equally poor experience, but the separate files at least let you download only the parts that changed over time, instead of having to download a completely new 2MB bundle every time someone changes a single letter in one of 100+ files and a new bundle with a new integrity digest gets rolled out. I'd rather have an equally slow experience on first load, and then much better performance forever, compared to having something that constantly invalidates the entire cache.
- cjblomqvist 4y ago
  I'm not sure what recent means, but I'm fairly sure (sorry, no references - only from memory) that it's been tested quite a lot, and also relatively recently (1-2 years?) by Evan (the guy behind Vite). Even with newer versions of http just transferring lots of small files is noticeably slower (few percent if I remember correctly).

xiphias2 4y ago

I thought this will be an article about adding import maps to deno, which would be great. I hope builders start adding it (at least to dev instances) to decrease the magic. I was trying to use import maps, but it's not trivial go create actually. There are always problems with Node lagging behind browsers though that makes developing hard (no WebSocket support by default for example, crypto module is also not included)

eyelidlessness 4y ago
Deno does support import maps out of the box. For Node there’s a loader[1] you can use (though a glance at the GitHub issues suggests it’s incomplete). 1: https://www.npmjs.com/package/@node-loader/import-maps https://www.npmjs.com/package/@node-loader/import-maps
- xiphias2 4y ago
  Does it generate import maps for me automatically? That's the hard part. I'm using Vite with Sveltekit, which is great because it compiles files separately, but still doesn't generate import maps, but uses imports with relative and absolute filenames.
  - eyelidlessness 4y ago
    I don’t use Svelte of any kind so I’m possibly out of my depth, but I don’t know what I’d want to automate with import maps. I don’t think Deno addresses any use case like that but I’m hesitant to say so because I really don’t know what need I’m even addressing.

mattwad 4y ago

So, if I'm using URLs for dependencies, effectively I can't code while I'm offline? I know it's not the norm, but there have been plenty of times I needed to work without internet.

schemescape 4y ago
I’m fairly certain Deno caches the downloaded artifacts locally. There’s also tooling for downloading all dependencies: https://deno.land/manual@v1.29.1/tools/vendor https://deno.land/manual@v1.29.1/tools/vendor
whstl 4y ago
No. Deno supports vendoring, caching and locking of dependencies just like other ecosystem. They are not fetched every time you run the app.

jesse__ 4y ago

Sounds to me like we've round-tripped back to PHP, circa 2009. Bout time!

whstl 4y ago
There are good things and bad things about PHP. This is one of the good things.
- jesse__ 4y ago
  Definitely! I'll make a small edit to my comment to make it clear I'm not dunking on the idea
mattgreenrocks 4y ago
That's the vibe I got from browsing the Fresh documentation. However, I don't see it as a bad thing! Concepts feel like they fit together much more nicely than what I've seen in a lot of web tools. As someone who is a bit of an outsider to webdev, it looks like enough power to make most webapps I'd want to make. I think the only question in my mind is what the benefits/drawbacks of Deno+Fresh vs something like SvelteKit.
praisewhitey 4y ago
more like PHP circa 1999 honestly

redox99 4y ago

I'm not sure why so many are interested in not having a build step. You'll still want to have a step that runs typescript to check for errors, a linter, maybe your tests and other stuff. Or do people just want to YOLO it and let it crash in prod?

deleted 4y ago
[deleted]

haolez 4y ago

Maybe they could add a new transpiled language as well, like Civet[0] or ReScript[1]. Not every project needs to be a C#/.NET clone in TypeScript :) [0] https://civet.dev/ https://civet.dev/ [1] https://rescript-lang.org/ https://rescript-lang.org/

irrational 4y ago

I hate hate hate that modern web development requires a build system. No build system would probably get me to convert to Deno.

sixstringtheory 4y ago
> I hate hate hate that modern web development requires a build system Why? For any sufficiently complex software system, a build system serves as a reducer whose input is something that is more convenient for developers, ie huge codebase with tons of utilities and annotations, and whose output is something more optimized to run on the end users' devices. It's good to do such optimization because there will be, at least for a successful project, many orders of magnitude more EUs than devs. And an automated solution can do much more optimization than any team of devs could ever hope to do manually. And that's before you get into obfuscation, although I can't tell whether that's necessary more for user security or just protecting IP. (Not a web dev, I write in a compiled language in my day-to-day.)
- rakoo 4y ago
  Because the need for a tool that bridges the impedance mismatch only hides the impedance mismatch even more, it allows developers to be even more remote from end users than before. It doesn't even start to question why we have an impedance mismatch in the first place. It keeps engineers in their position of those-who-know, and end-users in their position of those-who-need, preventing appropriation of technology. As software engineers we ought to question if we're going in the right direction, and "more complexity" is not something I agree is better
  - noahtallen 4y ago
    In what other similar user-facing system would that be the case? There is an impedance mismatch just in the fact that a UI is much different from code itself. There is a mismatch between what your parents can learn to use (UI) vs. what computers can understand (code). Most other UI projects are compiled (native apps), and they don’t even need to care about sending that final executable over the wire very quickly, or even other web optimizations a bundler might do like code splitting. These systems become complex because the web is a much different deploy target than, say, iOS.

rsp1984 4y ago

> What exactly needs to happen to make server-side JavaScript run in the browser? That sounds like an oxymoron to me. I have honestly no idea what they mean by that. To me, a browser is client-side software, so saying you want to run server-side JS on it doesn't make any sense. They mention it several times in the article but I simply can't follow. Could someone with a deeper understanding ELI5 this to me?

Ygg2 4y ago
A bit simplistic of a take, consider games. First client server games made server deal with logic, exclusively. Modern (post Quake) games make server authoritative but allow server logic to run locally. What modern JS app do is something hybrid client/server rendering. It's akin to moving/transmitting code from server for faster rendering. I think they use it for offline web apps and to fix problems with server side rendering (usage of resource, time to first render).
- agumonkey 4y ago
  We're going to have locality optimizing migrating code.
pphysch 4y ago
It doesn't make a lot of practical sense, but basically they want to reuse substantial amounts of server code as client code. A fundamental misunderstanding of the client-server model, methinks.
- aheieosnssisowi 4y ago
  You can't see a good reason to validate form inputs client side and use the exact same validations server side?
  - pphysch 4y ago
    That's nonsense. There are many validations that you don't trust to client to handle (or will require API calls, making "exact same" an unreasonable expectation). Ultimately, frontend validation is for UX and backend validation is for security. Different concerns, different capabilities, different code.

joshmanders 4y ago

Yes JIT building on route request sounds super non-wasteful and better. /s

pier25 4y ago
AFAIK there's some caching going on.

leerob 4y ago

IMO, this post doesn't discuss the tradeoff of removing the build step. What a “build” is has been obfuscated. When you deploy an app, you now need to convert TypeScript into JS, and then the JS needs to be turned into an optimal representation for V8 to process. For example, Fresh has a “build process” whose cost is paid for by the user [1]. You want to do these things before the user hits your page, and that’s the nice thing about CI/CD. You can ensure correctness and you can optimize code. In the interest of losing the build step, a tradeoff is made for worse UX for developer experience (DX). Rather, I would recommend shifting the compute that makes sense to the build step, and then give developers the optionality to do other work lazily at runtime[2]. [1]: https://github.com/denoland/fresh/blob/08d28438e10ef36ea5965efc712b3d785b0a2aec/src/server/bundle.ts#L15 https://github.com/denoland/fresh/blob/08d28438e10ef36ea5965... [2]: https://vercel.com/docs/concepts/incremental-static-regeneration/overview https://vercel.com/docs/concepts/incremental-static-regenera...

KyleJune 4y ago
In addition to this, the bundle files generated at runtime are stored in memory in a Map. If you have a server and want to have multiple processes for handling requests, each of those processes will have a copy of the build artifacts in memory. Any requests that get routed to newly started processes will have their response delayed by however long it takes to generate the bundle. So users would experience seemingly random delayed load times due to runtime bundling. I think it would be better to do bundling in your CI/CD. esbuild supports incremental builds, so using that + code splitting would be one way of speeding up builds. With their current bundling design, if they believe bundling is fast enough for users to not be negatively impacted, wouldn't it also be fast enough to not slow down development/deployment by having it in a build step?

robust-cactus 4y ago

The history here is a little misleading. Client side bundling happened before node/npm. It's a performance optimization to reduce the number of requests the browser has to make. Typically people were just concatenating files. Concatenating was a painful dependency management challenge for larger code bases. Subsequently there were module systems like requirejs that also sought to fix some problems like these and ran without a build step in dev. Browserify really changed the perspective here and people started to think a build step wasn't sooo bad. I do think, based on the requirejs code that commonjs/browserify didn't really need to be compiled anyways. Also fwiw, the technique mentioned here is a way a colleague and myself introduced babel to a large company as well, we just transformed + reverse proxy cached in dev. And fwiw, webpack basically does this anyways these days.

deleted 4y ago

[deleted]

LunaSea 4y ago

Deno is the "these go to 11" of the Node.js world. Creating a whole fork simply to not build TypeScript, reinvent a worse package management system and a useless security harness.

yoavm 4y ago
That's quite a harsh statement... What's so bad about package management? And what's useless about the security harness?
- LunaSea 4y ago
  > What's so bad about package management? Hard coding URLs is significantly worse than having a package.json file: - you don't need to write the full URL to import a module - you have a quick overview of which modules are installed and for which reason (dev dependencies) - you can easily create an immutable list of dependencies > And what's useless about the security harness Because most apps will have to enable all flags (file system and network) anyway and because huge security holes like symlinks breaking out of the harness were present not too long ago.
  - hobofan 4y ago
    - URL-based dependencies also have some additional security issues in the most common usage scenarios (see my recent flagged post: https://news.ycombinator.com/item?id=34937327 https://news.ycombinator.com/item?id=34937327). - You also lose all ecosystem upgradability, as everyone is using pinned versions instead of SemVer ranges
    - tracker1 4y ago
      How many things have been broken by doing that in practice though? I mean seriously... in node/npm, I've seen way too many times where a minor version broke things in practice... so we go to patch level by default, usually safer... In the end, we still wind up needing tools, like with github to alert to issues that require larger bumps.. Oh, your application hasn't been updated in a year, and you now have two major versions of LibraryX to run through... Next thing you know, you've spent literally three weeks to update your node/npm/react project... and even then, some packages were too painful to update, so you just deal with the warnings anyway. And, now you've concentrated targets to the latest minor/patch versions in packages... where if everyone is pinned, the targets are mostly unknowned from outside without deeper inspection. Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with.

pachico 4y ago

Regardless of if Deno solves or not the issue, this article clearly depicts how broken the entire user experience is.

deleted 4y ago

[deleted]

andrewmcwatters 4y ago

The dumbest thing about people building JavaScript to me is that you burn all of the energy and labor of building with almost none of the meaningful benefits. No one is building and ending up with bundles that are reducing the bloat of the web, you can’t tree-shake your way out of bad practices. Articles and real lived experiences show us that the web is still bloated. And why are we transpiling anything? If people want to flirt with building, I wish JavaScript engineers would just build an implementation that compiles to machine code intermediate representation. Which is it? Do you want to be a scripting language or a programming language that compiles to something? It’s so gross to me.

geysersam 4y ago
> Which is it? Do you want to be a scripting language or a programming language that compiles to something? It’s so gross to me. This is ridiculous. Just aesthetics. JS compiles to machine code when you run it "just in time". It's even relatively efficient considering it doesn't need static typing. The "build step" is just for reducing the size of the payload. It is possible a binary representation would make it even smaller but not by much. Not worth the added complexity
- tracker1 4y ago
  A bit older, but both worth a read, and most of this is still relevant today... https://www.amazon.com/High-Performance-Web-Sites-Essential/dp/0596529309 https://www.amazon.com/High-Performance-Web-Sites-Essential/... https://www.amazon.com/Even-Faster-Web-Sites-Performance/dp/0596522304 https://www.amazon.com/Even-Faster-Web-Sites-Performance/dp/...
- deleted 4y ago
  [deleted]

jstummbillig 4y ago

I am perplexed by the focus on this. Clearly there are excellent devs working on Deno — but what setups are you running that the actual build is holding your productivity back? Developing in node/ts or rails I don't think it would move the needle in the slightest for me. It's simply not an issue outside of my brain finding beauty in any kind of optimization. Is that all this is?

andrewmcwatters 4y ago
Developers creating problems they can solve later and call it progress.
samjmck 4y ago
When you’re trying to run a quick script or just want a “playground” environment where you can test your code, it holds you back. For example: I’m making a web app with Svelte in TypeScript and I’m trying to test a part of its code. To do that, I have to build the app first because TypeScript needs transpiling which in turn needs bundling etc…
- yencabulator 4y ago
  With SvelteKit, vite dev will hot-reload things on the fly as you save files. Definitely not worth this amount of brittle complexity to avoid.
inglor 4y ago
Deno has a hard time innovating and the reason adoption has been low in my opinion is that Node is good enough and has a lot of these features anyway (esm, easy ts support, https imports, web apis like fetch etc). They are trying to innovate and coming up with differentiators and reasons to use the platform. If you had to ask me when I met Ryan 5 years ago in JSConf EU before he introduced deno - I would have assumed they'd have 30% market share by now (of server JS) but Node has been able to "catch up" to complaints quickly enough (I think) and Deno's selling points like edge computing and fast startup aren't super important for msot devs in most use cases in practice and there are other runtimes for different clouds (like cloudflare workers). That said - it is still really good they are trying to innovate and while I find the marketing speak shitty and somewhat in bad faith - I still think it's really good they're innovating and I'm very much in favor of that and hope they find something important enough to solve to get big.

kaleidawave 4y ago

https://github.com/denoland/deno/issues/1739 https://github.com/denoland/deno/issues/1739 just crossed 4 years. if they want people to do transpiling inside their own tool create an API so we can use our own tools rather than ones behind their black box. Would be a much better use of their time than writing this nonsensical bs

evmar 4y ago

I worked on JS infra for Google. One thing we found in this space is that when your apps get very large in terms of number of source files, there is a developer-impacting load time cost to the unbundled approach. That is, your browser loads the entry point file, then parses it for imports and loads the files referenced from there, then parses those for imports and so on. This process is not free. In particular, even when modules are cached, the browser still will make some request with If-Modified-Since header for each file, and even to localhost that has time overhead cost. This impact is greater if you are developing against some cloud dev server because each check costs a network round-trip. However this may only come up when you have apps with many files, which Google apps tended to do for protobuf reasons.

moritzwarhier 4y ago
Google apps always seem to stand out with an especially large amount of requests. Does Google use a proprietary module system for these runtime imports? I've only seen this from afar when using the Maps JS API.
- inglor 4y ago
  This is the "don't download code you don't run" and "don't ask for data you don't need yet" with smart prefetching and caching. Mostly facilitated using an internal 3 letter framework in Google. If you want a de-googled approach for "only code you need" check out qwik by Misko Hevery who worked on a bunch f JS related things and a few others. The concept is "resumability". (not sure if that's what you entirely meant since your example was the maps api)
  - moritzwarhier 4y ago
    Thanks for the tip, I'll look at quik! My only experience with the approaches you mention so far has been code splitting and dynamic imports with webpack. Yes my example was a bit misleading as it's probably not specific to the maps JS API. Just remembered my casual observation of the network requests when embedding Maps using the JS API. Also saw that there were lots of tiny cacheable requests and overall great performance.

pier25 4y ago

Of course Deno has a build step. The difference is you don't have to configure it and it happens on demand rather than aot. It's definitely an improvement but the title is misleading.

draw_down 4y ago
[dead]
tracker1 4y ago
Probably one of the more rational takes I've seen in this discussion... I happen to prefer the Deno approach, while I really do appreciate the efforts for better node.js compatibility, if only because of the sheer volume of modules out there. I do think that new libraries should probably go the other direction with Deno first and Node/npm as a separate build target. I've started also reaching for Deno first for a few shell scripting chores where I need more than bash... #!/usr/bin/env -S deno run ... Which has been pretty handy.

Fauntleroy 4y ago

They make you read an entire article about how bad build steps are, only to present you with the (no less appealing) alternative of JIT compliation with URLs. This does nothing to improve the "sea of dependencies" problem they spent so much time pointing out as a bad thing.

jhatemyjob 4y ago

Great clickbait title, makes people wanna jump in the comments and say the OP is wrong. I mean if we wanna get really pedantic about it then yes there will always be a build step no matter what you do, one could argue saving the file and alt-tabbing to the browser is a build step, but that's not the point is it? The idea is to lower that friction as much as possible and JIT is perfect for that

avereveard 4y ago

sure these framework may do just in time transpilation and compression, that doesn't mean you don't have a build step. copying the code to the server becomes the build step. except now you have no chance to lint the code before shipping it "but I can lint it on my machine" good, then you have a build system, and you may as well just get the optimized stuff on the server, since server startup time depends on your code size at some point or another, and you pay for that.

ashishb 4y ago

In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years. In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!

nikanj 4y ago
It’s been [2] days since I had to fix our npm install. One package (not ours) suddenly fails to build about 40% of the time. Looks like a parallel access problem, node-gyp poops with ”Unable to access foobar.tlog” because some other step is using the same file Fixed elegantly by adding a while(failed){npm install} Because trying to debug the build for a package you didn’t create just isn’t worth it
Vaguely2178 4y ago
Very few languages operate under the same constraints as js. When you ship js you can't guarantee the version of Ecmascript that the client will be running, or the standard library of DOM functions that will be available (which differ slightly from browser to browser), so you end up transpiling your code to the least common denominator. You also have completely different performance requirements compared to most other languages. If I ship a python app I don't have to worry about reducing the length of variables names to shave off a few bytes, or bundling multiple files together to reduce the number of http requests. Other languages don't need to dynamically load code via http requests, they generally run under the assumption that all of the code is available before execution. The closest comparison outside of the browser would be to the container ecosystem, which also runs code in an environment agnostic way, and there's plenty of complexity and volatility there (podman, buildah, docker, nerdctl, k8s, microk8s, k3s, k0s, nomad, docker swarm, docker compose, podman compose, et cetera).
- ashishb 4y ago
  > The closest comparison outside of the browser would be to the container ecosystem And as someone who has worked on both, I can tell you that the container ecosystem is way better and way more deterministic. `Dockerfile` from 10 years back would work today as well. Any non-trivial package.json written even a few years ago would have half the packages deprecated in non-backward compatible way! There is another similar ecosystem of mobile apps. That's also way superior in terms of the developer experience. > Other languages don't need to dynamically load code via http requests, they generally run under the assumption that all of the code is available before execution. And that's not what I am objecting to. My concern is that the core JS specification is so barebones that it fragments right from the start. 1. There isn't a standard project format 2. There isn't a single framework that's backward compatible for 5+ years. 3. There isn't even an agreeement on the right build tools (npm vs yarn vs pnpm...) 4. There isn't an agreement on how to do multi-threaded async work You make different choices and soon every single JS project looks drastically different from every other project. Compare this to Java (older than JS!) or Go (newer than JS but highly opinionated). People writing code in Java or Go, don't expect there builds to fail ~1-5% of the times. Nor are the frameworks changed in a backward-compatible way every few years.

fauigerzigerk 4y ago

I'm certainly not the foremost expert in JavaScript build systems, but this just seems wrong. Reducing build times (or eliminating the build step) by moving things to runtime is a great idea for a debug build/mode. But why is it a good idea not to have separate release build to optimise for runtime performance?

pentagrama 4y ago

> [graph] > Interest in Node.js grew since its inception. They should mention the source of this, I guess is Google Trends.

jongjong 4y ago

This article is spot on. As a developer, I don't want to see the build step. As soon as you expose the mechanics of the build and transpilation process to developers, you add a ton of complexity; for example, it opens up the possibility of transpiler and JS engine version incompatibilities. Devs should only need to concern themselves with one number; the version of the engine which runs their code. If they need to worry about the engine version and the transpiler version separately, it makes code less portable because you can't just say "This library runs on Node.js version x.x." It sucks to come across a library which works on your engine version but relies on a newer version of TypeScript... It's like hoping for the planets to align sometimes.

habitue 4y ago

certainly, in terms of writing scripts, deno seems nicer. Like, if I want to write typescript that just runs and does something, without having to carry around a node_modules folder, etc, deno seems like it might be nice

throwaway14356 4y ago

I think new features move into the browsers pretty fast nowadays? The new stuff introduced is overly hipster. The old stuff still needs a lot of polish. We keep getting the means to do all kinds of new things but it (by lack of better words) progresses forwards. The sum of things adds up to greater things. The (almost) opposite approach is to look what people are doing then make a single thing that does that directly, without 100 weird steps. Update it to make it better just like modules do. Everything html does looks like it was slapped together in a weekend. If you look at the spec it is obvious a lot of work went in but the default behavior never fails to disappoint. Some examples out of hundreds: we wanted a range selector and a slider, we got a slider and they called it range. How do I do a range now and make it look the same as the slider? Oh, I write both from scratch? lmao Half of json's greatness is in how sad the xml tools are but if I compare both to sql I wonder how I get any work done at all! Imagine a form was just a json. Like json in and json out. Dynamically creating form fields and populating them from a deeply nested json, allowing the user to add fields, then trying to get the json toothpaste back into the tube was a truly hilarious adventure. I eventually just set the attribute value to the value of the form field then stored the html in the db. Did you know js has an xpath implementation? Not that one could use it but there it is. haha I really think with some love we could just go back to writing html/js/css directly. Maybe it is just that I fail to see the point of nodejs.

btbuildem 4y ago

Putting JS in the backend was a tragic mistake born of laziness and ignorance. It should not be a surprise that everything else that followed suffers the consequences of these root traits as well. JS was barely acceptable when it was caged in browser-land, and we'd all be better off had it stayed there. FE development has some unique challenges, but in my experience a lot of people who work in this domain try to find their own solutions to problems that have already been solved decades prior. There's a reason the build chains are fragile and a nightmare to configure, that package lists are out of date the moment they're published, and that it takes a sustained effort to maintain a project viable even if you're not adding features or fixing bugs. It's absurd, and it's the status quo. To take this into other areas of development (like BE for example) simply because that's what you're familiar with... it really is a special kind of masochism.