I think a better understanding between inline and block is, that inline-elements do not generate a block. The idea of a block breaks down for inline elements, especially when they go over multiple lines. It's not just a horizontal expansion.
So understand what creating a block means. Inline-elements don't.
In his explanation inline-blocks do generate a block. It's just a block that doesn't fill the entire horizontal space, but expands with the inner element.
I’ve always thought of ch as a unit intended for monospaced fonts or languages with monospaced characters. Does anyone know of any other practical uses?
I personally feel it’s a good spacer between labels and form controls, icons and text and can also be useful for other inline-like elements that should have a natural spacing. Another possible use is in setting min and max widths for content areas where ideal line-length for comfort of reading is considered important.
Yes. A good column width or grid card inline-sizes is between 30ch and 45ch, generally you don’t want text to exceed 90ch.
These numbers come from print design for magazine or journal layouts. In general the `ch` unit is perfect for defining the inline-size of text containers.
for people who want to go deeper on stuff like the box model and specificity and selectors, i highly highly recommend Una Kravets and Adam Argyle's The CSS podcast https://pod.link/thecsspodcast - they are the two CSS devrels from google and they really break it down in depth while explaining things in an accessible way. no vested relationship, just a fan.
> Using pixels (px) is tempting because they’re simple to understand: declare font-size: 24px and the text will be 24px. But that won’t provide a great user experience, particularly for users who resize content at the browser level or zoom into content.
Pixels (px) in CSS are relative as well, and scale with zoom. What is the benefit of em/rem?
They (em*) scale with the element's font size, and if you set an elements font-size itself in em, that will be relative to the parent element's font size.
For example:
body { font-size: 18px }
.something { border: 0.1em solid black; }
.something > .inner { font-size: 1.5em }
If you change the font-size on body, everything on that page will re-scale seamlessly. This is most useful for things like buttons/icons that are supposed to flow properly with text. So now even if you use them once in big text, and once in a small footnote, they'll still fit perfectly within the line.
The biggest limitation to this approach is that you can easily end up with computed values that are weird fractions of pixels, so you have to be a bit smart and pick an easily divisible number for your base font-size if you're aiming for something pixel-perfect.
The challenge with em units is that if you modify a parent element's size it changes the children as well. In your example, if you put 'font-size: 2.0em' on the .something class then the .inner would end up changing to 3.0em. That's rarely what you actually want to happen (especially in a web app). If you just want to control the overall font scaling of everything on the page using rem is preferable, because then they'd ignore the parent and scale based on the root element size.
The key is to use rem for font-size and em or unitless for all other properties: padding, border-width, margin, line-height. That way the size of the element is independent of the context.
There's no date on the article, and this was the entry that made me wonder if it's 5+ years old, back when text zoom was more prevalent. When full zoom became the default, em/rem became less necessary, and at least to me appear to be falling out of favor as extra unnecessary complexity.
(Quick edit: Mentioned but not really given much focus is that em/rem can be used on, say, image width and margin, as well - making it adjustable in a text-zoom world. That's mainly what I have in mind here.)
(Even aside from affecting non-text, in the newly popular component-oriented design, you typically don't want relative font sizing to leak between components.)
Not anymore, as most px units now is based on a reference px, a size determined based on screen density and viewing distance. That's why something rendered at 600px on an iphone takes almost all the width, even though the screen has more than double that in pixels. And when zooming, the reference px is zoomed. So the old reason for not using px and instead use rem doesn't apply.
Yeah I came here to ask this. Using relative units for layout seems like a terrible idea. If you want to make your text a little bigger, your entire layout changes too. That's fine if it's something like text padding or paragraph margins, but stuff like border width, or dimensions of boxes? That seems weird.
Browsers have been able to zoom pixel widths for years.
This is actually really nice. I've worked with CSS for a long while with the "Stackoverflow it until it works" philosophy, so some of these things (e.g. margin collapses) I had no idea about.
Useful article.
Getting started with CSS must be harder these days than it was 15-20 years ago. Not only for mobile-friendliness, but also because of the coexistence of flexbox/grid/traditional layouts. I'm wondering if the standard will ever been simplified, instead of being added more and more features.
Just use flexbox (and grid if you need to control both dimensions at once). You can ignore all of the old ways of doing layout. Flexbox is supported back to IE11.
As an occasional CSS user, I second that. Every time I have had to use CSS for anything more complicated than diddling item appearance has led to a lot of time on Stack Overflow trying to find answers to questions like "why did my height change work on this element but not that element?" or "how can I center this text vertically in this space?".
I don't use CSS frequently enough to not forget these things by the next time I need it.
I'll still probably forget parts of Flexbox between the times I need to use CSS, but it will be things like forgetting like what spacing modes are available, which is easy to quickly look up.
Flexbox is now my turtle [1]. Well flexbox and grid.
An incompatible and broken version of Flexbox is supported in IE11. Therefore, layouts look completely different (and broken) when rendered in it.
Only people who recommend Flexbox in IE11 haven't tried using it in IE11. I might via a library that did the heavy lifting for me, but there's just too many bugs to recommend anyone write Flexbox and expect it to just work -- it won't/doesn't.
PS - I'd link all the IE11 Flexbox bugs but Microsoft took them offline with Microsoft Connect's retirement.
I write a fairly substantiate app (60,000 DOM elements...) that uses flexbox and SVG for all the rendering and it's fine in IE11. The layout problems are more often SVG related. That said, if you don't need to support IE11 it's much easier not to.
Backwards compatibility support will always require adding on new ways to do things and not removing stuff.
I personally find flexboxes frustrating at times and tend to limit my usage to non-grid spacing (footer columns, horizontal menus) and responsive vertical alignment.
CSS grids are pretty cool, and maybe if you were just starting out it would be easier to pick up fresh than having to unlearn floating divs.
Funny thing is that if you go back 25 years (pre-table layout era), everything was not only mobile compatible but your target viewport was 800x600 which I find the painful part of mobile compatibility these days - it's that ugly zone in-between a nice mobile/cell phone layout and having the whole desktop to work with.
I started around 2006 and there are definitively more standards — as in more ways to achieve the same thing. And yes, you have mobile — though we did fluid and "responsive" layouts back then as well.
One thing that is better is the browsers adherence to standards. I spent my first years learning all IE6 rendering bugs and how to overcome them.
CSS and HTML are constantly evolving, and so its demands. However for me CSS is way more straight-forward than in the 90th and 00th.
The standards addressed a lot of the pains and struggles we had with floats/clearfix etc. This was challenging but nothing im comparison to supporting IE 6-9, FF, Safari, Opra etc. at the time. Also hacking in JavaScript added to the complexity.
Nowadays I can do with 10 lines of grid and flex what great CSS frameworks like Bootstrap abstracted away behind 1000th of lines of code.
Also testing is way easier, since browser vendors follow standards and there is chromium everywhere.
Earlier we did a lot of div soup, I remember fondly CSS zen garden as well as OneDiv.
Awesome times to be a web dev, you work on products (PWAs!) not on browser hacks.
15-20 years ago it was exceptionally more complicated to have rounded corners on things.
The complexity has just shifted. While previously you could easily start using floats, you might run into issues down the road with them, or with browser compatibility
Now, you might struggle a bit more trying to understand Gris syntax and how to use it, but once you do you’re probably set.
CSS is way easier now when it was 15-20 years ago (source: 24 years with frontend, 22 professionaly). Alas, that's probably one of the reasons why people do not spend any effort learning it.
I'd argue that 15 years ago was the golden age for CSS innovation and web standards in general. Technologies are much more powerfull now, but the attitude of those using them could use some improvement.
“Getting started with CSS must be harder these days than it was 15-20 years ago.”
Not like I’m teaching anyone these days, but I’m not sure about that. Yes, there’s just more now. Grid and flexbox and transforms and on and on.
But if you were totally starting from scratch, certain stuff is just way easier now, or at least, not a pile of hacks upon hacks. Basic beginner stuff that comes to mind…
• How can I center something vertically and horizontally without having to explicitly know the size of the container and object to be centered?
• What is all this float stuff, how do I just make a grid of icons?
• Wait, borders fundamentally change the size of my div? What?
• I have to do what now to have a drop shadow?
• How do I keep my branding colors consistent without having to make really sure I plug in the right hex values in every little color declaration?
I wish the author had gone a bit further into em vs rem. I'm reading other articles on the topic but they're simply technical explanations and I'm still not clear on what features of the page are best designed using em or rem.
em: unit based on the font size of the element it is querying.
rem: unit based on the font size of the body element.
rem is helpful if you want to make an entire page scale uniformly if you change the base font size (imagine accessibility settings) while keeping the same proportions with padding to font size.
em is great for things like buttons where you may want to make one class for `button.cool-button{ padding: 1em; font-size: 14px; &.xl{ font-size: 20px;
}}` and then you can change the font size by setting the `.xl` Class on that button and the padding will go from 14px to 20px. One button, shared proportions.
Just to mess with your mind: in media queries and in the root element’s font-size declaration, em and rem mean the same thing, being the browser’s default font size, which is 16px in most browsers by default, but customisable in some browsers and different by default in some environments (e.g. I seem to recall Kindle using 19px). I call this unit the “browser em”, or bem. No one else really talks about it. One thing I haven’t investigated and probably should: does this unit depend on the language the document is specified in? (Because you can define different default fonts and sizes for different languages in at least Firefox.)
I would guess it does matter about the language, but likely because as the language changes the font itself may actually change. And different fonts would have different relative font sizes. But like you, I haven't investigated it enough to make a definitive statement about it.
Anybody knows a good book on CSS for ppl with a solid programming background? Every couple of years I try something and fail. Somehow the tutorial rave about the cascading on and on, and when it comes how to strategically design a good SAP working on different devices the stuff gets mute quickly.
https://caniuse.com/ is also invaluable to check whether the cool CSS feature is actually supported. it's very much today's quirksmode.com.
Once upon a time I would have recommended Eric Meyer's CSS Definitive Guide without hesitation (I think I still have my 1st Edition copy) and it looks like he's re-released with updates for flexboxes and grids.
Can't recommend Andy Bell and Heydon Pickering's Everyday Layout enough. It's a wonderful resource for learning (and re-learning) contemporary best practice CSS.
I have every book written by Heydon and am currently doing Andy's 11ty course. They're both stellar teachers and some of the most knowledgeable programmers when it comes to HTML and CSS. Every Layout is amazing. Strong recommend.
Best resource I've found to learn the foundation of HTML/CSS is Shay Howe's guides [1]. I think it doesn't cover Flexbox and more advanced layouts, but it's totally worth a read. I still go back to it as reference from time to time.
I’ve written a small CSS ebook if that interests you. [1] It teaches you how to build a webpage from scratch.
I’m currently writing my second one, which will be more theoretical and cover things like this blog post actually. I’d be interested to know what kind of problems you’re facing in CSS, so feel free to drop me an email.
I'm curious about your book, as it seems small enough for the kind of things I write as well [1]. Can I ask if it earns you enough for anything?
Sorry for coming out of nowhere, but I have lots of small tutorials I could use (I teach in a local college) which I could make small ebooks out of them.. Looking for some side money..
I've been earning a bit on a regular basis since I published it 1 year and a half ago. Not enough for replacing a salary, but enough as side pocket money. I'm lucky to have a decent following, so I didn't have to market it a lot. I'm currently writing a second one which is longer and more advanced, so hopefully it will earn me a bit more.
Thanks for the reply! Do you have any practical tips you may want to share? Maybe how did you grow your audience, how you wrote your book (technologies, etc.)?
Well I grew my audience on Twitter by building open source projects. [1] I didn't really plan or aim for anything. It mostly happened.
As for technologies, I just wrote the book in markdown using Sublime Text. Then I used a markdown-to-pdf library from GitHub to generate my ebook, and voilà. Nothing fancy really.
This is content marketing done right. I really don't mind that this article is there to promote the book when it actually offers some value to the reader (I actually learned a new thing, nth-child and nth-of-type)
Yikes. I've been earning 6 figures as of about two years ago doing mostly HTML and CSS UI design for a bank. And I still did not know about many of these! I guess they are things I wish I'd known about CSS! Better late than never I guess.
Sometimes I wonder why companies even pay developers so much in the US. I'm a specialised medical embedded software developer in the UK and I'm not even halfway to six figures, and will likely never hit it.
It astounds me that companies don't hire twice as many non-US developers for the same price and get more work for their money.
Note, I'm not talking about outsourcing to the absolute cheapest bottom of the barrel developers who cost 1/20 of the price and the quality reflects the price. Just equally skilled developers in non-US countries.
That is going to happen. Big corporations are finally waking up to 1st class remote work, and that’s the gateway to lower US wages. I say this as a remote worker, and a huge fan of remote work. But I do think the high US salaries are going to mean revert a bit.
Now, admittedly I'm a skeptic of unions by default (in my view they're mostly just another layer of bureaucracy/waste), but isn't unionization of tech workers in the US the quickest way to make themselves even less desirable?
Why hire a US union member when you can hire an Eastern European who both works for peanuts and doesn't have union hang-ups? (Admittedly outsourcing has its own problems, especially when there are language/cultural barriers)
EU has very strong employee rights, so that will come to the same point as a union in the US. The lower pay is an advantage but the time zone difference of 8-12 hours can be a disadvantage. There are no language barriers in IT between the US and Europe, by the time they graduate college the average European has gone through more than a decade of English courses. Cultural differences are minor, management style is very similar (in the East) and so is the communication culture.
So yes, lots of American companies already outsource to East Europe. There are lots of "Silicon Valley"s across EE thriving on Western outsourcing from companies who aren't quite desperate or cheap enough to go to India.
There are some phenomenal outsourced shops in EE. Those that do pay 2-4 higher the going rate in the country. These aren't wordpress sweatshops. These are usually small teams and people work on interesting,specialised projects. Management style is usually very pragmatic ( a means a and let's cut the crap) .But the best part about these is that people do get exposed to things,build experience and eventually start on their own. 10-15 years ago there was hardly any product driven company in my country.Now the ones most worth working for do have successful software product that are sold in western markets.
The US salaries in IT are huge, but you need to take into account that they have to pay a lot to have a quality of life comparable to what a minimum wage worker is getting in west Europe.
If you have a few kids, I would bet you are not that bad in UK with one fewer digit.
Yes, This is the main difference. In Germany the education is free and medical insurance not something to worry about ( I have no idea about what deductables, deletables etc mean). This is where the difference lies.
As simple rule of thumb an employer in the EU has to pay roughly double the net salary amount, so on top of the salary pocketed by the employee yet another similar amount goes to taxes. The education/insurance aren't "free", they're just managed better and give more direct benefits to the taxpayer.
It depends. When I was a student, I did not have to spend a penny on medical biils, my wife got paid by the government for some courses (+ cost of rent etc) that would have costed us around 20K € at that time. Now that we are earning enough, I have no problem in paying back, so that others who need it will be also be able to achieve their dreams.
In the United States, you can spend 6k on health insurance and 12k out of pocket for unlimited family health care.
So as long as a US job pays 18k more, it's pretty similar.
People talk about vacation, but my job pays so much I'll take months off between contracts. (Engineering)
Also it's hard to compare lifestyles in the US vs Europe. Homes in the US are gigantic, often newish, and have Air Conditioning. Cars in the United States are more feature rich and have higher safety standards (when I was an airbag engineer in 2015)
I'm sure in terms of money, working in the US as an IT person is a good deal.
But you have to think not only about you but also the others. I don't know whether you have children or grandchildren , but if you do I'm sure knowing that they will never have a bad situation is pretty nice. You can't expect all your children and grandchildren to have a well paid job and you can't finance all of them forever.
Workforce mobility means people can always move for a system that makes more sense for them. If grandpa was a good IT engineer and made some nice money in US, but the grandchild is the village idiot then moving to Germany or France is a solution. Germany has an open door policy to foreigners (there are millions of Turkish descendants of "guest workers" invited after WW2 for reconstruction), East Europeans and now "refugees" from all over Middle East and Africa. No idea how immigration works in France, but there are huge Magrebian communities and lots of other foreigners as well, so I think it is doable.
One can live in Western Europe on welfare. Most of my colleagues in France are not born in France, they are foreigners. The trend is growing in Germany too, in our department there is no German in Germany but people from Brazil, India or Eastern Europe.
> In the United States, you can spend 6k on health insurance and 12k out of pocket for unlimited family health care.
Where? How? I... this total is about what I’m seeing for shit-tier covers-nothing insurance. Like, there are plans out there that are HCA non-conforming and not that far under $18k/year just for the premiums. Who do I talk to to get total max healthcare spending of $18,000 without an employer-provided plan, in the US? Who’s offering $12,000 annual max-out-of-pocket family plans for $500/m?
Although I don't really think it makes sense to compare costs based on OOPLs. For most people, the deductibles, coinsurance, and copays are much more relevant to actual costs.
For context: I'm an American who's currently working as a software engineer in France (for a French company).
I agree that engineering salaries are much higher in the US than in Europe and other non-US countries, however it's worth considering that there are additional expenses to hiring in other countries. My french salary is ~30-40% lower than I was making in the US. However, my cost to my employer is nearly as high. Employer taxes are much higher, my company is required to reimburse my transit and all-but-obligated to cover lunch as well. Certainly, many US software companies do some/all of that, but not all.
And beyond those pure costs, there are more liabilities to the employer. For instance, if they want to fire me, they're legally on the hook for four months of severance. And, I get ~7 weeks of combined vacation time and "comp time" (based on the fact that I work more than 35 hours a week). In the US, I got 2-3 weeks.
I don't have exact numbers, and I don't disagree that there are potentially savings to be had, but I don't think it's nearly as clear cut that you could get anything close to twice as many developers.
It's not 100% accurate (the exact amounts depend on many variables) but gives a good idea. For example, a cost to the employer of USD 100k (87460€/year) gives a before-taxes salary of USD 70.5k, and a salary after all taxes of USD 47k.
> before-taxes salary of USD 70.5k, and a salary after all taxes of USD 47k.
What!? That's over 30% of your income gone, and for a relatively average income. That's not even counting VAT and other taxes.... No wonder there's so much "free" stuff in Europe.
€61k before taxes isn't really a relatively average income in France. A junior engineer (with a Masters) starts around €35k ($40k) before-taxes. Country-wide median salary is €28k ($32k). But across all those salaries it doesn't change the fact that around 45~55% of the employer's cost isn't going to the employee.
And yes, taxes and cotisations are very high. On the other hand they cover most higher costs and risks in life (education, health, basic retirement…).
Still, €61k isn't an average salary. An engineer reaches that after about 10-15 years (from personal experience and some statistics I have access to). It's double the national median.
Even with the stronger safety net, it doesn't make up for the difference compared to the US for well-paid employees (such as engineers, or tech in general). US employees are much more well-off, there's no denying that. US levels for engineers compare more to Swiss level of living.
However the safety net is much more beneficial for less-paid people, at a relatively low cost for them.
I only visited the US so others might be able to provide a more detailed comparison. It seems to me that rent is generally significantly higher in US cities (might be different in lower CoL areas), and groceries and other smaller budgets were slightly higher in France (restaurants, tech purchases, cars…).
I have worked in the US and Europe, and may give a direct comparison.
US healthcare and education consume a vast portion of your pay. We paid cash for our daughter's college (biomedical engineering) at a total of over $300K. That buys her freedom of choice when it comes time to take a job, get an advanced degree, etc. Her colleagues will have more than $500K USD debt hanging over their heads when you factor interest payments.
The company pays for a portion of health insurance, but much of the cost is picked up by the employee, either though co-payments or deductibles.
We live modestly, drive low-end cars and don't dine out often. We see our European friends taking great vacations and their children bounce in and out of college programs. We see free healthcare, mountain cottages, and other perks unavailable to us.
Without going into numbers all I can say about US vs Europe: for people with low income,Europe is much much better. For middle class, it boils down to some difficult choices( kids, education, leisure) and is probably equal. While upper middle class or highly paid professionals have it better in the US.
I'm in Scotland, my salary is about £45-£48k. I take home about £31k.
The median salary here is about £21k nationwide.
I bought my home for £170k, now worth about £230k. it's a decent sized apartment in a nice area in the city where I work. For an indication of size, my living room is about 23ft by 28ft, 2 bedrooms, 2 bathrooms.
Did you have a large down payment? That looks like a small monthly cost for such mortgage. Or maybe the interest on such loan in Scotland is very small.
Well damn, I don't think there is anything below 3.00% (3.50% more common) where I live.
That's nominal - 3.5% - 4.0% is the effective interest rate. I don't know much about mortgages, so not sure if I'm missing something. Congrats on your place - it looks great!
Effective interest rate is, to my understanding, not related to inflation. It's just a way to make loans with various compounding periods easily comparable (I'm mostly citing this from Wikipedia, I'm far from expert here: https://en.wikipedia.org/wiki/Effective_interest_rate )
I just mentioned it for the sake of providing more information to whomever was reading my comment.
Some perspective on the costs that look "scary" for the people outside of the USA. I'll share some personal data based on my 20 years since moving here. I have started with $60K and now I am making close to $250K. All this time I was living in a median cost area (one of the top 20 US cities, east coast).
My average effective tax rate over the last 20 years is 19.6% (this includes federal, state, social security and medicare taxes)
My average medical expenses for a family of four are at 3.6% of my gross salary (includes health/rx/dental/vision insurance premiums and out of pocket expenses)
I've paid cash for my oldest child's education at top 10 public university - ~1.5% of my earning over the last 20 years. I am expecting to pay similar cash amount for my other child.
We live in a 4000 sqft McMansion near the best public schools in the state. My mortgage is ~$820 at 2.5% APR
It does look like your effective tax rate is 31-35%, which is more than my all-inclusive rate of ~24.7%
Notably, I doubt you could get family healthcare coverage in the US that reduced your financial risk as much as France’s does for under $25,000/yr. Even at that rate I bet your exposure’s still worse.
> I doubt you could get family healthcare coverage in the US that reduced your financial risk as much as France’s does for under $25,000/yr.
I'm not so sure. It looks like the average liability for a family (12 monthly premiums plus deductable) comes in at just under $23k[1]. That's the max the average family would pay. Obviously for just a single person total liability is a lot lower.
So for a person like me who makes good money being an engineer, I am still better off in America where I can make a lot of money but also pay a little more in COL / healthcare stuff.
Wow, that’s... much cheaper than I’ve seen. In my non-coastal middling-wealth state, you’re looking at $1500/m for an HSA family plan that still leaves you with tens of thousands in risk per year, and reducing that risk gets expensive fast (often it’s even worse, and you end up guaranteed to pay more per year than you might pay if something goes wrong under one of the cheaper plans)
Indeed, but eventually a ceiling is reached over which it would be impossible to make a profit having on-site employees.
I don't envy the locals though. I spent 2,5 months in Zurich, during which I saved so much that in pre-corona times it would be enough for the minimal allowed down payment for an apartment.
The Swiss don't have a Switzerland of Switzerland where they could pull off the same trick.
Housing supply is the variable that can act as a release valve. If cities don't want to expand vertically, that's fine, but they'll inevitably end up in a Bay Area type rent spiral.
I think the real issue is that homeowners vote so much more frequently than renters (who would love to have more housing and lower rents), even though they're technically outnumbered.
I think (hope, really) that gp is just one heavy "/s". The knowledge presented in the article is so basic that it is hard to believe that a person who does html for two years and six figures doesn't know these. As for the article, I fail to see any reason for it to exist beyond cheap media presence. Or maybe I should start a blog, because I'm not even halfway too.
There is probably more to the story here. If you’re only at about 50k, you’re making $24 an hour. There’s even cheaper labor than you. It’s going to be a disgusting race to the bottom if we start paying everyone 20, 18, 15 ... dollars an hour.
At this point in my life you would have to pay me around six figures for me to do CSS seriously on a daily basis (and it’s likely I’ll still burn out and leave). The cross browser and device testing alone is so tedious and stress inducing that I simply won’t do the job below a certain price point (or I will out of desperation but definitely will bounce ASAP). The unsaid thing about doing heavy CSS work is that it doubles as a QA job from all the testing required.
And again, I’m someone that’s good at it. You can’t pay me enough to do it, not if I have choices.
If you think CSS is tedious, then you've never dealt with medical device regulations. cross browser testing will seem like an absolute breeze. If a UK employer were paying £90k for CSS, absolutely everybody and their dog would be applying for a job that pays double a typical dev salary.
I think we've already experienced the race to the bottom and come out the other side, with $24 being fairly average for the world and the US being on the high side. This all happened years bacj when companies started outsourcing development and IT to India at rock bottom prices, but then received a lot of low-quality work (you get what you pay for). I believe India has a much different approach to software quality than many other countries.
It's taken many companies years to realise that mistake, but I wouldn't call $24 a race to the bottom for skilled labour as that will land you comfortably above average income in the UK
There's a whole world outside SF in the US where people do make ~$24/hr. It is well above the median salary in the US. Things may be closer to equilibrium than a lot of people think. I used to work for an outsourcing company that was roughly 50-50 people in the US and in India, and there was never any indication that the US people would be fired en masse, probably because they were somewhat more productive, and somewhat higher paid, and the differences weren't huge.
> Sometimes I wonder why companies even pay developers so much in the US.
Presenteeism.
The office "has to" be in Silicon Valley. The employees "have to" be in that office, in an open plan, so the manager can physically see them working. Therefore they have to be paid huge wages to compete against the other employers doing the same.
The only European countries where costs are as high as the US for tech salaries are basically Switzerland and Norway. In the rest of Europe you have access to a very qualified workforce for less money. But they also have more protection than in the US (fewer unpaid hours, more holidays, no cheap dismissal…).
I think the important bit of info is that they work for a bank, not that they write CSS.
If I look at the equivalent compensation for people who work for me, the vast majority of developers in the UK and US earn > $100k. Like for like the US employees earn more but that's almost wholly swallowed up in other costs (basically healthcare and our US healthcare plan isn't particularly bad).
And the FAANGs and hedge funds, in my experience, have a reasonably similar dynamic.
The simple fact is that we generally don't hire for PL knowledge except in very specific circumstances (KDB for example). If all we wanted was a coder, there are much more cost effective options than hiring someone, regardless of location.
1. Why do you think UK software companies aren't more successful compared to American ones. Aren't they saving tons on development costs?
2. Have you considered that you are terribly underpaid?
I've done CSS since 1999, none of this was new to me, and I've never earned 6 figures for doing HTML and CSS. I moved my career away from HTML/CSS in order to earn more.
I think we picked up a lot more of the basics back in the days because doing CSS was much less forgiving than it is now. And the whole struggle with pixel perfect between browsers just forced you to spend hours on these tiny things.
I've never been happy with a front-end dev that I've paid six-figures to.
I once paid a senior front-end engineer far too much to do a fairly involved layout. Three months, an uncountable number of bugs, and one unusable tangle of Sass later I pulled the plug and swore off ever hiring a "CSS Person" again.
I took the Linus+Git approach and said "I'm not writing another line of Python until I understand CSS." After a few weeks of study (I read CSS: The Definitive Guide cover-to-cover) I was able to implement the layout in, and I'm not exaggerating, two hours. No bugs, responsive, cross browser support, etc. Flat out done.
I went back to the dev and asked why they tried to implement it with over a thousand lines of Sass using Flexbox over a few lines with CSS Grid.
It went like this:
Me: "Hey, why did you choose Flexbox over CSS Grid for feature XYZ?"
Senior Front-End Dev (SFED): "I used a grid. Bootstrap's grid."
Me: "No, CSS Grid"
SFED: "Like the 'display: grid' thing? I don't know how that works."
I've never met a CSS Person who has read a book on CSS. Or one that can do the arithmetic on a simple flex-grow/flex-shrink/flex-basis combo.. Even with a cheat sheet.
I'm a back-end dev, I used to think that CSS was "garbage". After learning the ins and outs I think it's a pretty remarkable set of technologies. A true discipline. But, it's hard to find someone who really understands it because it sits at a weird level in the tech stack. Most developers feel it's beneath them or that they "have the gist of it" and most CSS specialists don't have a firm grip on it or keep up with browser developments.
If you're going to work with, hire, or exist as a "CSS Person" within 6-feet of me I'm going to require you to read "CSS: The Definitive Guide" before I give your laptop charger back to you.
This article is good, but it's barely the bare minimum that you need to know about not knowing CSS.
Six-figures for a "CSS Person" who's read CSS:TDG is completely worth it.
Thanks. If you'd like some more book and video suggestions I sent this to a friend back when she was looking to get into front-end development a few months ago:
Here are some book and video links (with Amazon affiliate tags snuck in). I've read all of these books cover-to-cover save for the RxJS one. They approach front-end as a set of technologies that should be understood and mastered rather than the "CsS hAckS to GET YoU pAiD!" style of most web tutorials.
Not sure where to point you with React but if you decide to use Angular or Vue I have some suggestions.
RxJS: Reactive programming the most significant development in UI technology in 20 years. Once you get the hang of it managing asynchronous events (user generated, network generated, time based, etc) become a breeze.
I watched most of the Layout Land videos when I was getting a grip on the state of CSS. Jen Simmons is a developer advocate at Mozilla and has the best overviews I've seen.
Thanks for sharing this list. If you happen to have any recommendations for pure JavaScript, I'd love to hear it. Otherwise, I'll probably take a look at the TypeScript recommendations and work my way through the material.
CSS grid is only recently becoming a reasonable tool to use in practice. I don't think any of the top 1% of front end engineers I know would be able to use CSS grid without looking at the documentation.
Based on experience, the kind of person who would be able to use it from memory either 1) is very skilled AND had a reason to use it recently, or 2) someone of medium skill who just recently read the spec but in almost all other ways is less skilled than the people I mentioned in the first paragraph.
That depends on your company I guess. If your entry salary is, or is close to 6 figures then yeah. But if you pay that only for skilled developers _specializing_ in front-end then it is not too much to ask that they are up-to-date with their field.
> I don't think any of the top 1% of front end engineers I know would be able to use CSS grid without looking at the documentation.
You probably don't mean it that way, but not having to use the documentation surely isn't a requirement for competency. I resort to the docs all the time, even with topics I'm quite famialiar and experienced with.
I agree. It's fairly common for experienced front end devs who have been bitten by browser incompatibilities in the past to wait several years to adopt the latest CSS techniques. The "old techniques" often work very well.
Most likely if you had asked me "why flexbox and not CSS grid" I would have said "because flexbox is able to perfectly well support this use case, and I'd rather not introduce a dependency on a less well supported CSS feature unless I need to".
I personally tend to prefer using the oldest (within reason) CSS feature that lets me accomplish a task. Or I'll pick the one that best conceptually maps to the task I'm trying to accomplish, if there's a significant difference.
Too bad you had a bad experience with your dev, but seriously, you just picked up css, people have been fighting it for years because of browser support. There's a reason why there are css reset stylesheets, and frameworks out there. If you are using it in one project great, but when you do it for living you will ended up building your own framework if you are not already using one. SASS also saves you so much time in development.
Yes, one of the issues with people who've recently learned the 2020 version of JS/CSS/frameworkX is that they assume what they've learned is the correct way to do things according to "the best, latest standard". It's a variation of Dunning-Kruger almost.
As you said, experienced engineers have been dealing with CSS browser support issues for years, so as a habit try to avoid using the latest shiny new features.
Also, experienced engineers do refresh their knowledge from time to time, but you might have caught them between refreshes. Remember that these engineers are also working 40-60 hours per week producing work output in addition to periodically refreshing their skillset. And depending on the environment they've worked in previously they may not have had the ability to use the latest features of whatever technology. Maybe they were working on a legacy app that didn't support ES6, for example. That would be less common now in the days of Babel, but there was a time a few years ago when it would have been reasonable for a working JS engineer not to be familiar with every detail of ES6, as an example.
I too have worked with many front-end developers that were book and spec averse who preferred to gather lore from various gurus in three paragraph blurbs.
I think this is a culture problem in fornt end dev in general. Front end devs learn frameworks, not technologies. It's very much focused on getting started as quick as possible instead of taking the time to read and understand the tech they are working with. Even though, as your story shows, you can get things done quicker when you know what's going on.
Front end development is a craft, just like other crafts. People need to treat it seriously if they expect to be taken seriously and be paid accordingly. (BTW, if you still haven't met a FE dev who's ever read a book on CSS, you have now. I own quite a few AND have read them.)
I also think a lot of the value from a front end developer comes from their ability to merge the technical requirements with a designer's vision, and produce a product that is at the same time usable, accessible and (bare minimum) meets the technical requirements.
Not going to touch the CSS Grid except for two quick comments:
- they absolutely should have been keeping up with CSS Grid, where it was at, and when it was usable and when it isn't
- it is still an open question, because although the overall numbers should 90+% available in browsers, you have to check your own stats. For example, the stuff I work on is often used in Enterprise environments, so IE11 is a requirement (yes, we know our numbers, it is, it could literally cost us 6 figure sales if we don't have support for it). We are using CSS Grid, but we have to be very careful what we use it for and to test those uses in IE to make sure the old Grid spec in IE supports the things we do it with. Otherwise it's back to Flex or other layout techniques. It's not a silver bullet, but I also recognize that is becoming a more unique example these days.
Those are the kinds of things a good FE dev should know though, IMO, and be able to articulate.
Plus, FE devs also need to know HTML and semantics, accessibility, and of course, Javascript. When you can put that all together along with the skills earlier re: usability and accessibility, then you can justify the higher salary brackets.
You seem to be trivializing css as something static you just have to deal with. This maybe true for 99% of websites but css has had more innovation in the last few years than anything else. And much of it hasn’t reached textbooks. For example css3 functions and now being able to mix these new techniques in undiscovered ways. CSS requires a very nimble and creative mindset. That maybe why backend devs usually are very dismissive of it. By the way I became a frontend developer after I spent many years as a backend dev. My background is in Php and Perl.
Have you looked at Definitive CSS? It's up to date and a massive 1000 page tomb of encyclopedic knowledge and guidance. Anyone who digests that entire thing is not being dismissive of CSS.
Digesting that is taking CSS more seriously than most people take learning new programming languages...which is appropriate! Because with CSS, you not only need to learn the language, you are effectively learning something like a language and a framework at the same time. Lots of folks learn the language minimally, piecemeal, on an "as needed basis," and end up wasting a lot of time because they aren't aware of the larger features and how they can be fit together.
Most folks do the equivalent of learning about goto statements, variable declarations, and arithmetic operators, and figuring you have everything you need to do good programming work.
Technically, you do have everything you need. And with a decade of work under your belt using those things, you can build some amazing and good robust systems. It's also easy to build total junk that nobody can understand but you. Perl, of course, is also infamous for having this quality.
> Technically, you do have everything you need. And with a decade of work under your belt using those things, you can build some amazing and good robust systems. It's also easy to build total junk that nobody can understand but you.
This is what’s beautiful about the frontend. It’s “magic” and underneath in code speak it may be ugly but the work speaks for itself. Arguably that is only if you own it and maintain it.
> Lots of folks learn the language minimally, piecemeal, on an "as needed basis," and end up wasting a lot of time because they aren't aware of the larger features and how they can be fit together.
The way I see it, learning about all the ingredients in a recipe will not teach you how to cook. In css techniques are unearthed by a small handful of css artisans and it’s not about learning css itself in 99% of the cases. It’s about digging and finding the best ideas on GitHub, stack and codepen. And hacker news.
Or, you know, using a well vetted, well organized resource that has already done all the digging and collating of techniques and organized into a well structured Definitive Guide.
> Have you looked at Definitive CSS? It's up to date ...
Not really, it doesn't talk about custom properties, inline svg, how to style them, etc. All very useful these days, if you want to allow color theming for your web app and not use hacks like custom fonts for icons...
And custom properties are around since 2014 at the very least.
Interesting, I am really really bad at css but knew all of this. Long ago, someone gave me 7 euros an hour to do some of this (and html/js/php; I never designed anything, I just edited an existing site to specifications, but css was still my least favorite part). Aren't these just things you run into and pick up on in the first webdev projects you do?!
This is great! I've been hacking away at CSS for years and learned heaps from this. Also, reminded me to look up the differences between `rem` and `em`, which I've been meaning to do for ages!
Apart from the course promoted (which sounds really good!), does anybody know a really good book that already presents this kind of material about CSS use in a similar "logical" way and is not being written the style "margin defines the margin" (how insightful)?
I'm also searching for the material that is specifically oriented on:
- depending on the features existing in all browsers since the last 3-4 years, also mentioning how to make the features "usable" with the older vendor prefixes, but not depending on the JavaScript "fixes" for older browsers, and then showing the examples with minimal number of lines.
- demonstrating all the functionality that can be achieved with CSS only, no JavaScript
- addressing the real-life problems encountered during the design of the modern looking pages, and the goal to use all the power of the commonly available CSS features.
If you're looking for world-class CSS knowledge, start with https://every-layout.dev; if you build UI for a living and haven't encountered axiomatic css and layout primitives, they're likely to change your world.
That's a radically misleading comment. It covers much more than layout, and the free content on the site is incredibly helpful and compelling. The full version more than justifies its price. And they offer it for free to students or anyone else for whom the cost is a problem (relying on the honor system).
It's far and away the best resource on CSS I've encountered in my 22-year career working with web technology for a living.
Ok,I missed that the honor system closed recently - but they continue to give it away freely to students or those facing hardship, on request.
The focus of course is on layout (by far the hardest part of CSS to get right), but it's in the context of building up your entire UI from robust, composable, accessible, standards-compliant, profoundly well-engineered primitives, based on first principles -- which principles are clearly articulated and demonstrated in the site.
It also covers typography (IMO by far the best explanation I've encountered of _why_ to use a typographic scale as the foundation of your design system), as well as touching on things like web components, shadowDOM, custom properties.. . and providing a deeply-expert perspective on the relative merits of utility classes (a la Tailwind et al), among other approaches.
I've been working in web-related roles for a living for over 20 years and have never once encountered a CSS-related resource that was this compelling and useful.
"Can't find TOC"?
Um, it's in the site's primary navigation, in the left column. Literally impossible to miss.
I paid the full $100 and was glad to do so. The authors aren't popular (they've clashed on twitter with some big-name FE people like MDalgleish) but their ideas and body of work are unparalleled, and that's what I support.
If I were more selfish I might try to keep my newfound FE superpowers [axiomatic css and composable layout primitives are transformational] a secret, but I find myself wanting to spread the word and support https://every-layout.dev every chance I get.
What I mean is that browsers used to zoom in a way where all the texts were automatically resized but nowadays the zoom works pixel-by-pixel, removing this issue.
Guys we need to talk. Are you capsbold serious? These are things that you learn in a first week of doing web development tutorials. I read this thread and it makes me think that I'm delusional because of a heat wave. Margins collapse? :focus exists? Me not getting a joke? I don't understand.
I think you may be underestimating the fact that many people have been writing CSS for well over a decade now, and that it has evolved considerably since they first read a web development tutorial. If you've not been paying close attention (or not been able to), there are many things that will have passed you by.
It's a blessing to learn css fresh today, in as much as it's a curse to still have practices from ten years ago still lodged in your memory.
GP is pointing out the parts that haven't changed at all, and are old (over two decades), simple, and common enough to be considered basic knowledge. I had the same reaction to those and one or two others.
Now if this was someone relatively new to CSS I'd understand, but the opening paragraph establishes how long this person was around. Padding-vs-margin in particular was necessary knowledge to do good layouts back in those earlier days (less so now only due to flex and grid, which aren't on here).
> GP is pointing out the parts that haven't changed at all
Doesn't read that way to me:
> These are things that you learn in a first week of doing web development tutorials.
Sure, padding vs margin isn't exactly new, however `display: inline-block`, ::before and ::after, rem, ch, and :nth-child() certainly weren't in the old html4/xhtml and css2 guidebook that got me into web development!
To add, I think another post by the same poster on this HN post proves the point that they're not dismissing individual parts, but rather disputing (or sorry but trolling) the article as a whole:
> I think (hope, really) that gp is just one heavy "/s". The knowledge presented in the article is so basic that it is hard to believe that a person who does html for two years and six figures doesn't know these. As for the article, I fail to see any reason for it to exist beyond cheap media presence. Or maybe I should start a blog, because I'm not even halfway too.
It's also good to remember that new devs make up something like 50% of the developer population each year (I forget the exact number, maybe it's every 2 years). So while this may be basic information to someone who's been doing this for at least a few years (and I'd argue it isn't, particularly since the site isn't aimed at Front End Devs, per se, but others who have to do front end development), it is valuable information for the target audience.
I think you are point on. The two existing sibling comments have contradictory excuses for this:
1. New developers might know this, but standards change fast, and it’s hard to keep up.
2. You can’t expect people new to the craft to know everything in the field.
I personally found this article sub-basic. You could probably learn more and better on MDN. I think CSS might be one of few areas on HN where a sub-par article doesn’t get the constructive scrutiny it deserves in the top comments.
> These are things that you learn in a first week of doing web development tutorials.
You meant CSS tutorials? Never read about "margins collapse" in web development tutorials.
Web development tutorials I read (like 10 years ago) were usually about having a web server renders some data queried from a database into some basic HTML. And adding a form to create/edit rows in the database. Then perhaps adding some basic style like colors and paddings and some jQuery to validate the form. Finally moving that page from localhost to internet.
Let's be honest, web development covers a very large area of knowledge and CSS is not the most interesting part (not saying CSS is not interesting!). I guess most people just skip the CSS documentation and learn it by inspecting other pages and copying rules, and searching "how to do X in CSS" and reading tutorials about their specific question.
This was a great article and I learned a few new tricks.
I learned CSS over the years by gradually solving problems I encountered building apps. Compare this to people learning CSS now as evidenced by the #100DaysOfCode tag on Twitter. The learning technique is comprised primarily of using gradient-heavy, absolutely positioned HTML elements to create a photo-realistic, 3D rendering of objects.
The results are pretty amazing, but I have my doubts about whether these skills are easily translatable for building an interactive, responsive UI. Some examples:
A lot of people make games or fun projects for #100DaysOfCode when their job might be updating a CRUD MVC app using Y framework. I think as long as it puts them in the "coding" mindset it's worthwhile.
I agree with that 100% — if it isn't fun, it's work. And if you build enough knowledge about how CSS works in general, when it comes to implementing specific layout or responsive design techniques you have a good understanding of the basics to build upon.
I posted this all to a community called "Forrst" (think of it like twitter, but curated for developers and designers).
I spent time giving feedback on other peoples work, I tried to ask insightful questions https://twitter.com/umaar/status/823915022917271552 to have an open discussion, I spent hours replying to comments every few days.
Then one day, Forrst got acquired by Zurb https://zurb.com/blog/zurb-acquires-forrst and later on it got shut down, and with that, I lost access to huge amounts of my work which I hadn't stored anywhere else (some stuff has been archived online, but not everything).
When it comes to web development tips, I now self-host on my own website and it's a really good feeling knowing that it'll be preserved: https://umaar.com/dev-tips/
339 comments
[ 3.5 ms ] story [ 311 ms ] threadSo understand what creating a block means. Inline-elements don't.
These numbers come from print design for magazine or journal layouts. In general the `ch` unit is perfect for defining the inline-size of text containers.
Some time ago, I wrote up a series about CSS. It’s still quite relevant (but CSS has come quite a ways, since then).
The thing I’ve found that is often misunderstood, is specificity. It’s a fairly non-trivial concept: https://littlegreenviper.com/miscellany/stylist/introduction...
...which kinda reflects "things I wish about CSS", so 10/10.
But "it works differently every time I try" wouldn't have made a good CSS joke. Oh, wait.
(c) Elon Musk, speaking about CSS (maybe)
Pixels (px) in CSS are relative as well, and scale with zoom. What is the benefit of em/rem?
They (em*) scale with the element's font size, and if you set an elements font-size itself in em, that will be relative to the parent element's font size.
For example:
If you change the font-size on body, everything on that page will re-scale seamlessly. This is most useful for things like buttons/icons that are supposed to flow properly with text. So now even if you use them once in big text, and once in a small footnote, they'll still fit perfectly within the line.The biggest limitation to this approach is that you can easily end up with computed values that are weird fractions of pixels, so you have to be a bit smart and pick an easily divisible number for your base font-size if you're aiming for something pixel-perfect.
(Quick edit: Mentioned but not really given much focus is that em/rem can be used on, say, image width and margin, as well - making it adjustable in a text-zoom world. That's mainly what I have in mind here.)
(Even aside from affecting non-text, in the newly popular component-oriented design, you typically don't want relative font sizing to leak between components.)
https://developer.mozilla.org/en-US/docs/Glossary/CSS_pixel
Browsers have been able to zoom pixel widths for years.
I don't use CSS frequently enough to not forget these things by the next time I need it.
I'll still probably forget parts of Flexbox between the times I need to use CSS, but it will be things like forgetting like what spacing modes are available, which is easy to quickly look up.
Flexbox is now my turtle [1]. Well flexbox and grid.
[1] https://en.wikipedia.org/wiki/Turtles_all_the_way_down
Nope.
An incompatible and broken version of Flexbox is supported in IE11. Therefore, layouts look completely different (and broken) when rendered in it.
Only people who recommend Flexbox in IE11 haven't tried using it in IE11. I might via a library that did the heavy lifting for me, but there's just too many bugs to recommend anyone write Flexbox and expect it to just work -- it won't/doesn't.
PS - I'd link all the IE11 Flexbox bugs but Microsoft took them offline with Microsoft Connect's retirement.
Backwards compatibility support will always require adding on new ways to do things and not removing stuff.
I personally find flexboxes frustrating at times and tend to limit my usage to non-grid spacing (footer columns, horizontal menus) and responsive vertical alignment.
CSS grids are pretty cool, and maybe if you were just starting out it would be easier to pick up fresh than having to unlearn floating divs.
Funny thing is that if you go back 25 years (pre-table layout era), everything was not only mobile compatible but your target viewport was 800x600 which I find the painful part of mobile compatibility these days - it's that ugly zone in-between a nice mobile/cell phone layout and having the whole desktop to work with.
One thing that is better is the browsers adherence to standards. I spent my first years learning all IE6 rendering bugs and how to overcome them.
The standards addressed a lot of the pains and struggles we had with floats/clearfix etc. This was challenging but nothing im comparison to supporting IE 6-9, FF, Safari, Opra etc. at the time. Also hacking in JavaScript added to the complexity.
Nowadays I can do with 10 lines of grid and flex what great CSS frameworks like Bootstrap abstracted away behind 1000th of lines of code.
Also testing is way easier, since browser vendors follow standards and there is chromium everywhere.
Earlier we did a lot of div soup, I remember fondly CSS zen garden as well as OneDiv.
Awesome times to be a web dev, you work on products (PWAs!) not on browser hacks.
My 2 cents.
The present-day CSS frameworks use "class soup."
For example, tailwind (which I like):
The complexity has just shifted. While previously you could easily start using floats, you might run into issues down the road with them, or with browser compatibility
Now, you might struggle a bit more trying to understand Gris syntax and how to use it, but once you do you’re probably set.
Not like I’m teaching anyone these days, but I’m not sure about that. Yes, there’s just more now. Grid and flexbox and transforms and on and on.
But if you were totally starting from scratch, certain stuff is just way easier now, or at least, not a pile of hacks upon hacks. Basic beginner stuff that comes to mind…
• How can I center something vertically and horizontally without having to explicitly know the size of the container and object to be centered?
• What is all this float stuff, how do I just make a grid of icons?
• Wait, borders fundamentally change the size of my div? What?
• I have to do what now to have a drop shadow?
• How do I keep my branding colors consistent without having to make really sure I plug in the right hex values in every little color declaration?
The fact you could use them to build all sorts of header/column/footer layouts was both very helpful and entirely confusing.
It became the default way to use CSS, for good reason. Yet, I always felt it was a shame it wasn’t often described as the hack it was.
Back then, you had to put some image to make a fake border-radius.
Or some weird hack because table layout doesn't wrap.
And using a different technology that is flash because css couldn't animate.
Not to mention the existence of transpilers like stylus that make writing far easier and we no longer have IE6 that behaved on its own rule.
em is often used for the padding of elements. For example buttons that exist in different sizes.
em: unit based on the font size of the element it is querying.
rem: unit based on the font size of the body element.
rem is helpful if you want to make an entire page scale uniformly if you change the base font size (imagine accessibility settings) while keeping the same proportions with padding to font size.
em is great for things like buttons where you may want to make one class for `button.cool-button{ padding: 1em; font-size: 14px; &.xl{ font-size: 20px; }}` and then you can change the font size by setting the `.xl` Class on that button and the padding will go from 14px to 20px. One button, shared proportions.
Also zeal (dash on Mac which is paid or you can build zeal yourself like I did) has docsets for CSS which are good.
Once upon a time I would have recommended Eric Meyer's CSS Definitive Guide without hesitation (I think I still have my 1st Edition copy) and it looks like he's re-released with updates for flexboxes and grids.
https://every-layout.dev/
[1] https://learn.shayhowe.com/
I’m currently writing my second one, which will be more theoretical and cover things like this blog post actually. I’d be interested to know what kind of problems you’re facing in CSS, so feel free to drop me an email.
[1] https://jgthms.com/css-in-44-minutes-ebook/
Sorry for coming out of nowhere, but I have lots of small tutorials I could use (I teach in a local college) which I could make small ebooks out of them.. Looking for some side money..
[1] https://github.com/joaoventura/full-speed-python
As for technologies, I just wrote the book in markdown using Sublime Text. Then I used a markdown-to-pdf library from GitHub to generate my ebook, and voilà. Nothing fancy really.
[1]: https://twitter.com/jgthms
https://css-tricks.com/examples/nth-child-tester/
eg. try 3n+1, 3n+2. 3n+3 and then different multipliers
Sometimes I wonder why companies even pay developers so much in the US. I'm a specialised medical embedded software developer in the UK and I'm not even halfway to six figures, and will likely never hit it.
It astounds me that companies don't hire twice as many non-US developers for the same price and get more work for their money. Note, I'm not talking about outsourcing to the absolute cheapest bottom of the barrel developers who cost 1/20 of the price and the quality reflects the price. Just equally skilled developers in non-US countries.
Why hire a US union member when you can hire an Eastern European who both works for peanuts and doesn't have union hang-ups? (Admittedly outsourcing has its own problems, especially when there are language/cultural barriers)
So yes, lots of American companies already outsource to East Europe. There are lots of "Silicon Valley"s across EE thriving on Western outsourcing from companies who aren't quite desperate or cheap enough to go to India.
If you have a few kids, I would bet you are not that bad in UK with one fewer digit.
But I'm talking from the employer side, not the employee and why they would employ US devs who cost twice as much
So as long as a US job pays 18k more, it's pretty similar.
People talk about vacation, but my job pays so much I'll take months off between contracts. (Engineering)
Also it's hard to compare lifestyles in the US vs Europe. Homes in the US are gigantic, often newish, and have Air Conditioning. Cars in the United States are more feature rich and have higher safety standards (when I was an airbag engineer in 2015)
But you have to think not only about you but also the others. I don't know whether you have children or grandchildren , but if you do I'm sure knowing that they will never have a bad situation is pretty nice. You can't expect all your children and grandchildren to have a well paid job and you can't finance all of them forever.
But do you want your child to immigrate because you live in a country of selfish people? I'm sure you would find the situation difficult.
By the way, the communities you are mentioning in France are French since a few generations and not foreigners.
Where? How? I... this total is about what I’m seeing for shit-tier covers-nothing insurance. Like, there are plans out there that are HCA non-conforming and not that far under $18k/year just for the premiums. Who do I talk to to get total max healthcare spending of $18,000 without an employer-provided plan, in the US? Who’s offering $12,000 annual max-out-of-pocket family plans for $500/m?
$3,600/yr individual, $0 deductible, 8k OOPL
$9,600/yr self + spouse + kid, $0 deductible, 16K OOPL
$12,000/yr self + spouse + 2 kids, $0 deductible, 16K OOPL
Although I don't really think it makes sense to compare costs based on OOPLs. For most people, the deductibles, coinsurance, and copays are much more relevant to actual costs.
I agree that engineering salaries are much higher in the US than in Europe and other non-US countries, however it's worth considering that there are additional expenses to hiring in other countries. My french salary is ~30-40% lower than I was making in the US. However, my cost to my employer is nearly as high. Employer taxes are much higher, my company is required to reimburse my transit and all-but-obligated to cover lunch as well. Certainly, many US software companies do some/all of that, but not all.
And beyond those pure costs, there are more liabilities to the employer. For instance, if they want to fire me, they're legally on the hook for four months of severance. And, I get ~7 weeks of combined vacation time and "comp time" (based on the fact that I work more than 35 hours a week). In the US, I got 2-3 weeks.
I don't have exact numbers, and I don't disagree that there are potentially savings to be had, but I don't think it's nearly as clear cut that you could get anything close to twice as many developers.
It's not 100% accurate (the exact amounts depend on many variables) but gives a good idea. For example, a cost to the employer of USD 100k (87460€/year) gives a before-taxes salary of USD 70.5k, and a salary after all taxes of USD 47k.
What!? That's over 30% of your income gone, and for a relatively average income. That's not even counting VAT and other taxes.... No wonder there's so much "free" stuff in Europe.
And yes, taxes and cotisations are very high. On the other hand they cover most higher costs and risks in life (education, health, basic retirement…).
Still, €61k isn't an average salary. An engineer reaches that after about 10-15 years (from personal experience and some statistics I have access to). It's double the national median.
How does rent and food costs compare to America, do you know?
However the safety net is much more beneficial for less-paid people, at a relatively low cost for them.
I only visited the US so others might be able to provide a more detailed comparison. It seems to me that rent is generally significantly higher in US cities (might be different in lower CoL areas), and groceries and other smaller budgets were slightly higher in France (restaurants, tech purchases, cars…).
US healthcare and education consume a vast portion of your pay. We paid cash for our daughter's college (biomedical engineering) at a total of over $300K. That buys her freedom of choice when it comes time to take a job, get an advanced degree, etc. Her colleagues will have more than $500K USD debt hanging over their heads when you factor interest payments.
The company pays for a portion of health insurance, but much of the cost is picked up by the employee, either though co-payments or deductibles.
We live modestly, drive low-end cars and don't dine out often. We see our European friends taking great vacations and their children bounce in and out of college programs. We see free healthcare, mountain cottages, and other perks unavailable to us.
The median salary here is about £21k nationwide.
I bought my home for £170k, now worth about £230k. it's a decent sized apartment in a nice area in the city where I work. For an indication of size, my living room is about 23ft by 28ft, 2 bedrooms, 2 bathrooms.
Some photos to show what I got for my money:
https://imgur.com/gallery/6oNLRtl
My outgoings each month average out to around £1200k. Mortgage is under £450 a month.
Healthcare is all free, university is free, prescriptions are free.
When I renew at end of year it shoul be around 1.1%
That's nominal - 3.5% - 4.0% is the effective interest rate. I don't know much about mortgages, so not sure if I'm missing something. Congrats on your place - it looks great!
You could imagine that inflation pays ~1% of your mortgage for you because each dollar that you owe is becoming less and less valuable.
I just mentioned it for the sake of providing more information to whomever was reading my comment.
https://www.investopedia.com/articles/investing/082113/under...
Some perspective on the costs that look "scary" for the people outside of the USA. I'll share some personal data based on my 20 years since moving here. I have started with $60K and now I am making close to $250K. All this time I was living in a median cost area (one of the top 20 US cities, east coast).
My average effective tax rate over the last 20 years is 19.6% (this includes federal, state, social security and medicare taxes)
My average medical expenses for a family of four are at 3.6% of my gross salary (includes health/rx/dental/vision insurance premiums and out of pocket expenses)
I've paid cash for my oldest child's education at top 10 public university - ~1.5% of my earning over the last 20 years. I am expecting to pay similar cash amount for my other child.
We live in a 4000 sqft McMansion near the best public schools in the state. My mortgage is ~$820 at 2.5% APR
It does look like your effective tax rate is 31-35%, which is more than my all-inclusive rate of ~24.7%
I'm not so sure. It looks like the average liability for a family (12 monthly premiums plus deductable) comes in at just under $23k[1]. That's the max the average family would pay. Obviously for just a single person total liability is a lot lower.
So for a person like me who makes good money being an engineer, I am still better off in America where I can make a lot of money but also pay a little more in COL / healthcare stuff.
[1] https://www.ehealthinsurance.com/resources/individual-and-fa...
Average salary (take-home): $11874
Average salary (total cost for employer): $19875
Median salary (take-home): $10225
Median salary (total cost for employer): $16526
Starting junior dev salary (take-home): $14800
Starting junior dev salary (total cost for employer): $25800
Senior dev salary (they can go higher, but that's relatively rare for local employers) (take-home): $27700
Senior dev salary (total cost for employer): $52000
VAT is 25%. Safety net is a joke. Health care is universal, but not that good. Education is mediocre at best.
It boils down to real estate prices combined with some companies really really really wanting those people to be on site.
I had my highest rate ever during a brief, beautiful moment in Switzerland where a studio apartment costs ~$2000 per month.
I choose to think that this rate is how much our work is actually worth - otherwise those companies couldn't afford having people on site.
I don't envy the locals though. I spent 2,5 months in Zurich, during which I saved so much that in pre-corona times it would be enough for the minimal allowed down payment for an apartment.
The Swiss don't have a Switzerland of Switzerland where they could pull off the same trick.
I think the real issue is that homeowners vote so much more frequently than renters (who would love to have more housing and lower rents), even though they're technically outnumbered.
At this point in my life you would have to pay me around six figures for me to do CSS seriously on a daily basis (and it’s likely I’ll still burn out and leave). The cross browser and device testing alone is so tedious and stress inducing that I simply won’t do the job below a certain price point (or I will out of desperation but definitely will bounce ASAP). The unsaid thing about doing heavy CSS work is that it doubles as a QA job from all the testing required.
And again, I’m someone that’s good at it. You can’t pay me enough to do it, not if I have choices.
I think we've already experienced the race to the bottom and come out the other side, with $24 being fairly average for the world and the US being on the high side. This all happened years bacj when companies started outsourcing development and IT to India at rock bottom prices, but then received a lot of low-quality work (you get what you pay for). I believe India has a much different approach to software quality than many other countries.
It's taken many companies years to realise that mistake, but I wouldn't call $24 a race to the bottom for skilled labour as that will land you comfortably above average income in the UK
If not, never ever show bitterness for your fellowship that brought honor to the profession, wherever they are.
I hope never to see developers disrespected that way, anywhere in the world.
Presenteeism.
The office "has to" be in Silicon Valley. The employees "have to" be in that office, in an open plan, so the manager can physically see them working. Therefore they have to be paid huge wages to compete against the other employers doing the same.
Might have been a few bad Apples.
Which countries would you suggest for this?
Just the UK?
If I look at the equivalent compensation for people who work for me, the vast majority of developers in the UK and US earn > $100k. Like for like the US employees earn more but that's almost wholly swallowed up in other costs (basically healthcare and our US healthcare plan isn't particularly bad).
And the FAANGs and hedge funds, in my experience, have a reasonably similar dynamic.
The simple fact is that we generally don't hire for PL knowledge except in very specific circumstances (KDB for example). If all we wanted was a coder, there are much more cost effective options than hiring someone, regardless of location.
I once paid a senior front-end engineer far too much to do a fairly involved layout. Three months, an uncountable number of bugs, and one unusable tangle of Sass later I pulled the plug and swore off ever hiring a "CSS Person" again.
I took the Linus+Git approach and said "I'm not writing another line of Python until I understand CSS." After a few weeks of study (I read CSS: The Definitive Guide cover-to-cover) I was able to implement the layout in, and I'm not exaggerating, two hours. No bugs, responsive, cross browser support, etc. Flat out done.
I went back to the dev and asked why they tried to implement it with over a thousand lines of Sass using Flexbox over a few lines with CSS Grid.
It went like this:
Me: "Hey, why did you choose Flexbox over CSS Grid for feature XYZ?"
Senior Front-End Dev (SFED): "I used a grid. Bootstrap's grid."
Me: "No, CSS Grid"
SFED: "Like the 'display: grid' thing? I don't know how that works."
I've never met a CSS Person who has read a book on CSS. Or one that can do the arithmetic on a simple flex-grow/flex-shrink/flex-basis combo.. Even with a cheat sheet.
I'm a back-end dev, I used to think that CSS was "garbage". After learning the ins and outs I think it's a pretty remarkable set of technologies. A true discipline. But, it's hard to find someone who really understands it because it sits at a weird level in the tech stack. Most developers feel it's beneath them or that they "have the gist of it" and most CSS specialists don't have a firm grip on it or keep up with browser developments.
If you're going to work with, hire, or exist as a "CSS Person" within 6-feet of me I'm going to require you to read "CSS: The Definitive Guide" before I give your laptop charger back to you.
This article is good, but it's barely the bare minimum that you need to know about not knowing CSS.
Six-figures for a "CSS Person" who's read CSS:TDG is completely worth it.
CSS and Sass are both worth mastering.
For CSS read: "CSS: The Definitive Guide" (https://www.amazon.com/CSS-Definitive-Guide-Visual-Presentat...)
For Sass read: "Pragmatic Guide to Sass 3" (https://www.amazon.com/Pragmatic-Guide-Sass-Modern-Style/dp/...)
Here are some book and video links (with Amazon affiliate tags snuck in). I've read all of these books cover-to-cover save for the RxJS one. They approach front-end as a set of technologies that should be understood and mastered rather than the "CsS hAckS to GET YoU pAiD!" style of most web tutorials.
Not sure where to point you with React but if you decide to use Angular or Vue I have some suggestions.
CSS/Sass:
"CSS: The Definitive Guide": https://www.amazon.com/CSS-Definitive-Guide-Visual-Presentat...
"Pragmatic Guide to Sass 3: Tame the Modern Style Sheet": https://www.amazon.com/Pragmatic-Guide-Sass-Modern-Style/dp/...
This Sass book has the best structure of any introductory tech book I've ever read.
"TypeScript":
Mastering TypeScript 3: https://www.amazon.com/Mastering-TypeScript-enterprise-ready...
"Programming TypeScript": https://www.amazon.com/Programming-TypeScript-Making-JavaScr...
RxJS: Reactive programming the most significant development in UI technology in 20 years. Once you get the hang of it managing asynchronous events (user generated, network generated, time based, etc) become a breeze.
"Build Reactive Websites with RxJS: Master Observables and Wrangle Events": https://www.amazon.com/Build-Reactive-Websites-RxJS-Observab...
RxMarbles - Interactive RxJS visulizations: https://rxmarbles.com/
Angular:
"Angular Development with TypeScript": https://www.amazon.com/Angular-Development-Typescript-Yakov-...
"Architecting Angular Applications with Redux, RxJS, and NgRx: Learn to build Redux style high-performing applications with Angular 6": https://www.amazon.com/Architecting-Angular-Applications-Red...
Videos:
I watched most of the Layout Land videos when I was getting a grip on the state of CSS. Jen Simmons is a developer advocate at Mozilla and has the best overviews I've seen.
Basics of CSS Grid: The Big Picture: https://www.youtube.com/watch?v=FEnRpy9Xfes
Using Flexbox + CSS Grid Together: Easy Gallery Layout: https://www.youtube.com/watch?v=dQHtT47eH0M
CSS grid is only recently becoming a reasonable tool to use in practice. I don't think any of the top 1% of front end engineers I know would be able to use CSS grid without looking at the documentation.
Based on experience, the kind of person who would be able to use it from memory either 1) is very skilled AND had a reason to use it recently, or 2) someone of medium skill who just recently read the spec but in almost all other ways is less skilled than the people I mentioned in the first paragraph.
You probably don't mean it that way, but not having to use the documentation surely isn't a requirement for competency. I resort to the docs all the time, even with topics I'm quite famialiar and experienced with.
Most likely if you had asked me "why flexbox and not CSS grid" I would have said "because flexbox is able to perfectly well support this use case, and I'd rather not introduce a dependency on a less well supported CSS feature unless I need to".
I personally tend to prefer using the oldest (within reason) CSS feature that lets me accomplish a task. Or I'll pick the one that best conceptually maps to the task I'm trying to accomplish, if there's a significant difference.
As you said, experienced engineers have been dealing with CSS browser support issues for years, so as a habit try to avoid using the latest shiny new features.
Also, experienced engineers do refresh their knowledge from time to time, but you might have caught them between refreshes. Remember that these engineers are also working 40-60 hours per week producing work output in addition to periodically refreshing their skillset. And depending on the environment they've worked in previously they may not have had the ability to use the latest features of whatever technology. Maybe they were working on a legacy app that didn't support ES6, for example. That would be less common now in the days of Babel, but there was a time a few years ago when it would have been reasonable for a working JS engineer not to be familiar with every detail of ES6, as an example.
I also think a lot of the value from a front end developer comes from their ability to merge the technical requirements with a designer's vision, and produce a product that is at the same time usable, accessible and (bare minimum) meets the technical requirements.
Not going to touch the CSS Grid except for two quick comments:
- they absolutely should have been keeping up with CSS Grid, where it was at, and when it was usable and when it isn't
- it is still an open question, because although the overall numbers should 90+% available in browsers, you have to check your own stats. For example, the stuff I work on is often used in Enterprise environments, so IE11 is a requirement (yes, we know our numbers, it is, it could literally cost us 6 figure sales if we don't have support for it). We are using CSS Grid, but we have to be very careful what we use it for and to test those uses in IE to make sure the old Grid spec in IE supports the things we do it with. Otherwise it's back to Flex or other layout techniques. It's not a silver bullet, but I also recognize that is becoming a more unique example these days.
Those are the kinds of things a good FE dev should know though, IMO, and be able to articulate.
Plus, FE devs also need to know HTML and semantics, accessibility, and of course, Javascript. When you can put that all together along with the skills earlier re: usability and accessibility, then you can justify the higher salary brackets.
Digesting that is taking CSS more seriously than most people take learning new programming languages...which is appropriate! Because with CSS, you not only need to learn the language, you are effectively learning something like a language and a framework at the same time. Lots of folks learn the language minimally, piecemeal, on an "as needed basis," and end up wasting a lot of time because they aren't aware of the larger features and how they can be fit together.
Most folks do the equivalent of learning about goto statements, variable declarations, and arithmetic operators, and figuring you have everything you need to do good programming work.
Technically, you do have everything you need. And with a decade of work under your belt using those things, you can build some amazing and good robust systems. It's also easy to build total junk that nobody can understand but you. Perl, of course, is also infamous for having this quality.
This is what’s beautiful about the frontend. It’s “magic” and underneath in code speak it may be ugly but the work speaks for itself. Arguably that is only if you own it and maintain it.
> Lots of folks learn the language minimally, piecemeal, on an "as needed basis," and end up wasting a lot of time because they aren't aware of the larger features and how they can be fit together.
The way I see it, learning about all the ingredients in a recipe will not teach you how to cook. In css techniques are unearthed by a small handful of css artisans and it’s not about learning css itself in 99% of the cases. It’s about digging and finding the best ideas on GitHub, stack and codepen. And hacker news.
Not really, it doesn't talk about custom properties, inline svg, how to style them, etc. All very useful these days, if you want to allow color theming for your web app and not use hacks like custom fonts for icons...
And custom properties are around since 2014 at the very least.
I'm not a CSS person, but I've read three (including CSSTDG) and I still can't do anything useful with CSS.
https://j.eremy.net/confused-about-rem-and-em/
I'm also searching for the material that is specifically oriented on:
- depending on the features existing in all browsers since the last 3-4 years, also mentioning how to make the features "usable" with the older vendor prefixes, but not depending on the JavaScript "fixes" for older browsers, and then showing the examples with minimal number of lines.
- demonstrating all the functionality that can be achieved with CSS only, no JavaScript
- addressing the real-life problems encountered during the design of the modern looking pages, and the goal to use all the power of the commonly available CSS features.
It's far and away the best resource on CSS I've encountered in my 22-year career working with web technology for a living.
No affiliation, just a grateful patron.
> That's a radically misleading comment. It covers much more than layout
Given the site and all 3rd party reviews just mention layout, how is it misleading? Cant find TOC anywhere?
Also, found working discount code 'BRANDEMIC' for 60% off in my travels should any1 bite the bullet.
prev hn sub/182 comments: https://news.ycombinator.com/item?id=20196061
The focus of course is on layout (by far the hardest part of CSS to get right), but it's in the context of building up your entire UI from robust, composable, accessible, standards-compliant, profoundly well-engineered primitives, based on first principles -- which principles are clearly articulated and demonstrated in the site.
It also covers typography (IMO by far the best explanation I've encountered of _why_ to use a typographic scale as the foundation of your design system), as well as touching on things like web components, shadowDOM, custom properties.. . and providing a deeply-expert perspective on the relative merits of utility classes (a la Tailwind et al), among other approaches.
I've been working in web-related roles for a living for over 20 years and have never once encountered a CSS-related resource that was this compelling and useful.
"Can't find TOC"? Um, it's in the site's primary navigation, in the left column. Literally impossible to miss.
I paid the full $100 and was glad to do so. The authors aren't popular (they've clashed on twitter with some big-name FE people like MDalgleish) but their ideas and body of work are unparalleled, and that's what I support.
If I were more selfish I might try to keep my newfound FE superpowers [axiomatic css and composable layout primitives are transformational] a secret, but I find myself wanting to spread the word and support https://every-layout.dev every chance I get.
What browsers zoom dynamically nowadays? When is this actually an issue?
It's a blessing to learn css fresh today, in as much as it's a curse to still have practices from ten years ago still lodged in your memory.
GP is pointing out the parts that haven't changed at all, and are old (over two decades), simple, and common enough to be considered basic knowledge. I had the same reaction to those and one or two others.
Now if this was someone relatively new to CSS I'd understand, but the opening paragraph establishes how long this person was around. Padding-vs-margin in particular was necessary knowledge to do good layouts back in those earlier days (less so now only due to flex and grid, which aren't on here).
Doesn't read that way to me:
> These are things that you learn in a first week of doing web development tutorials.
Sure, padding vs margin isn't exactly new, however `display: inline-block`, ::before and ::after, rem, ch, and :nth-child() certainly weren't in the old html4/xhtml and css2 guidebook that got me into web development!
> I think (hope, really) that gp is just one heavy "/s". The knowledge presented in the article is so basic that it is hard to believe that a person who does html for two years and six figures doesn't know these. As for the article, I fail to see any reason for it to exist beyond cheap media presence. Or maybe I should start a blog, because I'm not even halfway too.
1. New developers might know this, but standards change fast, and it’s hard to keep up.
2. You can’t expect people new to the craft to know everything in the field.
I personally found this article sub-basic. You could probably learn more and better on MDN. I think CSS might be one of few areas on HN where a sub-par article doesn’t get the constructive scrutiny it deserves in the top comments.
You meant CSS tutorials? Never read about "margins collapse" in web development tutorials.
Web development tutorials I read (like 10 years ago) were usually about having a web server renders some data queried from a database into some basic HTML. And adding a form to create/edit rows in the database. Then perhaps adding some basic style like colors and paddings and some jQuery to validate the form. Finally moving that page from localhost to internet.
Let's be honest, web development covers a very large area of knowledge and CSS is not the most interesting part (not saying CSS is not interesting!). I guess most people just skip the CSS documentation and learn it by inspecting other pages and copying rules, and searching "how to do X in CSS" and reading tutorials about their specific question.
The "CSS Zen Garden" from 1999 gets posted about every 3 months and makes it to the front page...
I learned CSS over the years by gradually solving problems I encountered building apps. Compare this to people learning CSS now as evidenced by the #100DaysOfCode tag on Twitter. The learning technique is comprised primarily of using gradient-heavy, absolutely positioned HTML elements to create a photo-realistic, 3D rendering of objects.
The results are pretty amazing, but I have my doubts about whether these skills are easily translatable for building an interactive, responsive UI. Some examples:
https://twitter.com/bauervadim/status/1282264611912327169
https://twitter.com/mercyoncode/status/1282449080132804609
https://twitter.com/ellie_html/status/1276177277315932161
https://twitter.com/thecoffeejesus/status/128204582508278169...
https://twitter.com/alyd789/status/1271200537988431873
https://jsfiddle.net/umaar/YNA5V/
https://jsfiddle.net/umaar/fu4TT/
I'd even make 3d graphics of things like the HTML5 logo: https://i.imgur.com/kuEYpSV.png
I posted this all to a community called "Forrst" (think of it like twitter, but curated for developers and designers).
I spent time giving feedback on other peoples work, I tried to ask insightful questions https://twitter.com/umaar/status/823915022917271552 to have an open discussion, I spent hours replying to comments every few days.
Then one day, Forrst got acquired by Zurb https://zurb.com/blog/zurb-acquires-forrst and later on it got shut down, and with that, I lost access to huge amounts of my work which I hadn't stored anywhere else (some stuff has been archived online, but not everything).
When it comes to web development tips, I now self-host on my own website and it's a really good feeling knowing that it'll be preserved: https://umaar.com/dev-tips/
Thank you for making and sharing!
https://developer.mozilla.org/en-US/docs/Web/CSS/background-...
https://developer.mozilla.org/en-US/docs/Web/CSS/transform-o...