17 ms·

I'm still using Make for all my minification / bundling / test running needs. Now and again I think to learn some trendy tech then never get round to it. Next t

• timlyo 10y ago
  I used to use make for everything, although recently I've started using doit for some things. http://pydoit.org/ http://pydoit.org/
• noir_lord 10y ago
  Same with me except I'm using bash and the CLI to all the modern tools. In 6 months I'll still remember how bash works and I get super simple debugging since I can just echo out the command it was about to run and start poking. I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript.
  • dasil003 10y ago
    > I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Portability.
    • gbuk2013 10y ago
      This is a valid concern, if it applies to your individual scenario. Nothing wrong with using the right tool for the job.
    • Cacti 10y ago
      That's a load of crap, there's nothing portable about a JS environment that requires build xyz of browser pqr, plus the hardware requirements, bandwidth requirements, etc. Take any ONE of those away and you're hosed (e.g., try loading even a single web page from Amazon on 56k). Every technology of the past 40 years has claimed "portability" as its mantra, and yet here we are still.
      • dasil003 10y ago
        Sure, but the web is a unique portability story in the history of computing. Has any other platform been an open standard that ends up being table stakes for any new entrant? Think about it, if you try to make a computer without a web browser today, you'd be laughed out of the market.
        • ktRolster 10y ago
          Has any other platform been an open standard that ends up being table stakes for any new entrant? C, Java. Far more computers run C than run Javascript.
          • esrauch 10y ago
            Number of machines that can run code written in the language isn't really the best metric for realistic portability. Sure, your toaster might run C and not JS, but it isn't going on run your C anyway.
            • TeMPOraL 10y ago
              My browser isn't running my JavaScript, it's running yours. In fact, the capability to run my own code in my own browser is being slowly but systematically removed from the browser.
              • esrauch 10y ago
                When I said "you" I meant "the developer" not "the user": the class of devices that run C and not JS is also a class of devices that generally don't run third party code. If you aren't a hardware manufacturer (or trying to sell middleware to one) the fact the embedded systems run binaries that were programmed in C isn't in any way relevant.
                • c22 10y ago
                  If only that toaster had a web browser.
    • stymaar 10y ago
      In my previous job, we had some bash scripts for a lot of things. It worked pretty well among Linux and Mac users in the team, but one day we had a new developer who was a windows user … We rewritten all those scripts in JavaScript using Grunt. Maybe nowaday it's different thanks to Windows subsystem for Linux.
      • bigato 10y ago
        Wouldn't it be better for one developer to learn and adapt to the rest of the team? I don't get why all the rest had to adapt to this single person who didn't know shell.
        • Klathmon 10y ago
          There's a benefit to having multiple platforms on your development team if you are developing something for multiple platforms. It's too often I see projects with "supports Linux, OSX, and Windows" only to find that none of the maintainers actually own a Mac and therefore it is filled with bugs and often requires the user to "find their own dependencies". If we are talking days of time and not weeks, the benefits of making (and keeping) your whole system cross platform could pay off big time in the future when you or someone on your team wants to switch, or you just want to easily test on other platforms.
          • stymaar 10y ago
            Exactly: Having a developer working on windows was a blessing since it allowed someone in the team to test on EI11 before we shipped to the product team, and it really improved our reactivity on this plateform. It wasn't our main target since our product was using webRtc(i.e. Firefox and Chrome), but it was supposed to fail gracefully on IE.
            • nawitus 10y ago
              At least these days you can download VirtualBox images for free to test on IE11. But yeah, it's a luxury if there's a Windows developer that you can have fixing all the IE11 bugs ;).
    • scintill76 10y ago
      bash, make, and a POSIX suite probably run on many more platforms than nodejs does. There is the caveat that too many people think they're writing portable shell scripts etc., but really they only work with GNU tools on Linux or MacOS. Then again, the same probably applies to many JS build scripts that end up relying on OS-specific behavior somewhere...
    • afdsadf 10y ago
      I don't care whether or not this is a joke, it's hilarious.
  • adamsea 10y ago
    For projects with not-overly-complicated builds, I have had success writing each desired script as a shell script, but then calling said shell script with an npm script. The shell scripts are nice for longevity, self-documenting, and if you have to call them with non-javascripty things. Calling them with npm scripts is nice for consistency, readability for many devs, and some of the path-setting/node.js process.env-var stuff that you are able to do in an npm script.
  • clock_tower 10y ago
    I'm guessing it's the inner-platform effect in action, but I could have sworn that there's a more detailed name for it in reference to Javascript in particular -- something about systems always existing on the edge of acceptability or of legibility, or thereabouts. I think this was on Ward's Wiki, but I can't find it...
  • zaptheimpaler 10y ago
    >I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Oh if only this was a joke. No.. its happening. https://www.os-js.org/ https://www.os-js.org/ https://node-os.com/ https://node-os.com/
    • Animats 10y ago
      Right on schedule. Mandatory XKCD: [1] [1] https://xkcd.com/1508/ https://xkcd.com/1508/
    • jryan49 10y ago
      We'll know os-js is finished when they finally put in a web browser. :)
      • deleted 10y ago
        [deleted]
    • nitemice 10y ago
      The future is coming! https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript https://www.destroyallsoftware.com/talks/the-birth-and-death...
  • kbutler 10y ago
    bash -x script Echoes all the commands for you for easier tracing/debugging...
    • noir_lord 10y ago
      Neat, always nice to learn new things :).
  • adrianratnapala 10y ago
    > I'm still not sure why the JS community seems determined to slowly bootstrap an OS in javascript. Well it worked for Emacs didn't it?
    • TeMPOraL 10y ago
      It works for Emacs because it gives everything a consistent yet very powerful user interface, that facilitates heavy interoperability. In fact, that interface is more consistent and more powerful than most people have in their operating system. Browsers, on the other hand, promote the exact opposite - inconsistent and weak interfaces, and no interop.
    • marcosdumay 10y ago
      You joke, but Emacs commands just interface the standard tools on your system, not replace them. And yes, Emacs programs get deprecated fast (compared to UNIX programs, they are way, way slow compared to JS code), but somehow people don't suffer to update them (mostly because people developing for Emacs know about that "compatibility" word).
