9 ms·

The attitude in this thread is pure shit. You DO NOT NEED to use bower or npm to install this, you can easily find the source and bring it in to your project i

The attitude in this thread is pure shit. You DO NOT NEED to use bower or npm to install this, you can easily find the source and bring it in to your project if you want to use this. Npm does provide you with a way to upgrade this without digging around, but you don't have to use it, so stfu, go find your file on the Internet, copy it to your css directory. A reason a flex grid could be cool, it provides you a standard across your application. When you one-off every time you need to have elements behave in a grid-like fashion, you run a much higher risk of ending up with inconsistencies. Unless you yourself write some code that reliably makes things behave like a grid, hey that's called a grid. I get that there are a lot of tools available, but this recent attitude of just slamming people because they created something that isn't aligned with your ideals is not healthy or progressive. There is no implication that because this exists anyone else has to use it. It's just code someone wrote and happened to end up here. Let it be.

Raphmedia 11y ago
I completely agree. We are in 2016. If you are a front end developer and you do not have at least one terminal opened in the front end directory of your website ready to run NPM or Bower and you are still managing your dependancies manually, there is something very wrong with your workflow.
- arrty88 11y ago
  How would you grab the latest versions for libs easily without a package manager?
  - Raphmedia 11y ago
    Sorry, I'm not sure that I comprehend your question correctly. Are you asking me how versions of a lib are managed in the package.json of a project? All of those are valid: { "dependencies" : { "foo" : "1.0.0 - 2.9999.9999", "bar" : ">=1.0.2 <2.1.2", "baz" : ">1.0.2 <=2.3.4", "boo" : "2.0.1", "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0", "til" : "~1.2", "elf" : "~1.2.3", "two" : "2.x", "thr" : "3.3.x", "lat" : "latest" } }
    - 91bananas 11y ago
      I think they're asking if not using npm or similar, what is the process for updating your local copy of a file/package. Which would be, go to where project is hosted, find out what version you're looking for, click until you find actual source, copy text or download file, move file from downloads to your repo, or paste in to a new file in your repo.
      - deleted 11y ago
        [deleted]
      - Alexqw85 11y ago
        Make works well for me... TMPDIR=$(BASEDIR)/tmp THEME=$(BASEDIR)/theme THEME_CSS=$(THEME)/css THEME_FONT=$(THEME)/fonts THEME_JS=$(THEME)/js VER_BOOTSTRAP=3.3.6 VER_FONTAWESOME=4.5.0 VER_JQUERY=2.2.1 updatedeps: $(TMPDIR) bootstrap fontawesome jquery bootstrap: curl -L -o $(TMPDIR)/bs.zip https://github.com/twbs/bootstrap/releases/download/v$(VER_BOOTSTRAP)/bootstrap-$(VER_BOOTSTRAP)-dist.zip unzip -j $(TMPDIR)/bs.zip bootstrap-*/js/bootstrap.min.js -d $(THEME_JS) unzip -j $(TMPDIR)/bs.zip bootstrap-*/css/bootstrap.min.css -d $(THEME_CSS) fontawesome: curl -L -o $(TMPDIR)/fa.zip https://fortawesome.github.io/Font-Awesome/assets/font-awesome-$(VER_FONTAWESOME).zip unzip -j $(TMPDIR)/fa.zip font-awesome-*/css/*.min.css -d $(THEME_CSS) unzip -j $(TMPDIR)/fa.zip font-awesome-*/fonts/*webfont* -d $(THEME_FONT) jquery: curl -L -o $(THEME_JS)/jquery.min.js http://code.jquery.com/jquery-$(VER_JQUERY).min.js
        gkya 11y ago
        This is actually a shell script in disguise. If this is all you do with make, I suggest you make this into a shell script: <Makefile sed -E 's/.*:$//; s/$|$//g; s/^updatedeps:.*/mkdir -p $TMPDIR/' > update-deps.sh BASEDIR=$PWD sh ./update-deps.sh Make is for generating output from interdependent input. It can be used for minifying your JS, or compiling your CoffeeScript in to js, or your sass (but that is handled mostly by respective compilers, tho I prefer running the compiler myself) (also, I don't use coffeescript or sass, so IDK if I'm mistaken).
    - 11y ago
  - 91bananas 11y ago
    Right? The point of a package manager that people seem to miss. You know, how it manages packages...
