Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You don't need a build step

deno.com

Post reply on HN
Print view View original

11–20 of 224 posts

Re: You don't need a build step

#11

Post by djbusby »

dom96 wrote: post #4

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.

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)

Re: You don't need a build step

#12

Post by kldavis4 »

dboreham wrote: post #8
kldavis4 wrote: post #3

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).

"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.

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.

Re: You don't need a build step

#13

Post by pictur »

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.

Re: You don't need a build step

#14

Post by gremlinsinc »

vhiremath4 wrote: post #7

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…

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.

Re: You don't need a build step

#15

Post by qbasic_forever »

vhiremath4 wrote: post #7

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…

Deno caches your dependencies locally.

If you are building something that demands high availability you probably want to host the dependencies yourself though. Which is easy, you just copy them and serve them as static files (assuming their license allows that use).

Re: You don't need a build step

#16

Post by [deleted] »

dboreham wrote: post #8
kldavis4 wrote: post #3

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).

"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.

[deleted]

Re: You don't need a build step

#17

Post by gremlinsinc »

djbusby wrote: post #11
dom96 wrote: post #4

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.

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)

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.

Re: You don't need a build step

#18

Post by crdrost »

gremlinsinc wrote: post #14
vhiremath4 wrote: post #7

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…

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 i…

This exists and is part of the deno executable; see [1] for more info.

1. https://deno.land/manual@v1.31.1/tools/vendor

Re: You don't need a build step

#20

Post by qbasic_forever »

gremlinsinc wrote: post #14
vhiremath4 wrote: post #7

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…

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 i…

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_ch...
Post reply on HN