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

211–220 of 224 posts

Re: You don't need a build step

#211

Post by tracker1 »

hobofan wrote: post #154
tracker1 wrote: post #151

Earlier quoted context omitted.

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

> Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with. It's still a win even if you consider only patch version updates. Without that, for a CVE in a dependency, every dependent package will have to update, and will first have to wait for the lower level to update and publish a new version. So for a dependency ~4 layers deep, with coordination and publishing lag in bet…

A lot of time that happens anyway... at least with npm... there are a lot of times you see warnings, that you cannot resolve because of a nested dependency that is more than a point release off.

Re: You don't need a build step

#212

Post by tracker1 »

phist_mcgee wrote: post #197
tracker1 wrote: post #142

Earlier quoted context omitted.

Had similar issues with linting/formatting... switched to rome.tools a couple months ago and really happy with the change. I'm really looking forward to that project's goals too.

Hasn't rome had some dramas in the past? I was under the impression that since it's such a large project, it is quite a risk to use it atm before it's fully ready. Happy to be proven wrong.

I'm not really sure, I haven't followed the development that closely... I know I tried it... and it was pretty close... when I was ready to switch, had done some testing, and had to adjust several of the defaults to be closer to the existing linter config. That said, the reformat/lint-fix was so fast, it wasn't that big a deal. Did it in two commits, one with just the linter config, another with the reformats in a separate commit.

The whole project can be scanned and reformatted and lint-fixes applied in under a second... the eslint config with TS took several seconds... as a precommit hook it felt pretty painful in practice, now you don't even notice it.

If they do as well for build options (once added), I'll be very happy indeed.

Re: You don't need a build step

#213

Post by yencabulator »

samjmck wrote: post #117
jstummbillig wrote: post #110

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?

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…

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.

Re: You don't need a build step

#214

Post by sitkack »

DoesntMatter22 wrote: post #208
sitkack wrote: post #156

Earlier quoted context omitted.

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

What do you think it is? 100k, 200k?

GP was humble bragging in a way that focused on them rather than the discussion. Deno's autoloading isn't targeted at a Google3 TS application that takes 8hrs to build.

Re: You don't need a build step

#215

Post by DoesntMatter22 »

sitkack wrote: post #214
DoesntMatter22 wrote: post #208

Earlier quoted context omitted.

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

What do you think it is? 100k, 200k? GP was humble bragging in a way that focused on them rather than the discussion. Deno's autoloading isn't targeted at a Google3 TS application that takes 8hrs to build.

On most weeks I'm doing 2k or better. So, assume 50 weeks a year, 100k per year. Assume most developers do at least 10% of that (which is crazy low, has to be much higher in general), so 10k per year. You have a 30 year career that is 300k in a career.

Even that is extremely low. That is only 37 lines of code per day. Anywhere I worked you are getting fired if you are only doing that (unless you are just bug fixing all day, etc).

Re: You don't need a build step

#216

Post by elendee »

jstummbillig wrote: post #110

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?

I think that people mistake building/ bundling js with compiling js. even when you use bundlers, the code still needs to be compiled by the JIT. so bundling is really kind of a weird step that makes web dev different afaik. they're trying to turn browser dev into a standardized scripting environment and stop the silly browsers from trying to innovate in what should be user-dev space. That's my idealistic take at least.

personally I've been using vanilla es6 for years and not bundling, because I dont care about mobile safari, and I love it.

Re: You don't need a build step

#217

Post by kerryoco »

rsp1984 wrote: post #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?

it has nothing to do with server side business logic. It's simply that javascripts package manager, npm, was widely adopted to server / node needs. And then the notorious "node_modules" folder, which was before handled by server compilation, became a part of clientside dev too because it had so many goodies in it, so now the client was de facto having to do the same build as the server, so, by "server side code", I think it's safe to say what they mean is "node modules".

Re: You don't need a build step

#218

Post by phist_mcgee »

tracker1 wrote: post #212
phist_mcgee wrote: post #197

Earlier quoted context omitted.

Hasn't rome had some dramas in the past? I was under the impression that since it's such a large project, it is quite a risk to use it atm before it's fully ready. Happy to be proven wrong.

I'm not really sure, I haven't followed the development that closely... I know I tried it... and it was pretty close... when I was ready to switch, had done some testing, and had to adjust several of the defaults to be closer to the existing linter config. That said, the reformat/lint-fix was so fast, it wasn't that big a deal. Did it in two commits, one with just the linter config, another with the reformats in a se…

The build step is the hardest of all.

Just look at vite, it's amazing progress, but getting it to work with legacy codebases is a nightmare.

Not having proper require support is a real killer.

My bet is in 5 years we'll have massive buy in to these one-stop tools, but until then, they don't fit the real world as well as i'd like.

Re: You don't need a build step

#219

Post by fennecfoxy »

Vaguely2178 wrote: post #181
ashishb wrote: post #162

Earlier quoted context omitted.

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

> 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! As I wrote elsewhere [1], Dockerfiles are not deterministic. The build artifacts that they produce are de…

>Mobile app users have different performance expectations. No one bats an eye if a mobile app takes several minutes to download/update, but a website that does so would be considered an atrocity.

Well if it updates in my face I'd be pretty annoyed. The mobile app thing only works when they update in the background/transparently.

Re: You don't need a build step

#220

Post by vanjajaja1 »

LunaSea wrote: post #147
vanjajaja1 wrote: post #143

Earlier quoted context omitted.

The world will take some time to adapt to correct security mechanics, just like all other software worlds did. The security harness is not only a security harness, its a whole layer that abstracts away access to the operating system.

But it's the wrong approach. The correct approach would have been through syscall blocking which is a much lower level.

I'm assuming you mean SELinux style sys call blocking. I think you need both - syscall blocking for the system/deno layer, which enables app layer security in deno itself. That would be the composition-over-inheritance / functional approach.
Post reply on HN