- techdragon 11y ago
  So Bower and NPM are now basically in control of modern JavaScript development... This is exactly the sort of thing us "JS dependency problem agitators/malcontents" are unhappy about. The vicious cycle of furious evolution in JavaScript is proving "too fast for comfort" for many of us. We do not all live entirely in the JavaScript ecosystem and no longer have the capacity to keep up with it. However remains the only language we can use in the browser so we are forced to use it and as it continues to accelerate, it becomes like an uncomfortably aggressive personal trainer screaming at us to "push harder" and trying to goad us into moving quicker. We do not have the choice to use JavaScript or not, so when it feels like is it angers us. We feel the parts of the JavaScript development community that push this ever faster, have taken no one else into account and are no longer interested in being good citizens of the web in cooperation with all us other developers. We feel understandably uncomfortable with this sudden "aggressive independence" in the JavaScript community. I'm quite sure a non trivial portion of the support for WebAssembly is because we want an alternative to JavaScript that enables us to escape from this situation. Many developers I talk to are eager to see their language of choice integrated via WASM so the are no longer forced to use JavaScript and much of the desire stems from being ever more unhappy with the direction of the JavaScript community. Everyone is entitled to their opinion, so many of us are glad we will soon have a place where our opinion matters too, not only the opinions of JavaScript developers.
  - qaq 11y ago
    Unless they are C++ developers they will have to wait for a long time :)
    - techdragon 11y ago
      You would think that, but as a python developer, I already know a number of projects that will be swiftly attempting to use every angle WASM gives them in order to enable lots of new ways to run Python more reliably in the browser.
  - pfooti 11y ago
    Sure, WASM will make things better, until you have to deal with library and dependency management in your WASM-llvm-deploy toolchain. I get that the javascript world moves pretty fast. On the other hand, what you seem to be saying is, "I don't understand this, _and I do not want to expend the effort to understand it_, so therefore it is bad". There's a lot of things I don't understand, and frankly don't have the time, energy, or training to understand. I leave those things to the engineers who actually worry about them. Example: I can write and optimize SQL queries, but I don't want to work on postgres internals. If you want to be a javascript developer, you should pay attention to the state of the art. FWIW: npm isn't in control of modern javascript development. You are still able to manually find new libraries, download them, add them to your assets directory, include them, and so on. This workflow never stopped working. All npm does is provide a centralized list of library versions and their locations, along with a syntax for declaring dependencies. My current project needs to do some image manipulation, so npm handles downloading and building the mmagic libraries for my development architecture. I could do this on my own, but this is just easier. If it's too hard for you, just do it the old-fashioned way. If you choose to publish a library and not provide npm/bower support because you're old-fashioned, however, don't expect wide adoption.
gkya 11y ago
Your attitude is infantile. There is a metastasis of so-called tools in the web-dev world nowadays. Setting up a moderate C project is way easier and less tools-involved than setting up a HTML-CSS thingy following the fashion of today. This one project in particular sports upwards of ten files to distribute what's worth a half page of CSS. If there's a library that I use across all my projects, then I just subscribe to its syndication (mostly VCS RSS feeds for me). And then I fetch it if the changes are of my interest, or there are bugfixes. All these other tools are completely superfluous. How many hours are lost in your shop setting these pieces of crap up instead of just downloading the file and putting it in your assets directory? The whole web dev business of today is a big stupid mess of people who have no clue what they're doing.
- 91bananas 11y ago
  Cool. A C project is usually just that right? A collection of C code, from one language, maybe two that are pretty similar? Where in our infantile web dev community we have to do things strewn across 3 languages at a minimum, and probably more if we're connecting to an api that is non-javascript. So, to me, it would make a ton of sense that a project integrating 4+ languages is going to take some time to set up. But that's just the cost of running in a browser. The amount of hours lost setting up "these pieces of crap" is effectively zero, I type `npm install --save <insert lib>` and I'm on my way. If I need changes that are of interest to me, I type `npm update <insert lib>`. But guess what, that's not the only way to do things. I also download files and drop them in. I analyze each situation and make a decision. I am glad you think we don't know what we're doing, because it shows that you have no idea what we're doing either.
