New Twitter site – is this what HTML is supposed to look like?

[teppo]

Not sure if this a topic for the dev talk area or perhaps rather the pub, but just wanted to share this little gem. It's a small part of the new Twitter web site/app. I'm not quite sure what's going on with that site – but whatever it is, it's getting out hand, and that might have something to do with current craze with components within components within components within... you know the drill ?

For the record, I was trying to figure out what that weird star-icon in the top right corner is/does. Turns out it's some kind of "top tweets on" button (whatever that means), but to learn that you'd first have to a) just randomly click it and see what happens, or b) dig through a whole lot of messy markup to get to the aria-label.

Another thing I found interesting is that when you hover the icon, it gets a background colour. Now, there's nothing particularly interesting in that alone – we have the :hover and :focus states in CSS exactly for that purpose – but the thing is that when you hover over the icon, JS adds the blatantly obvious "r-zv2cs0" class to one of it's parents, which in turn results in that slight shade of blue you see on the site.

I'm glad they've made the effort to make that mess of a markup accessible by applying aria properties and all, but is this really the direction we want the web to go? The obvious ugliness of the markup is one thing, but when you have to explain to the browser things like "this particular div here, buried ~20 levels deep in other divs, is actually a button you can focus on"... that feels wrong on so many levels ?

(And sorry for the clickbait title, by the way.)

[wbmnfktr]

What a beauty!*

I have seen some of these art pieces in the past and they seem to increase each and every day. Flip through those landing page gallery sites and dig into some of them. They often look pretty on the outside but later on when you look closer they aren't. At least not in terms of code quality.

I call it the "Bootcamp Coding Style".

Whenever I see those amazing examples they come in most cases from developers that did some kind of Web Development Bootcamp where they were taught "Do whatever is necessary!". So this example is even more frustrating.

But those aren't the only ones. There are even more in the Wordpress/Elementor/Divi and webflow cosmos. Holy cow.

* I can feel your pain.

 

I wish more people would think about their frontend code more carefully like the guys from Stripe.

 

[dragan]

Welcome to the wonderful world of "modern" SPA frameworks (React et al) !

 

[LostKobrakai]

Quote

is this what HTML is supposed to look like?

I think the reasoning for the above is quite plain: The web becomes a deployment target.

"Proper" HTML is not a business goal at all. Performance/Accessibility/Maintenance/… are. For twitter there's probably also in more detail: Is it easily maintainable with many devs/teams even with high developer fluctuation and potentially ones, which are not super knowledgable in the realms of "proper html"? Are components/design guidelines enforceable over all of their platforms? Can components be widely/easily reused? Removing as many bytes at compile time out of the markup because compile time stuff is cheap. Removing nested divs is dangerous at compile time. Using short unreadable classes on the other hand is simple if you have all markup/css at hand.

Sure accessibility sometimes comes for free with semantic html, but I guess at the scale of twitter even bugs/inconsistencies between the accessibility implementations of browsers will surface and simply doing everything on your own might give you the ability to work around those issues. And twitter likely has the manpower to do so, which is probably not true for anyone here. We struggle with styling those damn html inputs, twitter has probably more obscure browser inconsistencies to care about.

All those things make companies like twitter/google/facebook kinda like the worst examples to follow. The tradeoffs those companies do will hardly ever match with the tradeoffs smaller agencies/companies/single developers should/would choose. 

I see similarities to go and google. Go was created because google had problems with getting young, unexperienced, directly out of college developers up to speed. Therefore they created the a simple to grok C like language with a GC and easy concurrency. Their proper error handling is literally a truck load of if statements. It's nowhere near what more experienced people would expect from a programming language. But it does what it was created for very well and as it's stuff on the server nobody cares if it's particularly verbose or not very abstract. If you want "beautiful" server side applications rather look for a handful of senior erlang developers than a whole can of go developers.

[teppo]

1 hour ago, LostKobrakai said:

Sure accessibility sometimes comes for free with semantic html, but ...

Interestingly one of the first things to consider when making a site accessible – according to experts, whom I have plenty of trust in – is to always use the correct semantic elements. Screen readers, for an example, have varying support for aria properties and roles etc, so overall I have very hard time believing that Twitter did this because it's somehow "the best way to handle it". Rather it looks like they didn't think of accessibility until the very last moment, and since it was essentially added as an afterthought, modifying the source (read: existing components) big time was no longer feasible.

