Hacker News Reader

Comment by 91bananas | Hacker News Reader

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.

View on HN

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.

How would you grab the latest versions for libs easily without a package manager?

Right? The point of a package manager that people seem to miss. You know, how it manages packages...

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"

  }

}

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.

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

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

No my point is redundant. How would one manage upgrading dependencies without using a package manager? Why would anyone advocate against a package manager, no matter what the size of the dependency is?

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.

Unless they are C++ developers they will have to wait for a long time :)

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.

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.

I hope the hyperbole as far as 'control' goes, is viewed as the half joke it was meant to be.

While I'm sure that some as you say "do not want to expend the effort"... I and many others do not have the time left in our days to expend the effort in. As you go on to say, an individual's time and energy are finite. In my case and many other developers cases, the thing we are skilled at is/was web development, which was fine until the effort necessary to keep up with JavaScript and 'client side web development' grew to outpace our remaining time.

I want to continue to be a web developer, I have years of practice with this... which apparently means fuck all to most people hiring these days because despite being a good python developer that knows my way around the Django web framework, I can't find the time to work on Django, all the other things I do, like the spare time I've spent learning Django's ORM well enough to begin trying to write a RethinkDB back-end for it... AND after all that, start to rapidly learn the last 3 years of JavaScript in order to catch up to other 'web devs' and become competitive in the job market as web developer again?

Because I don't live and breath Ember, Angular, React or whatever new one comes out tomorrow... I'm not a good web developer? "Web developer" suddenly transformed into "JavaScript Developer" while me and others like me weren't looking...? Last time I checked, the web is more than JavaScript, yet we are marginalised by the web development community because the bulk of them are off gazing ever deeper into their own navels. I don't even mean that insultingly, "navel gazing" as a euphemism for being 'introspective' is about the only way to explain the 'staring inwards' that seems to be going on in the JS community, the transpilers, then Babel, ES6, ES7, and onwards, before they are done with one version there are transpilers from the next ultra experimental one to come from the future, to the one from yesterday, in order to implement the one from last Tuesday... which is the one that transforms all my CSS into JavaScript... and I'm already losing myself in my description of how convoluted the ecosystem can get.

I'm quite sympathetic to your position. I'm someone who left software in the early 00s to take a career in academia only to see my Java and old-style C++ experience become more and more obsolete. I luckily managed to wiggle back in when I decided academia was no longer my thing.

From where I sit, though, it isn't necessarily about react, ember, angular, or whatever. It is about javascript in particular. The shiny parts of the webworld are moving from CRUD style server side apps to client side rendering and SPAs.

For regular CRUD apps and a lot of other places, a server language like Python, Ruby, or Java are still pretty useful. But it really does seem like the future is interactivity, which for the time being means JavaScript. Languages like Python are likely destined to be (modulo wasm) backend ones that generate API endpoints and straightforward, noninteractive CRUD pages.

Of course that definition of 'future' is fleeting. In a few years I'll be bemoaning the churn in whatever new language ecosystem has turned the exponential corner.

The choice of a package manager is on a project by project basis. It's not as if you were required to use Bower or NPM to manage your dependancies.

Those are simply two tools used by the JS community to manage its dependancies. There are a lot[1] of them.

Where I work, everything was pushed by the back-end guys for a long time. This made the front-end developer dependant on them. With tools that use front-end languages (JavaScript), the front-end team is now free to experiment with package management and build systems (Grunt.js, Gulp.js). This made it so that we now have a very complex but quick and useful front-end workflow. We wouldn't have this if we had not freed the front end team dependancy on the back end team for builds, dependancies, etc.

[1] https://www.npmjs.com/ http://bower.io/ http://duojs.org/ http://webpack.github.io/ https://github.com/componentjs/component http://enderjs.com/ http://jamjs.org/ http://volojs.org/ etc.

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.

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

Makefiles, too modern. I poke bytes into memory just like Woz did.

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.

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.

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

If only there was a standardized system for installing frontend and backend javascript libraries so that the devops people don't need to learn about the specifics of each library. We could call it something like the "package manager for libraries in node" or something.

I sure wish there was such a thing, all that curl|sh-ing is getting on my nerves.

> I (as strictly ops person)

Aha!

Vagrant, Docker, Chef, Ansible, Fabric, Puppet, Jenkins, Octopus, TeamCity, Sentry, SVN, Git, AWS, Azure...

We all have monkeys on our backs. We all search for the best tools to use to make our lives easier and our products better and more reliable. When something new or improved comes out, we evaluate it, we weigh its use against everything from performance to code quality to backwards compatibility to having everyone learn yet another tool/library. If the benefits outweigh the drawbacks, then we make the switch. If not, then we leave our tool chain as it is.

Are there people who blindly switch to the Next Big Thing (tm) every 3 months? Yes. But I've found that in general they are few and far between. Perhaps you happen to work with one or more, but know that the entire web-dev community discourages that behavior.

The web-dev community might discourage that, but in my experience (someone who does backend/analytics and some devops, and who occasionally needs to modify the front-end projects that communicate with said backend) every time I setup one of the projects for local development it's a dependency nightmare and a good couple hours of research to figure out how all these pieces work together.

We've done the jQuery -> Angular -> React mambo. The RoR -> Node.js mambo. The Grunt -> Gulp -> Webpack mambo. The underscore -> lowdash mambo... I could go on. That's without even counting the CSS related fads.

Another thing I've noticed is that we've gone from projects trying to optimize for minimal JS and are light on browser resources, to installing multiple megabytes of Bower/Webpack/NPM dependencies and pages that perform (pardon my French) like crap. Famously, one of our backend devs wrote a Chrome extension that would disable the animated backgrounds in a bunch of stuff because they sucked our laptops' batteries.

So I feel the pain of poster who said it's become almost impossible to support JS projects unless that's your daily job. The tool churn is too big and don't get me started on all the new terms ("isomorphic websites", "polyfills", "shims", etc.) that seem to pop up every couple months.

I understand it's growing pains of a maturing ecosystem, it's just that the churn speed is insane.

> Vagrant, Docker, Chef, Ansible, Fabric, Puppet, Jenkins, Octopus, TeamCity, Sentry, SVN, Git, AWS, Azure...

Fair point! Although I'm just as tired of the rat race there, too. Of all the things listed, we're only using Git. I've looked at most, but I'm not bothering implementing it unless it's a huge benefit over the status quo. Chances are, better solutions will be around before we've finished migrating to the last Next Big Thing. I wish development finally got that memo.

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.

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.

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

Relax with the name-calling. Is it really unfathomable that people work differently, and that some people find value in tools you don't use? I completely understand not wanting to use them, but the presumption that they are completely useless cruft that people only use because they're idiots who don't know what they're doing is truly condescending, and closes your mind to learning new things. There are real benefits to be had from frontend package management. And real problems. Don't begrudge other developers for evaluating them for their own uses and making a different choice than you did.

Reply on news.ycombinator.com