- stephen_g 11y ago
  I do a lot of C (main day job - embedded systems stuff) and a fair bit of web (side business) and I find setting up NPM/bower is probably about the same difficulty as setting up a basic Makefile for a small C project if you have some experience with both. I like package managers because it saves me having to clutter up my git repositories with copies of my dependencies' JS files. You just have one package.json file for NPM, run npm install and you're done...
- 11y ago
creshal 11y ago
> I get that there are a lot of tools available Grunt gulp bower less sass npm node yeoman brunch underscore moustache… Whenever our frontend devs insist they need whatever deployed on all our servers yesterday, I nod and smile and count the days until they've completely forgotten about it and yell for the next shiney new toy that's totally going revolutionize JS development. This time for real. Meanwhile I'll stick to my makefiles, thank you very much.
- coldcode 11y ago
  Makefiles, too modern. I poke bytes into memory just like Woz did.
  - lisivka 11y ago
    I poked bytes into memory too (directly typing numbers from console or using BASIC), but I use everything my team wants to use (make, build scripts, docker, vagrant, grunt, gulp, cmake, autotools, rake, ant, maven, npm, bower, etc.) because it is easier to learn new stuff for me than to couch each member. Moreover, it makes my brain better. If you know your stuff deeply, then you will be able to achieve your goal with any of these tools.
- hyperpape 11y ago
  This is word-salad. You included underscore, which might as well be named "utils.js", alongside moustache, which is a templating tool, and Grunt/Gulp/Bower/npm, which are build or dependency management tools that have some real complexity. These things are not like each other! It seems like you're just complaining about a bunch of things based on little more than what their name is.
  - creshal 11y ago
    > These things are not like each other! It seems like you're just complaining about a bunch of things based on little more than what their name is. I only know the name, because they disappear faster from our tool chain than I (as strictly ops/backend person) can keep up with familiarizing myself with them. The tool churn in the frontend world is insane.
pfooti 11y ago
I think the central issue here is: javascript has only recently turned the corner of utility in most environments. It used to be the toy scripting language that you used in order to tie form fields together. I used javascript back in the day to send events to a java applet that handled rendering molecule pdb files (jmol). Nowadays, and quite suddenly, javascript is at the center of everything. Java applets? Flash? Everything's imploded. On top of that, we're revolutionizing the language (block-lexical scoping, classical OO syntactical sugar, standardizing import/export, promises, generators, async/await, optional type annotations) in a way that improves productivity and the reach of the language. There's a lot of churn in tooling and tools, because things are new. I've been doing software since before the STL and generics in c++, and I can say that I've seen this kind of churn before. It happens with lots of languages when they turn the corner in real exponential growth. I'd say it used to be the case that there were far fewer programmers in general, and they were a far more homogeneous lot than they are now (we still have a long way to go on that front, of course), so standardizing around autoconf and make was easier than standardizing around (say) ant vs maven or grunt vs gulp. To the original issue - I've been doing a lot of flexbox work lately, and one of the more annoying issues is dealing specifically with grids. If you just use flex-grow like a good flexboxer, stuff doesn't align well in columnar format on your page. Flexbox is great for some things, but handy macros for making a grid out of flex boxes are pretty useful. Useful enough that I ended up writing pretty much the same thing myself anyway, and useful enough that it makes sense to hoist some of that code out into a standalone library. That way, you can encapsulate fixes for browser quirks (shakes fist safariiiiiii!), and have the option to pull the whole thing into new projects or leave it out if you don't need it. People can complain about making a spiffy project page for a small library, but hey. People complain about a lot of things. Those kids, for example, on my lawn. I installed a motion-controlled sprinkler to keep them off, but those wacky kids are still on my lawn.