Another thing that points to that direction are complaints I've seen from regular users about the UX of the new service. It's not just about the missing labels and odd ("non-standard") icon choices, but overall the whole experience doesn't seem particularly well thought out. Some of that is no doubt a result of trying to control the user experience as much as possible (prioritised content and all that), but the new site does feel a bit overengineered and underdesigned.

Also, I'm not really sure how nesting dozens of non-semantic elements to create what could be done with a couple of semantic elements and a few of lines of CSS – and then sprinkling it with loads of extra attributes and JavaScript magic to simulate what those semantic elements would've done right out of the box – is good for performance. Or long-term maintainability for that matter.

...

I'm sure you're right in that the way these services are built is intended to minimise the amount of time it takes to get new developers on-board, or because the internal processes demand it, or because it's difficult to find those devs with crazy ninja skills who can single-handedly master every single aspect of a modern web application without even breaking a sweat. Still, to me this seems like a larger, almost industry-wide trend – one that Mike Taylor quite aptly described as the backendification of frontend development.

Anyhow — the point I'm trying to make here is that while there's no doubt that products like React make all sorts of interesting stuff possible (and feasible), that still won't magically make it a good idea to neglect even the most basic design / architectural principles of the "front of the frontend" (as Brad Frost has described his area of expertise on various occasions). In other words: I'm not saying that everything new must suck, just that it seems like too many devs are currently diving head-first into a world of hurt chasing something new and shiny ?

Spoiler

 

[LostKobrakai]

Maybe my guesses about twitter were a bit naively positive, but in the end it still comes down to that those big companies work under their own kind of constraints and people often look at/try to mimic those big companies even if their constraints are completely different, which is the point I was trying to make. They might still make things in bad quality or overly complex or overly verbose for one reason or the other and blindly imitating them is rarely smart.

[dragan]

1 hour ago, teppo said:

Rather it looks like they didn't think of accessibility until the very last moment, and since it was essentially added as an afterthought

For a long time, Twitter didn't care too much about a11y at all. Their most prominent open-source FE product Bootstrap wasn't all that accessible until v.4. With earlier versions, you'd have to use the Paypal a11y plugin for their JS components.

I don't want to open another "Pandora box", but I recently wrote about accessibility and its many pitfalls on the web, and one of the points I made is that a blind faith in FE frameworks can be dangerous. Just because a framework/library is very popular, doesn't mean it's all "plug and play" and covers everything (you mean) it should.

</sorry-for-slightly-derailing>

[teppo]

12 hours ago, LostKobrakai said:

They might still make things in bad quality or overly complex or overly verbose for one reason or the other and blindly imitating them is rarely smart.

That is so true!

Our industry has a long tradition of adopting both tech and practices because they worked for [insert a name of a web giant here], with little understanding of how and why they worked – and even less consideration given to the question "is this really a good idea for us?" ?

[Tom.]

I'm seeing this trend more often. I feel like it's bridging the gap between prototyping and production. When prototyping, using a lot of divs and a lot of classes doesn't really matter. It's about getting the job done quick. But now it seems this way of thinking is making it's way into websites.

