Grd – A CSS grid framework using Flexbox in 512 bytes gzipped | Hacker News Reader

Grd – A CSS grid framework using Flexbox in 512 bytes gzipped

1000ch.github.io

196 points1000ch150 comments

I genuinely don't understand CSS 'grid systems' in a world of border-box and flex by default.

If you want to put things beside each other, make them whatever widths you want and have a flex row.

What do 'grid systems' add apart from visual classes in HTML and negative margin hacks?

Agreed. I used to use grid systems, but being able to wholeheartedly embrace flexbox and border-box has meant that I really don't need to use them these days. Want to do percentage width and fill the rest of the container? Easy-peasy. Want to not specify specific widths but make one thing bigger than another in a relative way, that adapts to the viewport powerfully? No problems.

Hell, the only reason I use Bootstrap is for it's buttons and forms, etc. which nowadays I've replaced with PureCSS; and the best part about PureCSS is that I can use the bits I want and ignore the rest. Bootstrap can also do that, but requires a preprocessor like Sass or Less (v4 and v3 respectively).

Not really. You can customise Bootstrap online and download the compiled CSS:

http://getbootstrap.com/customize/

Just untick the boxes for the stuff you don't want, and hey, Bob's your uncle. No Less or Sass required.

Sure! But using Bootstrap as a dependecy via "npm" makes that a bit more annoying; and PureCSS does that out of the box via that route, which is great.

For clarity sass and less are not required locally to run bootstrap, if you wish to build it from source then they are required.

its button etc.,

The "grid" is a graphic design principle [1] that existed long before CSS. You can implement this in CSS with flexbox or something else. If you don't care about vertical alignment of elements at different heights on your page then you probably don't need a grid framework.

[1] https://en.wikipedia.org/wiki/Grid_(graphic_design)

I'm familiar with grids as a design profile. My point was that most 'grid system' libraries add no value and make some things worse.

Browser support. Desktop Safari's flex support was notoriously buggy, but I see that they've fixed it with El Capitan. The next major release of Bootstrap will have a flexbox mode AFAIK.

http://caniuse.com/#feat=flexbox

There's still some pretty nasty flexbox bugs in Safari that are fixed in WebKit nightly, but not released yet. I hope 10.11.4 and 9.3 fix these issues.

I'm not yet sure if we should abandon grids completely. I've tried flexbox-only with one project, but I found it to be repetitive and more time consuming than starting with a grid based on flexbox. A simple flexbox grid is my way to start a project now as you need a lot of it anyways.

I started out with simple flex, then moved to a flex based grid library because it solves subtle gutter/margin alignment issues that appear with out of the box flex rows.

Easy vertical centering.

You might wanna look at this: https://css-tricks.com/snippets/css/a-guide-to-flexbox/

Yes, the whole point of Flex was to replace grid systems. I really don't see the point for a CSS library to wrap flexbox - All it does is dumb down flexbox for people who are too lazy to learn it.

There are enough common patterns and frequently used combinations to make a flex box based library a good idea. It's DRY

This is ... confusing.

a) The concept of a typographic grid is a print layout design tool fundamentally unsuitable for coding flexible component-based layouts on today's web (it probably always was, but talking about a "grid" can give designers an air of technical mystique they quite enjoy ;)

b) Flexbox was invented to move beyond the grid. We don't want or need a grid anymore.

c) It takes less than 1 day's effort to learn the vanilla CSS flexbox API and you can re-create this "grid" if you really need it with a few lines of plain CSS. No framework dependencies, other developers don't have to learn the framework, and no polluting your markup with global utility classes.

Can class names begin with a hyphen followed by a number?

This SO answer says [1]:

> a name must begin with an underscore (_), a hyphen (-), or a letter(a–z), followed by any number of hyphens, underscores, letters, or numbers. There is a catch: if the first character is a hyphen, the second character must be a letter or underscore, and the name must be at least 2 characters long.

[1]: http://stackoverflow.com/a/449000

Which references the CSS Grammar spec [2].

[2]: http://www.w3.org/TR/CSS21/grammar.html#scanner