Raphmedia 11y ago

I completely agree. We are in 2016. If you are a front end developer and you do not have at least one terminal opened in the front end directory of your website ready to run NPM or Bower and you are still managing your dependancies manually, there is something very wrong with your workflow.

arrty88 11y ago
How would you grab the latest versions for libs easily without a package manager?
- Raphmedia 11y ago
  Sorry, I'm not sure that I comprehend your question correctly. Are you asking me how versions of a lib are managed in the package.json of a project? All of those are valid: { "dependencies" : { "foo" : "1.0.0 - 2.9999.9999", "bar" : ">=1.0.2 <2.1.2", "baz" : ">1.0.2 <=2.3.4", "boo" : "2.0.1", "qux" : "<1.0.0 || >=2.3.1 <2.4.5 || >=2.5.2 <3.0.0", "til" : "~1.2", "elf" : "~1.2.3", "two" : "2.x", "thr" : "3.3.x", "lat" : "latest" } }
  - 91bananas 11y ago
    I think they're asking if not using npm or similar, what is the process for updating your local copy of a file/package. Which would be, go to where project is hosted, find out what version you're looking for, click until you find actual source, copy text or download file, move file from downloads to your repo, or paste in to a new file in your repo.
    - deleted 11y ago
      [deleted]
    - Alexqw85 11y ago
      Make works well for me... TMPDIR=$(BASEDIR)/tmp THEME=$(BASEDIR)/theme THEME_CSS=$(THEME)/css THEME_FONT=$(THEME)/fonts THEME_JS=$(THEME)/js VER_BOOTSTRAP=3.3.6 VER_FONTAWESOME=4.5.0 VER_JQUERY=2.2.1 updatedeps: $(TMPDIR) bootstrap fontawesome jquery bootstrap: curl -L -o $(TMPDIR)/bs.zip https://github.com/twbs/bootstrap/releases/download/v$(VER_BOOTSTRAP)/bootstrap-$(VER_BOOTSTRAP)-dist.zip unzip -j $(TMPDIR)/bs.zip bootstrap-*/js/bootstrap.min.js -d $(THEME_JS) unzip -j $(TMPDIR)/bs.zip bootstrap-*/css/bootstrap.min.css -d $(THEME_CSS) fontawesome: curl -L -o $(TMPDIR)/fa.zip https://fortawesome.github.io/Font-Awesome/assets/font-awesome-$(VER_FONTAWESOME).zip unzip -j $(TMPDIR)/fa.zip font-awesome-*/css/*.min.css -d $(THEME_CSS) unzip -j $(TMPDIR)/fa.zip font-awesome-*/fonts/*webfont* -d $(THEME_FONT) jquery: curl -L -o $(THEME_JS)/jquery.min.js http://code.jquery.com/jquery-$(VER_JQUERY).min.js
      - gkya 11y ago
        This is actually a shell script in disguise. If this is all you do with make, I suggest you make this into a shell script: <Makefile sed -E 's/.*:$//; s/$|$//g; s/^updatedeps:.*/mkdir -p $TMPDIR/' > update-deps.sh BASEDIR=$PWD sh ./update-deps.sh Make is for generating output from interdependent input. It can be used for minifying your JS, or compiling your CoffeeScript in to js, or your sass (but that is handled mostly by respective compilers, tho I prefer running the compiler myself) (also, I don't use coffeescript or sass, so IDK if I'm mistaken).
  - 11y ago
- 91bananas 11y ago
  Right? The point of a package manager that people seem to miss. You know, how it manages packages...
