Live data from Hacker News

You don't need a build step

deno.com

51–60 of 224 posts

Re: You don't need a build step

#51
post #8

Earlier quoted context omitted.

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

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.

Re: You don't need a build step

#52
post #46

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]

Re: You don't need a build step

#53
post #22
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.

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.

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?

Re: You don't need a build step

#54
> 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?

Re: You don't need a build step

#55
post #49
post #40

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

There are good things and bad things about PHP. This is one of the good things.

Definitely! I'll make a small edit to my comment to make it clear I'm not dunking on the idea

Re: You don't need a build step

#56
post #53
post #22

Earlier quoted context omitted.

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.

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?

It's not just features, it's a 350kb js file you have to send over the wire [1] as opposed to pre-building and sending a tiny css file containing the small subset of classes you used.

Not to mention, I don't know exactly how it works, but I assume it's doing all that processing to convert classes in your HTML into CSS classes on the client side so it's probably less performant.

[1] https://cdn.tailwindcss.com/

Re: You don't need a build step

#57

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

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

Re: You don't need a build step

#58
post #44
post #19

[flagged]

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.

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.

Re: You don't need a build step

#60

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 think the benefits of leaning on a (very familiar) protocol instead of a central repository outweigh the risks you describe

Like you mentioned- mirrors could become more common, and relying on HTTP makes it incredibly easy to host your own mirror. And import-maps mean you can mirror anything and everything in your dependency tree

Let's not forget, back in the day every major site relied on a client-side request to a jQuery CDN :)

Post reply on HN