You don't need a build step • Hacker News Board

Re: You don't need a build step

#221

Post by fennecfoxy » Mon, Mar 06, 2023, 6:15 PM UTC

kevingadd wrote: post #66

mdaniel wrote: post #62

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…

Granted, we have all moved from receiving updates to languages/frameworks once every 1-3 years (C# etc) or C++ with 3-8 years and instead get them monthly (sometimes even daily).

Devs from the past who wrote chunks of FORTRAN that sat on a "dusty 386 in the basement for 30 years" are still around, what do they think of the constantly evolving field/goalposts vs more traditional, slower release cadence of languages/frameworks/software in general (afaik; I wasn't around for it).

Re: You don't need a build step

#222

Post by tracker1 » Tue, Mar 07, 2023, 5:34 PM UTC

phist_mcgee wrote: post #218

tracker1 wrote: post #212

Earlier quoted context omitted.

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.

Vite is definitely an improvement over what came before (Parcel can be nice too). And yeah, migrating an existing codebase can be difficult, especially when you have other integrations (storybook, etc) that need to line up as well.

Just updating libraries in use can be really painful if too much time goes by.

Re: You don't need a build step

#223

Post by danlugo92 » Wed, Mar 08, 2023, 3:29 PM UTC

elondaits wrote: post #25

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.

The reason for bundling is converting potentially hundreds of individual script files to an amount that’s more manageable with a browser, without suffering a cost from latency… not only optimizing code size. Also, besides tree-shaking there’s a big saving from minimization and removing development-only code.

Sadly there's lots of people are overoptimizing all of these things for apps that serve 10 users.

If you serve 10 million users every byte counts, but 10? Use the cdn.

Re: You don't need a build step

#224

Post by Vaguely2178 » Sun, Mar 12, 2023, 1:40 AM UTC

fennecfoxy wrote: post #219

Vaguely2178 wrote: post #181

Earlier quoted context omitted.

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

Well yeah if you had to wait for apps to update before you could use them you'd definitely be annoyed, but the beauty of mobile (and desktop) apps is that users don't expect to constantly be running the latest version of a given app, which means you can slowly update large apps in the background.

When you visit a website you expect to always be running the the latest version of that website. In fact, most users aren't even consciously aware of the fact that websites have versions at all.