techdragon 11y ago
So Bower and NPM are now basically in control of modern JavaScript development... This is exactly the sort of thing us "JS dependency problem agitators/malcontents" are unhappy about. The vicious cycle of furious evolution in JavaScript is proving "too fast for comfort" for many of us. We do not all live entirely in the JavaScript ecosystem and no longer have the capacity to keep up with it. However remains the only language we can use in the browser so we are forced to use it and as it continues to accelerate, it becomes like an uncomfortably aggressive personal trainer screaming at us to "push harder" and trying to goad us into moving quicker. We do not have the choice to use JavaScript or not, so when it feels like is it angers us. We feel the parts of the JavaScript development community that push this ever faster, have taken no one else into account and are no longer interested in being good citizens of the web in cooperation with all us other developers. We feel understandably uncomfortable with this sudden "aggressive independence" in the JavaScript community. I'm quite sure a non trivial portion of the support for WebAssembly is because we want an alternative to JavaScript that enables us to escape from this situation. Many developers I talk to are eager to see their language of choice integrated via WASM so the are no longer forced to use JavaScript and much of the desire stems from being ever more unhappy with the direction of the JavaScript community. Everyone is entitled to their opinion, so many of us are glad we will soon have a place where our opinion matters too, not only the opinions of JavaScript developers.
- qaq 11y ago
  Unless they are C++ developers they will have to wait for a long time :)
  - techdragon 11y ago
    You would think that, but as a python developer, I already know a number of projects that will be swiftly attempting to use every angle WASM gives them in order to enable lots of new ways to run Python more reliably in the browser.
- pfooti 11y ago
  Sure, WASM will make things better, until you have to deal with library and dependency management in your WASM-llvm-deploy toolchain. I get that the javascript world moves pretty fast. On the other hand, what you seem to be saying is, "I don't understand this, _and I do not want to expend the effort to understand it_, so therefore it is bad". There's a lot of things I don't understand, and frankly don't have the time, energy, or training to understand. I leave those things to the engineers who actually worry about them. Example: I can write and optimize SQL queries, but I don't want to work on postgres internals. If you want to be a javascript developer, you should pay attention to the state of the art. FWIW: npm isn't in control of modern javascript development. You are still able to manually find new libraries, download them, add them to your assets directory, include them, and so on. This workflow never stopped working. All npm does is provide a centralized list of library versions and their locations, along with a syntax for declaring dependencies. My current project needs to do some image manipulation, so npm handles downloading and building the mmagic libraries for my development architecture. I could do this on my own, but this is just easier. If it's too hard for you, just do it the old-fashioned way. If you choose to publish a library and not provide npm/bower support because you're old-fashioned, however, don't expect wide adoption.

gkya 11y ago

Your attitude is infantile. There is a metastasis of so-called tools in the web-dev world nowadays. Setting up a moderate C project is way easier and less tools-involved than setting up a HTML-CSS thingy following the fashion of today. This one project in particular sports upwards of ten files to distribute what's worth a half page of CSS. If there's a library that I use across all my projects, then I just subscribe to its syndication (mostly VCS RSS feeds for me). And then I fetch it if the changes are of my interest, or there are bugfixes. All these other tools are completely superfluous. How many hours are lost in your shop setting these pieces of crap up instead of just downloading the file and putting it in your assets directory? The whole web dev business of today is a big stupid mess of people who have no clue what they're doing.

