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/
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/
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.
But I do agree that web dev tooling could use a lot of work. Grd did not set out to solve that.
A 4 page static website, for example, shouldn't need model view controller, package manager, routing, etc.
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.
https://raw.githubusercontent.com/1000ch/grd/gh-pages/dist/g...
I'm honestly not seeing what is there to complain about.
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.
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
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.
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>.
You may find this article to your agreement: http://www.satisfice.com/blog/archives/27
Not that hard right?
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.
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.
Don't like micro frameworks? Install bootstrap or foundation.
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.
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.
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.
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.
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.
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.
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;
...There was once a time when you could mock ridiculous things without being "traumatized" by them.