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

201–210 of 224 posts

Re: You don't need a build step

#201

Post by moritzwarhier »

whstl wrote: post #194
deckard1 wrote: post #134

Earlier quoted context omitted.

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.

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

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.

Re: You don't need a build step

#202

Post by claytongulick »

simplotek wrote: post #158
dathinab wrote: post #149

Earlier quoted context omitted.

A good craftsman knows not to use bad tools.

> A good craftsman knows not to use bad tools. In your opinion, what's so wrong in prefering to just run your JS/TS code without having to maintain a build/bundling step? To me, Deno's approach is undoubtedly a killer feature with regards to the status quo of the whole nodejs ecosystem. Don't you agree?

Alternately, you can just stick close to standards and not really worry about it.

I write plain CSS.

I use Web Components as my unit of isolation, generally sticking with the light dom.

I have a small state utility [1] that I wrote years ago and works great.

I do have a build step before deployment, but I use vite during development so I have zero "make a change, wait, test, rinse, repeat" downtime. When it's time to deploy, vite build does the trick nicely.

I don't use frameworks. I don't use JSX. I don't use typescript, for types I use jsdoc in vscode which gives me 90% of the benefits of TS without the downsides.

My pages are light, fast and easy to maintain. I don't have to deal with painful build steps, or framework churn.

Debugging is simple. No multiple layers of transforms and sourcemaps, WYSIWYG.

I'm pretty passionate about the "keep it simple" philosophy.

I chose to innovate in the problem domain, not the technical one.

Anecdotally, I had a new developer join my team and he was initially very confused. He said "it's just so strange using this tech stack. You make a change, and you see it..."

I didn't know whether to laugh or cry.

[1] https://www.npmjs.com/package/applicationstate

Re: You don't need a build step

#203

Post by lern_too_spel »

inglor wrote: post #135
moritzwarhier wrote: post #123

Earlier quoted context omitted.

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.

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…

Lit? https://developers.google.com/marketing/engineering/librarie...

Re: You don't need a build step

#204

Post by claytongulick »

ashishb wrote: post #138

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!

Please tell me you're kidding.

Have you ever tried building v8 from source? Go ahead, give it a whirl and come back in a few days and let me know how it went.

Or .net? Which one you ask? .net framework? .net core? Mono? Which version? Which framework? Which OS? Enjoy tweaking assembly xml files?

Python? You mean one of the main driving forces behind the invention of containers because dependency installation is such hell?

Go? Well, actually it is better. So, that's one.

My point is, js isn't unique in having fragmentation. It is a bit unique in its pace of innovation, but that's a good thing since it's also probably the most backwards compatible ecosystem in existence.

Re: You don't need a build step

#205

Post by sam_goody »

irrational wrote: post #48

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

You can use Python or PHP or some other language that doesn't have a build system, and whose performance and security model bests that of server side JS. (Deno, Node, Bun, etc.)

I run one Node/Js server and several Nginx/Php servers.

When Node was released, it had better handling of multiple long-lived connections. Nowadays, support for SSE on Node trails all other servers, and the dream of "Isomorphic" code that doesn't need to be rewritten has not panned out (in JS, at least).

The main reason I could imagine someone choosing Deno now is that it is the tool they know best (such as someone fresh out of college). Which may not be a bad reason, but it is hardly the best tool for the job.

Re: You don't need a build step

#206

Post by [deleted] »

moritzwarhier wrote: post #201
whstl wrote: post #194

Earlier quoted context omitted.

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

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

[deleted]

Re: You don't need a build step

#207

Post by dathinab »

simplotek wrote: post #158
dathinab wrote: post #149

Earlier quoted context omitted.

A good craftsman knows not to use bad tools.

> A good craftsman knows not to use bad tools. In your opinion, what's so wrong in prefering to just run your JS/TS code without having to maintain a build/bundling step? To me, Deno's approach is undoubtedly a killer feature with regards to the status quo of the whole nodejs ecosystem. Don't you agree?

My comment was more about the saying of the parents comment then specific to deno.

What I mean is that a good craftsmen doesn't complain about bad tool because they choose to use good tools (or more precise appropriate tools for the job) not because they ad-hoc easily negate any drawbacks of bad tools(1). And if they use bad tools anyway they do so intentionally or because there is not other choice and in turn don't complain because it's pointless to do so.

So the saying in the op comment is IMHO misleading at best deceptive at worst. Furthermore it doesn't advance any discussion, only side track it.

I'm sure the deno specific workflow from the article is a grate tool for a lot of use-case. I'm also sure there are use cases where it will fall apart.

(1): Depending on what you do creating a decent result without good tools might literally be impossible no matter how good your skill is. Or it might not make too much of a difference and can be compensated by skill, it's all context dependent, like most things in live.

Re: You don't need a build step

#208

Post by DoesntMatter22 »

sitkack wrote: post #156
evmar wrote: post #116

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…

Is the article targeted at Google use cases? The vast majority of programmers probably write less than 50kloc of code in their entire life and work on projects with a handful of files.

50k in their entire life??? That's insanely low/inaccurate

Re: You don't need a build step

#209

Post by btbuildem »

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.

Re: You don't need a build step

#210

Post by pphysch »

aheieosnssisowi wrote: post #183
pphysch wrote: post #64

Earlier quoted context omitted.

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.

You can't see a good reason to validate form inputs client side and use the exact same validations server side?

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.

Post reply on HN