Formidable employee here: To be quite honest we are compensated very fairly for our industry already and this program is not meant to ‘provide a living wage’ by any means.
Instead, this is a ‘fair nod’ at the work some of us feel compelled and motivated to do after work hours.
Not saying your perspective is wrong, just hopefully providing a bit more context about what this program means for someone who uses it.
I get that. I work ten hours a week or so for free on my open source passion projects. If that turned in to an extra $200 a week that would be cool - I’m doing the work anyway.
I haven’t read the article yet but my only fear with crowd funding is what happens when I want to take a month off of technical work.
As someone who supports several developers, I hope you take as much holiday as you need. I mostly support it to increase the chance of the project surviving in the long term, and as a token of appreciation of your past contributions.
You can pause patreon campaigns. If you're open about your work life balance and how you need to take a month off from the project I think most people will understand that.
You're an employee so you can answer the question: does Formidable take copyright ownership of the open source contributions provided by you? Do you have to ask your employer if you want to change licenses for your open source projects?
And I'd assume you guys have some employees who are paid competitive salaries by Formidable and end up working almost exclusively on your open source code anyway, right?
This is awesome. If my employer did this I'd probably take a lot of that money and donate to other OSS and charity since I'd neebed working on OSS regardless.
I'm a true designer/FE developer hybrid - I love designing and prototyping with sketch/framer/invision, and then developing frontend components & building single-page apps. I've build simple RESTful APIs for personal projects that include oauth/sql/qless services. I care a lot about UX & perf, and really want to work on an exciting product.
Its not horribly broken, IE11/10 is well supported with prefixes & past flexbox-spec properties. Autoprefixer does all the work there. For IE9/8 you could rely on polyfills like https://github.com/10up/flexibility
Listened to @_lemonmade & @snookca at a recent conference talk about how they're using Flexbox across the Shopify platform and there is no reason why other far-reaching platforms shouldn't make the switch today.
It works in some cases as a pattern of keeping components very modular and only loading the styles on the page that a single component needs. And I think it works well in cases where a component is very unique and wouldn't share any styles with other components.
That said, I personally see it as an anti-pattern. Styles should be kept agnostic of application logic for the most part. Practicing proper BEM convention paired with proper organization of SASS files yields simple management of style logic. This works exceptionally well in complex applications.
There are two camps forming right now with different methodologies & use-cases in each, and it will be interesting to see which patterns are implemented & what kind of 'css in js' tools become available.
If you're using BEM, then in my opinion, styles in React are the logical conclusion. Using CSS means having 2 files per component, Button.js and Button.scss. If you want to share styles, then you can simply import an object. If you want to darken a color, you can import a function. And so on.
So what about caching and rendering? So I imagine that if I render 200 buttons that have inline style it would be slower if I load one stylesheet and 200 HTML tags.
And caching problem would be if I have 2 server rendered pages ( even with JSX that's possible ) and have same styles which will be downloaded twice from two js bundles.
I think separation of those is still better solution. Not to mention stylesheet commits that are far easier to follow than just modifying a js file.
You're mixing two different problems. Just because you write your CSS in JavaScript doesn't mean you have to deliver them as inline styles. [1] [2] [3]
CSS in JS is about leveraging the (relatively sane) variable/procedure declaration and control flow semantics that are already available to you in JavaScript. How you deliver them to get the best possible performance is a wholly different problem.
A quick google search on the matter will reveal many sources. Though not the most professional news syndicate, VICE ran a great story a few months ago on the environmental impacts of palm oil in Indonesia.
AFAIK This script came from Tympanus/Codrops, not VI. I've used a version of this script as well for a project. I mean, it'd be better if Marek used even a modified background instead of taking the entire example from Codrops, but I don't think it would be 'stealing' as much as reusing tutorial code.
The standard recommendation for the Aeropress, including from Adler himself, is to use 175F water, much less hot than you'd use in other preparation methods.
In Seattle at least, there is near-universal consensus among every coffee shop I've been to using an Aeropress that 175 is much too low. Most go closer to 200.
What’s your definition of “proper”? You get a different flavor profile if you vary the water temperature. My favorite for single origin light roasts is very fine grind, not too much 170–180° water, and short steep time. It requires somewhat more beans to get strong coffee compared to a brew using more, hotter water and a long steep time, but the resulting cup of coffee is much tastier IMO.
Instead, this is a ‘fair nod’ at the work some of us feel compelled and motivated to do after work hours.
Not saying your perspective is wrong, just hopefully providing a bit more context about what this program means for someone who uses it.