• tmaly 10y ago
  same here, I use Make for everything on my projects
• ktRolster 10y ago
  An advantage of using make is if you come back to a project a year later, you don't need to remember how to build the thing. It's documented in the makefile.
  • slmyers 10y ago
    How does that differ from saying the same thing about say webpack -- ie, "the build is documented in the webpack config"?
    • ktRolster 10y ago
      Makefiles are more stable, webpack just went through a breaking change to 2.0. Makefiles are more versatile, they can be used not just for Javascript files, but for anything. I have a django project that uses lib-fann on the backend, and Selenium for data collection. I wish I had put that into a makefile because I can't remember the commands I used to build it, and now I have to take the time to go figure it out. Makefiles have conventions for not just building, but also running: "make all" to build, "make run" to run, and if you have an unusual project, you can get plain "make" to print out out some documentation explaining what to do. Webpack has webpack-dev-server but then you have to remember that command. Ultimately a lot of that could be had by a README file, of course, but Makefiles are easier.
      • komali2 10y ago
        vim readme.md "To run, use 'npm run'. To develop, use 'npm run dev'. To test, use 'npm test'." Or, open up package.json and see what scripts are there... I don't get how that's any different? Why wouldn't you have scripted all that?
        • hoorayimhelping 10y ago
          I script it that way and then add a makefile on top of it so that it's conventional and handles things like envvar setting. build: NODE_ENV=production yarn build:server NODE_ENV=production yarn build:client test: NODE_ENV=test yarn test
• tannhaeuser 10y ago
  That's what every sane developer does and has been doing since the beginning of Node.js including tj (of express.js, koa, ... fame) [1] so you're in good company. I remember a hilarious comment about "build systems becoming obsolete in year" (supposedly referring to the like of webpack, babel, grunt/gulp/broccoli, css.next if anyone is actually using it, etc.). The newest trend as of a year ago is to ... use shell scripting [2]. [1]: https://github.com/tj/mmake https://github.com/tj/mmake [2]: https://medium.freecodecamp.com/why-i-left-gulp-and-grunt-for-npm-scripts-3d6853dd22b8#.46l5dorj2 https://medium.freecodecamp.com/why-i-left-gulp-and-grunt-fo...
  • nawitus 10y ago
    In my experience npm scripts become way too complex on real world applications. But maybe I simply work on apps complex enough for this to become an issue. I've used grunt, gulp, webpack and npm scripts in multiple projects. Still not sure which is my favourite, probably gulp.
  • deleted 10y ago
    [deleted]
• komali2 10y ago
  Meh, we use make for our app, works just fine. We do wanna switch to Webpack though because it's starting to get... messy.
  • shakna 10y ago
    Why not multiple Makefiles?
• david-given 10y ago
  I've found that too much JS stuff produce multiple output files for make to be really comfortable --- make's support for multiple output files is very rudimentary and unless you follow the insanely complex and undocumented procedure to the letter, builds fail under obscure and almost impossible-to-debug circumstances. I've had success with ninja, although the scripts are a bit long-winded.
  • flukus 10y ago
    How long are the builds? If it's not long then you could not worry about outputs and incremental builds and/or only worry about it where it makes sense.
• deathanatos 10y ago
  Same here! It does its job well. It frustrates me, however, that some of the JavaScript tooling (in particular, bundlers) are incapable of outputting their dependency tree. It makes efficient builds much harder, as you now need to manually track the dependencies of various files. Essentially, the equivalent of `gcc -M`.
• andreareina 10y ago
  I was just recently in the position of having to figure out a "modern" javascript workflow. After getting over my stupefaction that modular js requires compilation, I ended up with a Makefile, ./src, ./lib, and ./bin.