5 ms·

From my perspective, the main reason for most browser JS projects having a build system is to essentially concatenate modules and to transpile newer JS features

by baddox 6y ago

From my perspective, the main reason for most browser JS projects having a build system is to essentially concatenate modules and to transpile newer JS features so they work on older browsers. That’s really just not as crazy as you make it sound. I don’t know about the Linux VM stuff being part of a browser JS project, maybe I’m misunderstanding that part but it does sound crazy.

ori_b 6y ago
> I don’t know about the Linux VM stuff being part of a browser JS project, maybe I’m misunderstanding that part but it does sound crazy. A bunch of stuff I see comes with a dockerfile these days. While I get building in docker for reproducibility, kind of -- shipping with one is a pretty big red flag. It means that it's likely to be very painful to port the code out of docker and integrate it into some other build. Which means that it'll be painful to integrate it with other code. Leave the build environment set up to the users. Embrace build diversity, it makes your code less fragile.
- Someone 6y ago
  At my job, a colleague shared a solution for tunneling into servers that involved having a Docker image running for each server, with some tunneling tricks inside the image. Those are the times I wonder whether I’m getting old. I kept using a shell alias that does ssh -ND, even though that requires maintaining a config file. But on the other hand, is a dependency on having Docker available really worse for portability than having a dependency on having a reasonably standard Unix environment?
  - ori_b 6y ago
    > But on the other hand, is a dependency on having Docker available really worse for portability than having a dependency on having a reasonably standard Unix environment? I often need to run it somewhere other than docker -- possibly integrating it into a different program. Docker doesn't make this impossible, but it's a sign that portability was not considered when the code was written, and I'm in for pain.
- core-questions 6y ago
  > It means that it's likely to be very painful to port the code out of docker and integrate it into some other build. No it wouldn't. Dockerfiles are stupid simple. A bunch of ADD/COPY commands to add files, and a bunch of RUN commands that are basically wrapping shell scripts. Plus, find me a modern build system (CI/CD system, rather) that doesn't natively support Docker. It's become a lingua franca at this point. I just wish it was faster on its own without me having to do all the legwork of maintaining lower layer containers etc. to avoid lengthy package install times.
  - com2kid 6y ago
    I had a problem yesterday where I had so many docket images laying around from builds that starting a new container pegged my CPU at 100% and slowed everything in a docker container to a crawl. A colleague predicted the problem and I learned about one more bit of random fragility that exists in today's ecosystem.
    - rumanator 6y ago
      > I had a problem yesterday where I had so many docket images laying around from builds $ Docker system prune It makes as much sense to complain about Docker because you let images accumulate in your system as it would make to criticize file systems because you never emptied your system's trash bin.
      - com2kid 6y ago
        My file system doesn't peg my CPU when it gets 10% full. Why the hell should the very existance of unused docker images cause the single image I am using to peg multiple cores? And no warning was given. Heck if my hard drive gets close enough to full that it's gonna be a problem my OS tells me.
  - ori_b 6y ago
    > No it wouldn't. Dockerfiles are stupid simple. A bunch of ADD/COPY commands to add files, and a bunch of RUN commands that are basically wrapping shell scripts. Yes. And the code sitting beside them starts to make assumptions -- so when I try to port it to Android so that I can run it under the NDK, for example, it turns into a shitshow because I discover that the code depends on the quirks of the docker environment, and I need to untangle a whole bunch of issues to just get it to build on anywhere. Containers -- dockers, jails, zones, etc -- are useful tools, but I'd rather see them left up to the people doing deployment, rather than the people shipping libraries. As a library author, I don't know where people want to run my code, so I serve them better by keeping the code portable.
com2kid 6y ago
I was thinking server side. Client side Babel makes sense. And packagers make sense. And it all unfortunately makes sense, but that doesn't make it good. (Ok being able to try out new syntax with Babel is cool)
- baddox 6y ago
  What would make it good? If there’s a real problem, and you have a real solution that makes sense, what’s not good?

by baddox 6y ago

ori_b 6y ago

> I don’t know about the Linux VM stuff being part of a browser JS project, maybe I’m misunderstanding that part but it does sound crazy. A bunch of stuff I see comes with a dockerfile these days. While I get building in docker for reproducibility, kind of -- shipping with one is a pretty big red flag. It means that it's likely to be very painful to port the code out of docker and integrate it into some other build. Which means that it'll be painful to integrate it with other code. Leave the build environment set up to the users. Embrace build diversity, it makes your code less fragile.

Someone 6y ago
At my job, a colleague shared a solution for tunneling into servers that involved having a Docker image running for each server, with some tunneling tricks inside the image. Those are the times I wonder whether I’m getting old. I kept using a shell alias that does ssh -ND, even though that requires maintaining a config file. But on the other hand, is a dependency on having Docker available really worse for portability than having a dependency on having a reasonably standard Unix environment?
- ori_b 6y ago
  > But on the other hand, is a dependency on having Docker available really worse for portability than having a dependency on having a reasonably standard Unix environment? I often need to run it somewhere other than docker -- possibly integrating it into a different program. Docker doesn't make this impossible, but it's a sign that portability was not considered when the code was written, and I'm in for pain.
core-questions 6y ago
> It means that it's likely to be very painful to port the code out of docker and integrate it into some other build. No it wouldn't. Dockerfiles are stupid simple. A bunch of ADD/COPY commands to add files, and a bunch of RUN commands that are basically wrapping shell scripts. Plus, find me a modern build system (CI/CD system, rather) that doesn't natively support Docker. It's become a lingua franca at this point. I just wish it was faster on its own without me having to do all the legwork of maintaining lower layer containers etc. to avoid lengthy package install times.
- com2kid 6y ago
  I had a problem yesterday where I had so many docket images laying around from builds that starting a new container pegged my CPU at 100% and slowed everything in a docker container to a crawl. A colleague predicted the problem and I learned about one more bit of random fragility that exists in today's ecosystem.
  - rumanator 6y ago
    > I had a problem yesterday where I had so many docket images laying around from builds $ Docker system prune It makes as much sense to complain about Docker because you let images accumulate in your system as it would make to criticize file systems because you never emptied your system's trash bin.
    - com2kid 6y ago
      My file system doesn't peg my CPU when it gets 10% full. Why the hell should the very existance of unused docker images cause the single image I am using to peg multiple cores? And no warning was given. Heck if my hard drive gets close enough to full that it's gonna be a problem my OS tells me.
- ori_b 6y ago
  > No it wouldn't. Dockerfiles are stupid simple. A bunch of ADD/COPY commands to add files, and a bunch of RUN commands that are basically wrapping shell scripts. Yes. And the code sitting beside them starts to make assumptions -- so when I try to port it to Android so that I can run it under the NDK, for example, it turns into a shitshow because I discover that the code depends on the quirks of the docker environment, and I need to untangle a whole bunch of issues to just get it to build on anywhere. Containers -- dockers, jails, zones, etc -- are useful tools, but I'd rather see them left up to the people doing deployment, rather than the people shipping libraries. As a library author, I don't know where people want to run my code, so I serve them better by keeping the code portable.

com2kid 6y ago

I was thinking server side. Client side Babel makes sense. And packagers make sense. And it all unfortunately makes sense, but that doesn't make it good. (Ok being able to try out new syntax with Babel is cool)

baddox 6y ago
What would make it good? If there’s a real problem, and you have a real solution that makes sense, what’s not good?