111–120 of 224 posts
Would be a much better use of their time than writing this nonsensical bs
Earlier quoted context omitted.
Fun fact: the "compilation" step in my company's React project is the biggest consumer of CI minutes by far across our entire organization, beating out every one of the Maven compile and test loops But, since the devs don't care, there's only so much finger wagging I can do
Over the course of a month or two the time taken to compile a single .ts file in our codebase climbed from 'too small to measure' up to '7 seconds'. It eventually turned out that a single type definition in the file was causing all typechecks to become incredibly slow. Getting timing data out of build tools like rollup was brutal, and editors with tsc integration like vs code/sublime text would just lag and misbehave…
Build CI should be configured with a very aggressive upper limit to catch those regression but it's often forgotten; even I don't do it often while I have been bit more than once.
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?
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 th…
I hate hate hate that modern web development requires a build system. No build system would probably get me to convert to Deno.
Fun fact: the "compilation" step in my company's React project is the biggest consumer of CI minutes by far across our entire organization, beating out every one of the Maven compile and test loops But, since the devs don't care, there's only so much finger wagging I can do
If in terms of money it’s not significant, for the company it makes no sense to devote costly labour time to speed it up.
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.
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?
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…
Earlier quoted context omitted.
That's quite a harsh statement... What's so bad about package management? And what's useless about the security harness?
> 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…
- You also lose all ecosystem upgradability, as everyone is using pinned versions instead of SemVer ranges
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 w…
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
Earlier quoted context omitted.
They are not using their own bundler. They are using esbuild at runtime to generate bundles for individual islands when the process starts up. Then they store those files in memory in a Map. When the bundle files are requested, it just pulls the copy that was generated at runtime. Here is a link to the source where esbuild is used. https://github.com/denoland/fresh/blob/main/src/server/bundl... I personally think it…
Man the things that pass for innovation in the node-adjacent space continues to blow my mind. It feels like hte horrors of /r/programmerhumor meets generic internet hype-beast cycles.
Web code is made of duct-tape, nothing new.
Deno is a pretty big departure from Node in some respects as far as I can see.
I admit I haven't used it, but if it keeps only half of its promises to simplify frontend bundling and compilation/transpilation, I think it's innovative.