91bananas 11y ago
Cool. A C project is usually just that right? A collection of C code, from one language, maybe two that are pretty similar? Where in our infantile web dev community we have to do things strewn across 3 languages at a minimum, and probably more if we're connecting to an api that is non-javascript. So, to me, it would make a ton of sense that a project integrating 4+ languages is going to take some time to set up. But that's just the cost of running in a browser. The amount of hours lost setting up "these pieces of crap" is effectively zero, I type `npm install --save <insert lib>` and I'm on my way. If I need changes that are of interest to me, I type `npm update <insert lib>`. But guess what, that's not the only way to do things. I also download files and drop them in. I analyze each situation and make a decision. I am glad you think we don't know what we're doing, because it shows that you have no idea what we're doing either.
stephen_g 11y ago
I do a lot of C (main day job - embedded systems stuff) and a fair bit of web (side business) and I find setting up NPM/bower is probably about the same difficulty as setting up a basic Makefile for a small C project if you have some experience with both. I like package managers because it saves me having to clutter up my git repositories with copies of my dependencies' JS files. You just have one package.json file for NPM, run npm install and you're done...
11y ago

creshal 11y ago

> I get that there are a lot of tools available Grunt gulp bower less sass npm node yeoman brunch underscore moustache… Whenever our frontend devs insist they need whatever deployed on all our servers yesterday, I nod and smile and count the days until they've completely forgotten about it and yell for the next shiney new toy that's totally going revolutionize JS development. This time for real. Meanwhile I'll stick to my makefiles, thank you very much.

coldcode 11y ago
Makefiles, too modern. I poke bytes into memory just like Woz did.
- lisivka 11y ago
  I poked bytes into memory too (directly typing numbers from console or using BASIC), but I use everything my team wants to use (make, build scripts, docker, vagrant, grunt, gulp, cmake, autotools, rake, ant, maven, npm, bower, etc.) because it is easier to learn new stuff for me than to couch each member. Moreover, it makes my brain better. If you know your stuff deeply, then you will be able to achieve your goal with any of these tools.
hyperpape 11y ago
This is word-salad. You included underscore, which might as well be named "utils.js", alongside moustache, which is a templating tool, and Grunt/Gulp/Bower/npm, which are build or dependency management tools that have some real complexity. These things are not like each other! It seems like you're just complaining about a bunch of things based on little more than what their name is.
- creshal 11y ago
  > These things are not like each other! It seems like you're just complaining about a bunch of things based on little more than what their name is. I only know the name, because they disappear faster from our tool chain than I (as strictly ops/backend person) can keep up with familiarizing myself with them. The tool churn in the frontend world is insane.

pfooti 11y ago

I think the central issue here is: javascript has only recently turned the corner of utility in most environments. It used to be the toy scripting language that you used in order to tie form fields together. I used javascript back in the day to send events to a java applet that handled rendering molecule pdb files (jmol). Nowadays, and quite suddenly, javascript is at the center of everything. Java applets? Flash? Everything's imploded. On top of that, we're revolutionizing the language (block-lexical scoping, classical OO syntactical sugar, standardizing import/export, promises, generators, async/await, optional type annotations) in a way that improves productivity and the reach of the language. There's a lot of churn in tooling and tools, because things are new. I've been doing software since before the STL and generics in c++, and I can say that I've seen this kind of churn before. It happens with lots of languages when they turn the corner in real exponential growth. I'd say it used to be the case that there were far fewer programmers in general, and they were a far more homogeneous lot than they are now (we still have a long way to go on that front, of course), so standardizing around autoconf and make was easier than standardizing around (say) ant vs maven or grunt vs gulp. To the original issue - I've been doing a lot of flexbox work lately, and one of the more annoying issues is dealing specifically with grids. If you just use flex-grow like a good flexboxer, stuff doesn't align well in columnar format on your page. Flexbox is great for some things, but handy macros for making a grid out of flex boxes are pretty useful. Useful enough that I ended up writing pretty much the same thing myself anyway, and useful enough that it makes sense to hoist some of that code out into a standalone library. That way, you can encapsulate fixes for browser quirks (shakes fist safariiiiiii!), and have the option to pull the whole thing into new projects or leave it out if you don't need it. People can complain about making a spiffy project page for a small library, but hey. People complain about a lot of things. Those kids, for example, on my lawn. I installed a motion-controlled sprinkler to keep them off, but those wacky kids are still on my lawn.