I think the best reference would be the actual (main) spec since the grammar spec says it is kind of a "superset" of the actual specification, i.e. not always strict enough. Identifiers are specified here: https://www.w3.org/TR/2011/REC-CSS2-20110607/syndata.html#va... (two hyphens at the start are also not allowed, in contrary to the "SO answer" cited).

That answer clearly states that -- is not allowed.

I will make a flexbox framework with 100 bytes gzipped that contains one thing: display: flex. Wait.. flex.io is already gone? Nvm.

This looks nice and simple!

I've been enjoying Lost (https://github.com/peterramsing/lost) with PostCSS for grids recently - it has Flexbox support which works well and keeps grid class names out of my markup.

Thanks. I'm working on something new. Should be done this weekend. Stay tuned.

Re: this post

Grd doesn't do anything interesting at all. Everyone is blindly obsessed with flexbox. Grd doesn't even concern itself with gutters.

Here's something I cooked up in 5 minutes that does more with less code: http://codepen.io/corysimmons/pen/eZgZzz?editors=1100

Without being able to change amount of elements per row depending on viewport width I don't see this picking up.

Good point. I actually don't understand its behaviour in regard to viewport width. Also, there are actually no media queries used in the CSS file.

Pretty trivial to extend it.

Pretty trivial to write it all from scratch.

width and media queries do that.

Perhaps my CSS is rusty and not keeping up with the new syntax but I need to know what with that "\" syntax?

   .Grid.\-stretch  { align-items: stretch; }

I think they're just escaping the hyphen, I don't know of any hack that might use that [there are many "backslash hacks"] other than perhaps for IE5.5 (on Mac?). You're not supposed to start class names with hyphens by convention so there could be a pre-parser/checker that complains if it's not escaped?

I thought classes starting with an hyphen are reserved for browser vendors[1]. Maybe this changed since the last time I checked the spec.

[1] = https://www.w3.org/TR/CSS21/syndata.html#vendor-keywords

That's for properties and keywords, not for class names.

Afaik it's just for escaping `-`

It means that this `.-stretch` needs a class `.Grid` on the same element

I like it. It'd be easier to play with the demo if there was some more space beneath it.

This seems to defeat the idea of flexbox. Grid systems were needed for old CSS, but with the powers of flexbox, we better off using it directly then using it with a grid system, as the grid system will be limiting and will not give any significant comfort.

This lib will only work on the latest browsers.

The source leverages calc for simple width percentages, so on android browser below 47 these values won't calculate at all: http://caniuse.com/#feat=calc.

> Partial support in Android Browser 4.4 refers to the browser lacking the ability to multiply and divide values.

Why wouldn't the author change this to:

.Cell.\-1of12 { width: calc(100% * 3 / 12); }

.Cell.\-1of12 { width: 25% ; }

It seems silly to go through the trouble of installing a lib when it gives you less browser support than flexbox itself.

The "dist" version has all this removed.

It's a pretty odd use for a preprocessor.

Each mixin is only used once (so why bother?) and the calcs are turned into percentages by the compiler (so why bother?)

Is there a way to work around this limitation?

I have a CSS code that looks like this for a good reason:

    left: calc(100% + 2em)

that I'd like it to be changed to support legacy stock Android browsers.

I've developed a heuristic that any web project posted to HN that mentions its size in the headline is probably a half-assed copy of something with better documentation, developer-mindshare, browser-support, testing, bug fixing etc.

Size and therefore speed is important on the web, but it seems an easy mental trap to optimize it at the expense of the other important things.

file size appears to me as a completely random metric to measure your code against. With the overhead associated with establishing a http connection, the actual byte-size is most likely of little importance. In fact, if this goes over TCP/IP (Which HTTP usually does), isn't there a frame size of some 1500 bytes?

Ever ever since I found out IE10 and IE11 have several big issues with Flexbox [1], I've been avoiding using it in production.

[1]: http://caniuse.com/#search=flexbox

Or you could just use tables for tabular (another word for a grid) data and use native flexbox for other stuff. Besides, CSS Grids level 1 will be coming to browsers soon anyway.

