Thread by @morewry

An interesting perspective. (Though I don't agree with every word or implication.)

https://twitter.com/snookca/status/1107166019880173569

"CSS frameworks like Bootstrap enable developers to quickly contribute styling as they’re working on the structure and behaviour of things."

"This blending of concerns can prevent entry level developers and valued specialists (Eg. visual design, accessibility, search engine optimization, and internationalization) from making meaningful contributions to a project."

That point in particular resonates with me. One of the more frustrating aspects of the vertical vs horizontal SoC debate is the frequent lack of acknowledgement that both have value.

So, yeah, you lose out on that if you separate by component alone. But you also need to manage that interreliant relationship between structure, behavior, and style. I'd just prefer us not throwing out the baby with the bathwater in seeking that.

"In an attempt to augment their own weaknesses, these new entrants are introducing tools and practices which serve their own needs, but fail to consider the organization as a whole."

There's probably some truth in this, but I wouldn't point just at newbies. Engineers tend to think they're the annoited, high-holy owners of technology, so no one else should touch the code. Newbies are taught that attitude, they're not the origin of it.

"I[...] think our department’s lack of technical depth may have allowed us to spot the inherent problems [...] sooner. [...T]hese tools are being adopted in the interests of their implementers rather than the organization as a whole."

"You embark on a rebranding project starting with tweaks to Bootstrap’s endless list of 'handy' variables. You survive the unavoidable paralysis of illusory choice only to find the changes you hoped for were only as broad as your rotating cast of developers were consistent."

This I know from repeated personal experience to be true. Been banging that drum for years.

"Remember, compared to development, software will spend the majority of its life under maintenance."

Consider this idea alongside this one, "Frameworks like Bootstrap and React are appealing because they offer incredible up-front velocity." Because this IMO is the origin of much unnecessary hostility between approaches.

"Most likely development will continue throughout the life of an application where the larger a project grows, the harder it becomes to maintain. From a long term perspective, short term objectives can result in long term consequences which only compound over time."

One approach optimizes for quick prototyping and disposability. Delete it and start over, with a resulting quality ceiling. Another optimizes for multi-disciplinary collaboration over time, with a propensity toward calcification. What if you had both?

"A common theme I hear among Bootstrap proponents is 'how easy it is to create a good looking working prototype'. Similarly, React proponents will say 'I like that I never have to leave JavaScript'."

The idea that tools designed by engineers for engineers fail to meet the needs of non-engineers should not be offensive or controversial. It's the most natural result imaginable.

CSS and HTML were languages designed for non-engineers with the active participation of non-engineers. Are they perfect? Nope, far from it. But putting them inside or replacing them with JavaScript destroys their value as tools that enable non-engineers to contribute.

Sure, then you can build your own platform around it, but outside of a megacorp you have more important things to spend your time on. And, frankly, I'd prefer a transferable skill to a company-specific one.

I identify as about half engineer, incidentally.

So it must be said that it's not just for/by engineers in play here. It's also the types of organizations that produce these tools. It's also by/for large technical organizations and small product-oriented start-ups often embedded in Bay Area technical culture.

There's a really interesting interplay there I've been observing for years, though I don't have any pithy conclusions about it.

Not news the web platform wasn't exactly designed with shipping traditional software applications in mind. No wonder it's annoying to that set. But we're doing applications on it. To meet that need it's smart to borrow from the best prior art and listen to the prior experts.

But since how the web was different was what got me into working on it, I'm always hoping we can combine the best of both worlds.

If you think this isn't true, I'm sure you're right that it's not true for everyone. I'm sure you're right that lots of designers would rather use a WYSIWYG that look at or write code. But I assure you it is true for some and that we haven't nailed the WYSIWYG yet.

If you'd like an example you can independently verify rather than my anecdotal experience, consider WordPress Gutenberg's recent accessibility debacle.

I don't think this article does a stellar job of supporting its own points. It makes sense to me because I have some similar concerns and a similarly non-traditional background for a software engineer. It's possible the author and I wouldn't agree on more than we agree.

Very reasonable that when a technical evolution sacrifices being approachable to non-engineers in the name of some other form of progress, it's the non-engineers, non-traditional engineers, and small mixed teams that notice it first.

This is an important point for me because, yes, you should obviously be careful around production code. But there's a difference between security/quality assurance and barriers to multi-disciplinary contributions.

The latter especially drives me crazy. I had someone tell me that CSS in JS was the right choice because we mostly hired JS devs and they would be more comfortable that way. I asked how we expected them to be qualified to write CSS if we weren't hiring or training them to do so.

And this was one of the best things about the web platform when I started. The idea that you had to be a programmer or engineer to code was often actively, consciously resisted and worked against. Particularly in web standards.

And the Bay Area seems like a rather unique ecosystem in many respecs. Tech stacks seem way, way more trend-driven here than they were in my previous experience. Much as it's supposedly about efficiency, it seems very wasteful to me.

Interesting that we're prepared to shut most people out of production codebases lest they make a mistake in encapsulation, but we uncritically ship UI code written by someone without the knowledge and experience to make it responsive or accessible just 'cause they're an engineer.