First of all: HTML+CSS is indeed pretty complex. When you care for A11y, Responsiveness, Performance, Maintenability, complexity rises as a cartesian product.
But if you introduce interactions, the complexities rise by orders of magnitude.
To keep up with those complexities, you need to have a strong engineering background in concurrent/event-driven programming. Because that’s what a UI is.
So a HTML+CSS developer is all good till they need to add a dropdown, or any interactive component. Then you either know how to manage that complexity, or you’re gonna introduce technical dept to the project (or just pass responsibility).
In reality, what I saw, is that developers focused on front-end usually can perfectly learn on the spot what they need to keep their HTML+CSS accessible or responsive. When they have a knowledge gap is usually for past disinterest.
On the other hand, HTML+CSS developers usually have a hard limit when talking about interaction.
So, when I’m searching for developers, I look for the skill super-set, because I can make a HTML+CSS dev out of a FE dev, not the opposite.
I don't think the article is advocating that that designers can just code up some HTML and CSS as a substitute for FE devs. Specialists are necessary, but so are people who can span disciplines, like designers who can do some HTML and CSS. https://chiefexecutive.net/ideo-ceo-tim-brown-t-shaped-stars... If the designer codes up his design, finds problems, and makes improvements, that's time saved for the FE engineer, and eliminates some conflicts like https://library.gv.com/why-you-should-move-that-button-3px-t... It's also faster for the FE engineer to start with working code as opposed to a Sketch or Zeplin document.
Having said that, maybe you're responding to one part of the article, and I'm responding to another, so we're talking past each other.
I think you're right that being really good at HTML/CSS/design is hard AND being really good at writing complicated UI code in JS is hard. They're both hard problems (or can be!). Where I disagree is that moving from an expertise in one to another is asymmetric (JS -> HTML/CSS [easy], HTML/CSS -> JS [hard]). I think it just depends on a person's interests. Some people really only care about the complicated logic so they'll stick to the JS side of things. Some really only care about design and visual aspect so they'll stick to HTML/CSS. Some people can do both very well. And of course there's a million permutations in between. What matters the most I think is whether a person's interested. If a person is interested they'll learn anything eventually. That and likely they'll learn it better than someone who's not interested who's had more time/experience.
I think when you're going to hire someone you should try and screen for interest in the things you need them to do. That and screen for a proven ability to learn things quickly (cognitive ability). That or you take a calculated risk when hiring.
My comment a little bit rushed. What I meant is not that an HTML+CSS dev cannot move to the other side, but that the frontend developers I saw in the last ten years falled in the one of the two categories. Those willing to move to UI/app development already did — or are vocal about wanting to do it.
I don't want to diminish your comment, but we've been able to do pure HTML/CSS dropdowns for awhile now. That was actually a coding test I took back in 2014.
I strongly disagree with your last line as well. Coming from, and knowing many of my colleagues that started as HTML+CSS dev, that went into jQuery -> Backbone -> SPA frameworks -> ES6. It's definitely possible, but it depends if the person (or candidate) has the passion and aptitude to pursue that path.
I used dropdowns as an example for a deceivingly simple UI element. You cannot build a complete dropdown without JS: you need to track keyboard events.
As I answered the other sibling comment: those developers already are UI/app devs in my classification.
It's insane to me that CSS and web layout et. al. has become so complex that it's being described as engineering.
This seems to further be a confusion between design -- that is, the blank-slate, unfettered artistic approach to a user interface -- and design as in the architecture of the software that makes it possible for the art to function in a usable way.
Those are two quite different skillsets and I can't imagine there are very many developers who are very strong at both.
It only makes sense that its become so complicated though. With millions of websites and different use cases something simple would never suffice. So many people need to use it in so many different ways (compared to 20 years ago) that it was forced to become complicated.
Tech recruiter here. From all software engineering profiles, frontend is indeed the hardest to match because the variety of skills is so big. On the one end you have JQuery people who are stuck in 2002, on the other hand you have people like Dan Abramov.
Gatsby uses GraphQL and React to generate a static website. I muttered angrily at it everytime some data was not available in the page because I forgot to update the GraphQL query.
It is just a static website for crying out loud.
But once I got around it, it gave me a score of 100 in performance and 80 in SEO just out of the box. Images are resized and inlined if need be; critical CSS is rendered first; the plugins added niceties like default anchor link in Github. And I could use React components to organize everything, which is a much more ergonomic way of doing reusable markup compared to server-side things like Rails partials.
I would've needed to spend weeks if I had to get here from scratch. Gatsby is bleeding edge and it does best practices - including performance better than most other static site generators. I think the web is only moving forward - there is cambrian explosion of new untested and often ill-thought ideas, but the good ones will survive in the long run.
Gatsby shines when you combine multiple sources - Twitter, Instagram, YouTube feeds along with blog articles as a simplistic example. With GraphQL you have ultimate control over all of it and can organize automate it sensibly without writing custom plugins.
By default Next.js scores 100/100 on performance and best practices eg https://nextjs-3q3i4heaj.now.sh/ (SEO / Accessibility are not 100 as I didn't add meta tags in this example, but are very trivial to add.)
In case of Invision it seems like images / render blocking css that was added outside of Next.js are the main culprit. I've reached out to Jon Wheeler who works on the marketing site to make him aware.
I know it’s trandy to disqualify jQuery, but I’ve yet to see a rational argument that justifies it.
Most small to medium sized projects don’t need MVC, build systems, preprocessors, docker, etc. It's just a collective fascination for shinny overly complex things.
Even if you decide MVC is not needed, it's just as likely you won't need jQuery either. Vanilla JS is pretty powerful and cross browser complaint these days.
Jquery is messy on a large scale, but on a small scale it allows you type far less code than pure JS. On small to medium size projects, it's entirely reasonable to remain the best tool.
Can't agree more with this. Nowadays, it's hard to tell what anyone wants from a front end developer any more, and there have definitely been a few jobs I've interviewed for where they wanted one type while the description was seemingly tailored to the other.
I'd also this is why Gutenberg isn't a great idea for WordPress, and why it feels the software's going the wrong direction. It's trying to aim at the Airbnb/Netflix/Facebook/Google crowd writing SPAs in React and what not, whereas its actual audience are the traditional web developers, agencies and deisgners using standard HTML, CSS and a bit of JavaScript and PHP.
Also a few interesting articles linked there that need posting here individually...
It seems like traditional craftspeople (e.g. woodworking) worked directly with the medium they designed for. AFAIK industrial designers are heavily involved in creating/production their products.
As a developer turned designer I can’t understand how anyone can design for the web and not know how to write HTML and CSS.
There’s always going to be grey area but I don’t think you should need an CS/engineering degree to build a UI.
Surely someone with HTML+CSS skills and a strong focus on layout, user experience and accessibility counts more as a "designer" than a "developer/engineer"? Something akin to the old term "web designer", who might have dabbled in Javascript but worked mostly with HTML+CSS.
In contrast, the terms "developer" and "engineer" definitely have a stronger implication of programming being a major element of the job. Though nowadays on React-using sites, designers might have to work with JSX and JS directly, causing an even greater crossover of the roles.
It seems to me that everyone is trying to normalize terminology and job titles instead of normalizing skills and disciplines. Why not read a book or follow a tutorial? Anyone can learn CSS from zero to expert in a week. Instead we spend time giving ourselves a new title that is just the right mix of accurate and ego-stroking.
> Anyone can learn CSS from zero to expert in a week.
Maybe the (highest level of) basics, but as someone who's been in the industry 21 years and manages all hiring for front-end, the one area of front-end that everyone seems to think is easy but also one of the rarest skills to find on the market is someone who actually understands the finer points of CSS, like why one would use "font-display: swap" in the context of performance, the performance implications of complex CSS on mobile devices, CSS methodology rationale, accessibility implications of using X vs Y, best way of delivering CSS to accelerate the "Start Render" metric, etc.
I am wondering whether this is also a problem in game development or not. In game development to create a game often you need an even more broad skillset in your organization than in web frontend developemnt. Can frontend development learn from game development when defining the roles?
UI is roughly gamedev's equivalent of the HTML/CSS part of "front-end development", and within my experience, UI is one of the more common places for games to have problems.
First of all: HTML+CSS is indeed pretty complex. When you care for A11y, Responsiveness, Performance, Maintenability, complexity rises as a cartesian product.
But if you introduce interactions, the complexities rise by orders of magnitude.
To keep up with those complexities, you need to have a strong engineering background in concurrent/event-driven programming. Because that’s what a UI is.
So a HTML+CSS developer is all good till they need to add a dropdown, or any interactive component. Then you either know how to manage that complexity, or you’re gonna introduce technical dept to the project (or just pass responsibility).
In reality, what I saw, is that developers focused on front-end usually can perfectly learn on the spot what they need to keep their HTML+CSS accessible or responsive. When they have a knowledge gap is usually for past disinterest.
On the other hand, HTML+CSS developers usually have a hard limit when talking about interaction.
So, when I’m searching for developers, I look for the skill super-set, because I can make a HTML+CSS dev out of a FE dev, not the opposite.