I get 'Uncaught SyntaxError: Unexpected token ILLEGAL' on Chromium Version 37.0.2062.120 Ubuntu 12.04 (281580) (64-bit)

The live demo doesn't work for me

Your old browser version doesn't support template literals.

I'm fine with the "this tiny codebase is DRY" justification (though how hard is it to be DRY with 37 lines...? DRY in the sense that it proves DRY-ness is a concept of computer science??? DRY in the sense that it conceptually overlaps with what other developers/programmers in the field are describing in their systems? DRY in that it appeals to a handful of niche programmers?), I'm fine with the package management justification (because it makes continuous integration possible with upgrades); I'm fine with the "I don't need to be a Pointer-dexter Programmer to write software". The problem is the "cute name" justification, or the idea this is a "good practice in the honored tradition of DRY".

The only problem here is that "who cares" if it is a "cute name". This isn't really DRY in a non-trivial sense. I mean, yet another grid system that calls grid-like things "grids". Yergh! Go read Brian Cantwell Smith's paper on "semiotic alchemy". More practically, I would say that all the points about filesize and what not are sadly irrelevant as true sources of anger. I honestly see this as no different as someone getting angry with someone else because they bought a foreign part to put in an American car. More puffery!

We have 7 "big" problems in CSS today:

    Global Namespaces, 
    Dependencies, 
    Dead Code Elimination, 
    Minification, 
    Sharing Constants, 
    Non-deterministic Resolution, 
    Isolation.

What happened to the pursuit of truth? Alright. You put a framework on your résumé? But are you a computer scientist? Are you defending an idea? Or simply leveraging an old one?

We take and depend on a lot of code today. But now we are taking and depending on higher order concepts or principles to give the illusion of pursuit... of something.

This is a "grid system" only in name insofar as it surely is detached from the idea of why grid systems were invented, mostly assuredly, to solve problems.

The "filesize" problem of CSS is like the "filesize" problem of Bitcoin. It's just that nobody really likes CSS or knows they can build Turing Machines in it, so they hate you for it. Whereas in Bitcoin, it gets you a seed round to test yr vaporware. At least these little CSS publications don't cost society that much, I guess..

Typically when I venture down this path of "system building" in CSS land, I use Organic CSS[0] because it promotes fun, thinking, creativity, and gives me a scientific scheme within which to treat those 7 problems listed above.

Does this grid framework solve any of those problems listed above? Is it even concerned with them? Are devshops aching to refactor to the next tiniest grid system? Are we really looking to shave off submilliseconds from our HTTP requests? I mean, we have HTTP/2... so do those submilliseconds really matter these days?

[0]: http://krasimir.github.io/organic-css/

Are you sure you're in the right place, spammer?

Sup, Qt. How u iz?

We will be moving to this immediately

My tagline would be -

er mah GRD, it's amazing!

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.

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.

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.

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.

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.

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?

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.

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.

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

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.

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.

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.

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.

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

I came here to see really cool comments on an interesting project and I see hostility.

This is why I don't hang out with developers

You're bound to find this sort of response in any professional circle that deeply cares about the tools it uses to do its job.

I think we're blessed that the discussions in this forum are usually constructive & critical but respectful at the same time.

I find myself making negative comments more than I would like. But these happen to be about points that are the most interesting to discuss. The resulting discussion is very useful. What am I to say about things I like? +1 adds nothing to a discussion.

There's a way of criticizing that still honors—or at least doesn't trample—the creative spirit in the work being criticized. That's what we're going for here. Substantive criticism is helpful because it adds information. Snarky dismissals merely puff up the criticizer. As long as that's not your intent, your comments are likely to be fine.

Definitely. I would like to think that what I call negative can also be called substantive criticism.

Where does this recent comment of mine fall? It is snarky but isn't it also substantive? I guess I could have left out the snark.

"I love it. We had servers, then we had clouds, and now we have personal clouds. Uh, isn't that a server?"

I agree. I just wished there were more nuggets of encouragement in this sea of criticism.