Things like TailwindCSS (https://tailwindcss.com) is making strides because you can easily tweak margins, paddings, without having to create loads of classes to manage. It falls down however when you have to make global tweaks or responsive tweaks, but you have to go though every element and replace the classes. This means it's better to use Vue as you can create components, but then you run into things like trying to do server side rendering and SEO issues. Sometimes the solution is worse than the problem. Bigger companies have the man power to manage something like this.

Don't get me wrong I love TailwindCSS, but for me it's fallen down later in a project where I've found it's just taken me too much time to tweak and keep track of everything. I personally still use UIKit, as it comes with a lot of tools at my disposal (Parallax, Sliders, Models, Tooltips) something I would otherwise have to use an amalgamation of different modules. People at Statamic (https://statamic.com) are doing a great job at keeping on top of emerging technologies and I do hope that ProcessWire eventually finds the time to update it's admin interface, things like jQuery UI should be dropped now as well as the use of jQuery in my opinion.

AirB&B was a company I always looked up to, they were doing great things like setting Javascript Guidelines that companies could use so they didn't have to create their own, but even their website is now looking like Twitter (https://www.airbnb.co.uk). It seems to be this the "modern web", but it just looks scary to me.

[LostKobrakai]

2 hours ago, Tom. said:

It falls down however when you have to make global tweaks or responsive tweaks, but you have to go though every element and replace the classes. This means it's better to use Vue as you can create components, but then you run into things like trying to do server side rendering and SEO issues.

I'm not sure what you mean by global tweaks, but I cannot imagine e.g. wanting to change the padding for a whole website at once. If you're talking about e.g. brand colors create a color called "brand" and now you don't need to update the class if the brand color changes just because the name no longer matches. The important part is scope the names to the granularity you're working on. p-1, p-2, p-4, … is to coarse? Try p-sm, p-md, p-lg.

Also I don't think components are the problem. You can do components in server-side languages just as well. Twig or smarty templates are also "components", but without the client side logic. The big problem I see with more wide spread server side usage of component is the gap between non-node server side languages and javascript on the client side. To get the best of both worlds I kinda like the idea of doing business logic on the server in whatever language, delegate to node/v8 for rendering the SSR html (no node exposed to the internet) and sending it to the client, where the matching js framework then hydrates the state based of of the ssr's markup. Svelte makes that especially interesting as it compiles its components down to mostly string concatination for the ssr code. So no expensive vdom calculation or stuff like that just to throw everything out the window after the rendering is done.

[Tom.]

8 minutes ago, LostKobrakai said:

I'm not sure what you mean by global tweaks, but I cannot imagine e.g. wanting to change the padding for a whole website at once. If you're talking about e.g. brand colors create a color called "brand" and now you don't need to update the class if the brand color changes just because the name no longer matches. The important part is scope the names to the granularity you're working on. p-1, p-2, p-4, … is to coarse? Try p-sm, p-md, p-lg.

I'm talking about the granularity of the margin/padding's but also how hard it can be to follow the classes, without changing my markup to something like:

<div class="m-2 md:m-4 lg:m-8
            p-2 md:p-4 lg:p-8
            block sm:flex
            sm:align-middle lg:align-top
            sm:text-center lg:text-left">
  <h2 class="mb-2 md:mb-4 lg:mb-8
             text-md md:text-lg lg:text-xl">
    Title
  </h2>
  <p class="mb-2 md:mb-4 lg:mb-8
            text-sm md:text-md
            text-grey">
    Some text here
  </p>
</div>

I find that when it becomes inline it becomes hard to follow. Personally when I think grid becomes more widely accepted, there is going to be a combination of grid and utility first-css. 

16 minutes ago, LostKobrakai said:

To get the best of both worlds I kinda like the idea of doing business logic on the server in whatever language, delegate to node/v8 for rendering the SSR html (no node exposed to the internet) and sending it to the client, where the matching js framework then hydrates the state based of of the ssr's markup. Svelte makes that especially interesting as it compiles its components down to mostly string concatination for the ssr code. So no expensive vdom calculation or stuff like that just to throw everything out the window after the rendering is done.

If I'm understanding correctly, when I took this approach, I felt it overkill for the simple websites I create. For web apps I can see how this would work as it has level of complexity to it. Twitter I have no doubt will be taking an approach similar to this. Personally I currently use "snippets" and include them in PHP with ProCaches static caching to help the server response time. I've been hitting 99/100 on Google PageInsights with this method. 

[teppo]

17 hours ago, dragan said:

For a long time, Twitter didn't care too much about a11y at all.  [...] I don't want to open another "Pandora box", but I recently wrote about accessibility and its many pitfalls on the web, and one of the points I made is that a blind faith in FE frameworks can be dangerous. Just because a framework/library is very popular, doesn't mean it's all "plug and play" and covers everything (you mean) it should.

</sorry-for-slightly-derailing>

Don't worry, that's not a bad sidestep ?

I mean – sure, I've seen folks take a library or framework that perhaps even boasts about being "accessible" and implement something with it and actually think that they've now got it all handled. While that'd be nice, in reality we're far from that.

Where I currently work we care a whole lot about accessibility. Part of that involves not believing everything third parties say, but actually validating the services we build, and making sure that they are up to standards. For an example I'm currently not aware of a carousel plugin that would properly fulfil WCAG level AA – let alone AAA – out of the box. While I'm kind a Slick fan myself, even their idea of a11y is rather cringeworthy:

Quote

Fully accessible with arrow key navigation.

Yeah, because that's all there is to accessibility, right?

Similarly one of the biggest issues I see with a lot of these modern web-apps (or whatever you choose to call them) is indeed exactly that gross neglect of "proper markup", and all that follows: "Can't we just use something generic and sprinkle it with some magic dust to make it accessible? Isn't that what ARIA and all that stuff is for anyway?"

Sure, assistive technology has been evolving and these days it is indeed possible to tell the browser that a div is a button. Tricks like that might not work everywhere yet, but support is likely to increase. Regardless there are all sorts of problems with that approach, one of the biggest ones being is that we're essentially offloading accessibility and usability to someone else and expecting them to catch the ball where ever and when ever we decide to drop it.

And then there's the problem that something as intangible as accessibility – or usability for that matter – is really hard to summarise into a set of algorithms. Each and every case is different. It's a lot like assessing code quality programmatically: sure, to a point it can be tremendously helpful, but the reality is still that (for the time being) we still need humans to complete the assessment. Tech alone is not the solution.

1 hour ago, LostKobrakai said:

Also I don't think components are the problem. You can do components in server-side languages just as well. Twig or smarty templates are also "components", but without the client side logic.

I know there are some parallel topics going on here and this was perhaps related to another idea altogether, but: this is a very good point, in my opinion. "React made me do it", or "it's like this because components" are not very good excuses to mess things up. It's just tech, and particularly unopinionated tech for that matter. The problem isn't React or components – it's how people use them ?

I feel that this is again very much related to the stuff Brad Frost wrote about in frontend design, react, and the bridge over the great divide. To summarise, even though these days "frontend" goes way beyond HTML+CSS(+JS) and simple GUI level tasks/responsibilities, there's still plenty of demand for so-called frontend designers. Folks who are specialists in crafting that clean, semantic, usable, accessible, and (in the long term) likely maintainable "front of the frontend" layer.

1 hour ago, Tom. said:

Personally when I think grid becomes more widely accepted, there is going to be a combination of grid and utility first-css.

That's roughly the direction I've been going on for a while now. With a few twists.

We discussed Tailwind with Antti a while ago, but I've yet to try it on a real project. Some of the examples I've seen look kind of horrifying, but admittedly I've recently found myself gravitating towards the general idea of utility classes. Perhaps it's the sort of sites I work on, but one key problem for me is that I often find myself using same components (there's that word again) over and over again.

So far I've found this easiest to handle by using as little markup as possible, and delegating the bulk of the visual side to CSS, utilising a loose adaptation of the BEM methodology to manage these so-called components.

Grid is a big reason I've used frontend frameworks, so once that's properly usable (read: no one demands IE11 support) those are going to feel less and less attractive. I used Foundation for the longest time, but their built-in components are – excuse my language – kind of crap. Menu is completely unusable, and other components have at the very least various a11y problems. I haven't yet given a good try to Uikit. Probably should, but after investing all that time into Foundation I'm somewhat vary about diving head first into another "full-featured" framework ?

[apeisa]

I have now used tailwind in two projects and to be honest, I cannot go back to regular frameworks. It is utility framework or just custom css for me currently. 

You can use only "semantic class names" if you want to with tailwind also, but you will soon notice that "bg-green" is great class name, much better than "success-button". 

[teppo]

13 hours ago, apeisa said:

I have now used tailwind in two projects and to be honest, I cannot go back to regular frameworks. It is utility framework or just custom css for me currently. 

You can use only "semantic class names" if you want to with tailwind also, but you will soon notice that "bg-green" is great class name, much better than "success-button". 

I should definitely give this a proper try ?

I was actually writing a longer question here, but then I found this: https://tailwindcss.com/docs/extracting-components/.

Quote

But as a project grows, you'll inevitably find yourself repeating common utility combinations to recreate the same component in many different places. This is most apparent with small components, like buttons, form elements, badges, etc.

One of the benefits of BEM approach has been that when a site has been designed with components in mind, it's easy to start from the lowest level ("button looks like this"), and then re-use the same element. For big sites in particular this is quite nice, while you can still create variations of those elements for use in specific situations (.button--cta, .button--success, .button--click-to-call, etc.)

It looks to me like you achieve a very similar result with Tailwind. Please correct me if I'm wrong, though ?

[apeisa]

Yes, you can have generic btn class and then just tweak it with bg-red and rounded classes for example. 

But biggest win with tailwind for me is that it is actually design system (scales for colors, margins, heights etc) instead of full design that you tweak/modify (foundation, bootstrap etc) or 100% custom styling, where it is very difficult to be consistent with the all decisions and endless possibilities. 

First of the sites was designed already (photoshop) and other was me designing with tailwind. I was surprised how well it suited both of those use cases. 

[teppo]

3 hours ago, apeisa said:

But biggest win with tailwind for me is that it is actually design system (scales for colors, margins, heights etc) instead of full design that you tweak/modify (foundation, bootstrap etc) or 100% custom styling, where it is very difficult to be consistent with the all decisions and endless possibilities. 

Makes sense to me. To be honest the two things I was mostly worried about with Tailwind were repetition and consistency, but the component approach should definitely help with that ?

I wouldn't really describe Foundation as a full design, because the "normal" workflow with it involves more configuration than overriding. That's the main reason I preferred Foundation over Bootstrap and early versions of Uikit: "randomly" overriding what someone else was already doing always felt dirty, and at least in my experience (based on maintaining Bootstrap sites built elsewhere) was somewhat prone to problems... particularly when things had to be updated "upstream" to fix problems within the framework itself.

Haven't been keeping tabs on frontend frameworks lately, but at least Uikit seems to include something similar these days with their SASS/LESS builds ?

We've been crafting styles mostly from scratch. We have what you might call a frontend framework, but it's relatively unopinionated – mostly just stuff like common file structure, build process, font size management, image helpers, and some utility features. One of the benefits of that approach is that each site gets exactly the styles it needs, while one obvious downside is that there's a lot to do.

In my experience this approach works well for very large or very simple projects: you're essentially building your own component library for each site, so you need either big enough budget, or reasonably narrow scope.

[dragan]

To me, BEM + principles of Atomic Design + SASS is the way to go.

I was quickly looking at that Tailwind page "extracting components". You can do exactly that with mixins. It's already there as a fundamental cornerstone of SASS. Why re-invent the wheel? And the M in BEM (modifier) gives you the flexibility you need without adding a truckload of utility classes or duplicating code.

Also, if you want to just have a small, but very flexible layout (grid) SASS lib, I can highly recommend https://www.oddbird.net/susy/

Having said all that - I really really love the way you can use scoped CSS (SASS) inside Vue components. No chance of naming collisions, and you don't even need BEM anymore: Each CSS-rule lives in its own scope. What's actually finally rendered in the build will be named something else, but that doesn't matter. It just works. A great relief and time-saver. 

[LostKobrakai]

25 minutes ago, dragan said:

It's already there as a fundamental cornerstone of SASS. Why re-invent the wheel?

Some thoughts from before tailwind existed https://github.com/laravel/horizon/issues/56 and the other reason afaik was making tailwind work with any css preprocessor and not just SASS.

27 minutes ago, dragan said:

Having said all that - I really really love the way you can use scoped CSS (SASS) inside Vue components. No chance of naming collisions, and you don't even need BEM anymore: Each CSS-rule lives in its own scope. What's actually finally rendered in the build will be named something else, but that doesn't matter. It just works. A great relief and time-saver. 

That's probably how those class names in the initial post come to exist. 

[apeisa]

I use sass with tailwind. Also in my opinion purgecss is must have with tailwind to remove all unnecessary css. 

This is a good read, it nails just how I have felt about BEM and many other ways to css: https://adamwathan.me/css-utility-classes-and-separation-of-concerns/

I do like vanilla css, but writing scalable, easy to maintain css is very difficult. Tailwind helps me a lot regarding that and doesn't take away css/sass/less when I want it. 

My first reaction to utility frameworks was that those are worst idea ever. Glad I gave em chance! 

[szabesz]

Related: MDN Now Built With React
https://www.i-programmer.info/news/87-web-development/12972-mdn-now-built-with-react.html

[teppo]

Related to Tailwind, just stumbled upon https://tailwindcomponents.com/ – thought this might be of interest to someone here. Too bad the first couple of components I checked out were pretty bad in terms of accessibility (inputs without labels etc.) but I bet there are good ones in there as well ?

[apeisa]

Tailwind authors are planning own commercial version of "general components library". High hopes for that.