I don't think this is the place to seek cool comments. I come here precisely for the technical discussions.

    Syntax error at line 109 while loading: unexpected character: U+0060
       grid.className = `Grid ${align.value}

Web design today: NPM or Bower installation for a 37 line CSS file. When will this insanity end?

The framework itself looks handy and simple enough, but there's probably already about 10 other flexbox layout frameworks out there that works just as good too. Here's another one: http://gridlex.devlint.fr/

Yes, how "insane"

I actually think it was nice of the developer to say "Hey, you can install this with npm or bower". And if you don't like either, you can grab the source yourself. Or you can just not use it and move on.

I wouldn't use this myself just because I think using flexbox on its own is great. And there are plenty of problems in web development today. But calling it "insane" just feels like you were looking for something trivial to get upset about.

Excess of tools is not trivial, it's the main problem with web development today, IMO.

They are two widely used tools in the web dev industry. The developer of this CSS framework is simply supporting users of those tools, they're not deserving of this criticism.

But I do agree that web dev tooling could use a lot of work. Grd did not set out to solve that.

I agree it's not "insane" to include NPM, but I do feel a trend of over complicating things that should be simple.

A 4 page static website, for example, shouldn't need model view controller, package manager, routing, etc.

How is a simple package.json file included in the repo "over complicating things"?

The question is at which point you feel the need for a package manager.

I tend to err on the side working as simple as possible. Adding tools only when things seem like they can get out of hand, not before.

What's wrong with that? It's a dependency. What else do you want to do, just load it in a `link` tag? Then here you go:

https://raw.githubusercontent.com/1000ch/grd/gh-pages/dist/g...

I'm honestly not seeing what is there to complain about.

That actually isn't a good idea. https://rawgit.com/faq

So use Bower/NPM then. Or use npmcdn.com.

https://npmcdn.com/grd@1.2.0/dist/grd.css

I meant that you can download it from there and use it locally.

It's 37 lines of wrapper CSS. You don't need a library with a cute name and a package manager and an HN thread and a fucking logo to do something that you can replicate in a minute.

Imagine someone posting a repo of their alternatively-named C integer typedefs on here.

  nt
  An integer framework using stdint.h

  Simple
    It's just a header file
  Light-weight
    It's like 10 lines
  Flexible
    You can do anything

  ...
  #include <stdint.h>
  typedef int32_t nt32;
  ...

How is that a problem again? You find it overkill and ridiculous, OK, but how is that a problem? Just download the file the way you want and you can forget about all the trauma you encountered when you had to see a logo

It's not a "problem." It's just silly and indicative of the immaturity of web developers.

There was once a time when you could mock ridiculous things without being "traumatized" by them.

You can do ANYTHING at zombo.com!

That I shouldn't need to install NPM or Bower to download a fucking half a Kb of CSS is what is the complain.

It's a clear sign of people with no clue about proper software engineering, which is glaring in today's front end world where dependencies and tools have gone amok to manage mere hundreds lines of CSS or Javascript.

Just provide a download link to the min file and be done with it.

Wow, check your anger and your prejudice. Yes, the site could do with a clear link to the source, but most software engineers are familiar with the 'github-link-in-top-right-corner' pattern, so it shouldn't be a problem even if you're ideologically opposed to using more robust alternatives.

I see anger but I'm struggling to find "prejudice" here.

"All these bloody young people don't respect my JAVA Enterprise BSServiceFactoryFactory experience".

Similar to the prejudice that every high-level programmer from so many idiot low-level programmers who think because they mess about with pointers all day they are "real" programmers.

"people with no clue about proper software engineering, which is glaring in today's front end world"

Providing an option to install with npm simply makes it more convenient for those devs who already use it - which surely is not an insignificant number. Nothing is requiring you to work that way or stopping you from downloading the files manually.

I just started to use npm (and indeed package managers in general) for my work recently and it's opened my eyes. It makes sense to me that this will be the preferred way of working for every dev/designer. Just as we mostly all use git now. It's hard to imagine that time when we just shared files via FTP and didnt use version control. I'd encourage anybody like me who was resistant, or working on a large code base that doesn't use those tools - give it a fair try on a side project.

> That I shouldn't need to install NPM or Bower to download a fucking half a Kb of CSS.

And if you entire dependency chain for your project is half a Kb of CSS that's a valid point, I'd like to see that project though.

Dependency management for front-end/browser assets is sorely needed, the problem at the moment is that we have too many of them and no clear standards have emerged yet, npm/require() is as close as we've got though and I'll take it for now.

I have a lot of dependencies. Sometimes they have dependencies. Being able to update them all at once is great. Same reason I like apt, yum and the various app stores.

you don't _need_ to, its simply best practice.

have you ever taken on a code base with thousands of lines of copy pasta code?

tried to update or workout dependencies/conflicts when the dude before you just dumped a bunch of jquery plugins (some hacked) in a directory?

give me a package.json any day! mmmm.. structured data.. nom nom nom

>its simply best practice.

Some of the times. What I am bitching about is that I can't get around NPM/Bower and other bullshit, I have to use it for a lot of these libs, regardless of me needing them.

I am the only one who should judge what are the best practices for the project I am working on, not some clueless Javascript hacker (cheap shot I know). What I'm complaining about is that front end "developers" seem to all be unaware of a few staple principle of software engineering: keep it simple and right tool for right job. I've used NPM, Bower, Gulp, and others, when it was needed but from over a decade of experience in the web I can assure you that 90% of the time, it's superfluous.

It generates developers who don't know how their own code works or interact, and who for the major part end up over engineering everything they touch for no goddamn reason.

Plus I always end up spending more time dealing with those stupid tools than coding, and if Java taught me anything it's that this is the clear sign of a very ill and insane dev culture.

> What I am bitching about is that I can't get around NPM/Bower and other bullshit, I have to use it for a lot of these libs, regardless of me needing them.

You do realize that downloading the CSS/JS for these libs is trivial, nothing is forcing you to use Bower/NPM/<insert lib management tool here>.

I've often wondered why this sort of overengineering, excess, and heavy "preaching" of "best practices" is more prevalent in some software ecosystems than others; the best hypothesis I can come up with is that it happens because the barrier to entry is low and the problems to be solved are easy, which encourages people to add complexity until it's not. Furthermore, the simplicity causes opportunities for something like a religion to develop: you don't have to think, just believe and follow. It's cargo-cult. Some fact that worked for someone gets parroted as "best practice" and then, despite how suboptimal it could be for them, others pick it up and think it's the "best" solution, and it works for them, propagating the belief. There's little questioning, because those who believe don't themselves actually understand enough to.

You may find this article to your agreement: http://www.satisfice.com/blog/archives/27

Go to the Github repo --> find the minified file --> download

Not that hard right?

Clearly you dont understand dependency management. Maybe you should look to your own practices, as you simply come off as a luddite to me..

In this case, I too have to question the NPM / Bower (yes, it's optional, but IMHO shouldn't be needed). The CSS file is basic flexbox. I think it would be a bit embarrassing if you were a web developer, and had to npm / bower a library to avoid writing trivial flexbox CSS.

This isn't a complicated, full featured grid... those definitely need dependency management.

If you are new to flexbox, the CSS file is a helpful demonstration I guess. Flexbox is way more powerful, and far more flexible, than this grid alone though.

> I think it would be a bit embarrassing if you were a web developer, and had to npm / bower a library to avoid writing trivial flexbox CSS.

Why does everything have to be this huge library to be used? Why can't I pull in 30 small libs that composed? I'm a Node.js developer, our ecosystem is built around small focused modules that do one thing and one thing well. Sometimes you can write the 1 line yourself, or pull in a module and know that if anything changes that could affect that line of code, someone somewhere will notice it before you and update the module. Congratulations you just saved yourself hours of debugging because someone else did it for you.

Libraries always are a trade-off between the flexibility of developing it yourself versus the time saved relying on other people's work. To me, it's less the size of the code than the functionality that matters. Code size is not necessarily an indicator of how hard it is to solve a problem after all.

In this case, however, we are talking about pretty basic CSS. There are some standards for page layout, but there is no One True Way to design a web page front end... all designs are different. Small CSS like this (as a library) in effect make design decisions for you and I don't think CSS is difficult enough for this to be justified.

As an example (without manually editing the CSS at least, which defeats the point of the NPM / Bower installs), this grid CSS locks you in to arbitrary divisions of 12. What if your grid requires 5 evenly spaced columns? You can't do that.

> I don't think CSS is difficult enough for this to be justified.

YOU don't think it is. Neither does my buddy who works in CSS/SASS, but I do. Because I don't do styling. I'm mostly a backend developer.

> What if your grid requires 5 evenly spaced columns? You can't do that.

I just did it easily by 5 elements and putting them as `-fill`. 5 evenly spaced columns. I wouldn't have been able to do that without this lib because I don't know CSS that well, nor flexbox. This library just saved me tons of time, just to do what you said it can't.

Its still a case of copypasta, and is reminiscent of the cowboy PHP development prevalent during the early 00s.

Granted, in this case the library is exceptionally lightweight, but its still a 3rd party dependency and should be treated as such. It still gets injected into the codebase at the end of the day, and can be vendored if required.

funnily enough those new devs, so imbued in their 'best practices', commit the dist of their project on github so at least is dead easy to work around the damn 'I depend on an application being installed globally' pattern

Merits of this framework aside, the front end space is way too volatile to provide a single unversioned binary and walk away.

Don't like micro frameworks? Install bootstrap or foundation.

Everyone needs their own tool in their CV...

So beautiful to hear someone else say it. I've been feeling this way for a while. Besides, there's really nothing critical in my HTML that's going to require updates. What's the last remote root discovered in Bootstrap? What's the last use-after-free found in FontAwesome?

There you go:

https://1000ch.github.io/grd/dist/grd.css

Not only does the installation with npm take at least 20 minutes but you install anywhere between 250 and 400 dependencies for those 37 lines of CSS.

The demo is broken for me.

Why would anyone even want anything like it?

E: Nice to see again how childish HN is, downvoting when someone points out that the thing is broken and asks a serious question. This is why I originally left this place.

The demo works fine for me in Chrome. Maybe you would have received a better response if you included how the demo is broken, which browser you are using, and what you see.

nice

I wish there was gentlewomen^H^H^H^H^Hfolks agreement to use minified size for library size comparison, not gzipped size, because minified size better tells how much there are code to read/understand & parse/execute, while gzipped size tells how much there are bytes to transfer, and the bottleneck is generally the former.

Just say gentleman's agreement. It's okay to use a real phrase.

Thanks sir, but I prefer gender neutral wording. (Note to self: humor, do not use.)

Not only is it OK to use a real phrase like "gentleman's agreement", it communicates better. People will more easily understand what you mean, and they won't be distracted when you attempt to be gender-neutral by calling attention to gender.

The above is all true but only because gender-neutral words are not yet used widely enough, and the only way to change that is to systemically prefer gender-neutral words. Isn't it part of hacker mentality that one should fix broken things and one should not be afraid of change?

(I guess this is largely culture related thing, but e.g. among my peers (high educated 30s Europeans) gender-biased words actually cause more distraction.)

Your affectation of the old terminal-style backspacing joke is way more distracting than "gentleman's agreement" could ever have been.

And anyway, I think you'd have been better off just saying, "I wish we could all agree...."

What an odd thing to get your knickers in a twist about.

Then why didn't you use gender-neutral wording?

how is that neutral?

Don't people usually mention both? This one didn't. But even the full un-minified source code of this one is just a bit over a kilobyte, so perhaps the author didn't feel the need to minify in the first place.

I don't think parsing and executing is the bottleneck, especially on mobile connections. Do you have any numbers on this?

It's actually worse on mobile, because mobile connections typically are not order of magnitude slower than non-mobile, but mobile cpu power can be order of magnitude more limited (esp. on lower end hardware).

https://timkadlec.com/2014/09/js-parse-and-execution-time/

That article is about JavaScript, not CSS.

Does not matter, same principles apply to CSS as well. Transferring is pretty lightweight operation compared to parsing & rule applying.

Reply on news.ycombinator.com