Leaderboard

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.)

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.

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.

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 ?

Debian 10 (codename Buster) stable version has been released on July 6. Around a week later it was available for download at my server provider. Yesterday I put myself in good mood … ?and I decided to update my VPS. As Debian 10 comes with PHP 7.3.4-2 bundled, I wanted to take the opportunity to upgrade from PHP 7.0. The process of updating from Debian 9 to Debian 10 was quite smooth. I just had to manually check some configuration files that I previously changed, in particular openssh, sysctl, postfixadmin, and dovecot. All small fixes. I just encountered two issues: emails were not accessible in remote and network.service did not start. The first one was depending from dovecot configuration files, while the second was a bit more tricky to solve. ? I installed PHP 7.3.4-2 FPM/FastCGI and updated the virtual hosts accordingly. So far I did not encounter issues. There were only some incompatibility problems of PhpMyAdmin 4.6.6 (the version that comes from Debian) with PHP 7.3. As I am not in a hurry to update it, for the time being I just reverted its dedicated virtual host to PHP 7.0. And finally let's come to ProcessWire (3.0.123). After the update everything seems to be working well. ? I only had an issue with one of my custom classes. As of PHP 7.2 the word "object" has become a reserved word! ?It took a bit of patience to find, as even with display errors enabled in php.ini you do not get any error (not even in logs) but just the blank screen. ? So far so good! If I encounter any issue I will let you know. Wish you a nice weekend!

https://github.com/processwire/processwire-issues/issues/943

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?" ?

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>

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

We're finally launching a redesign of our website! Doesn't feel like it to us, but our previous design was already from 2013 ? https://ed-works.com/ We like to keep things simple, so the only third-party modules that we installed were Tracy debugger, Admin on steroids and Admin Theme Boss, which we tweaked a little bit to our taste. All in all, there's not much going on inside PW. Our main concern was to serve the frontend with responsive images with a close quality to the originals, and for this, it's important that PW allows us to use ImageMagick for resizing them. We also love to use PW's image tags to add classes to the images. In this case, we use them to display the images with three different sizes. We also had to change the templates to serve the projects to the homepage via Ajax. We hope you guys like our new baby ? Edit: I forgot to refer that we also changed our logo and tweaked our name to ED works.

You could update to the latest dev. Support for empty data attributes was added in this commit.

I did the same mistake as someone here above... I did not echo the render() nor the getScript() ... (my form is in plain HTML and not in a var called $out, therefrom...) It's working now. ;-)

Hi @KarlvonKarton thanks for reporting it. Can you tell me on which version of ProcessWire the module didn't work for you ?

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. 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.

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.

Thanks for your answers and for you generously shared work, @teppo! I really like your Wireframe idea - a well-established and documented way to structure code in ProcessWire MVC way. So one could follow rules that are thought out and described. I understand quite well that in order for this to work one should give up some of his own preferences) Will be looking forward to next additions to the project we've been talking about here.

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.

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.

The module has been published to Packagist, under rockett/sitemap. :)

https://returntrue.win/ have fun ?

That changes things quite a bit. Personally I've never been a part of this kind of team – as strange as it may sound, I've worked in teams where there are backend developers and so-called full-stack developers, but never a "pure" front-end developer ? You've definitely given me something to think about here! Features that are not tied to a specific template have in my use cases usually been partials with very little "logic" behind them, but this would actually be a nice use case for shared (sub)controllers as well, which is something I'll likely dive into soon. Basically the idea is to have a controller that isn't tied to a single template, but rather can be used by multiple templates. Also controllers that inherit other controllers – "base controllers", or whatever they might be called – is another way to achieve shared features. Overall there's a lot you can do with current codebase, but since there are different use cases, it's very much about finding a balance between "not opinionated enough" and "too opinionated" ? As for layouts, I've found the concept really useful, and since I use them in pretty much all projects I work on, this is something I wanted to have built-in and ready-to-use within Wireframe. Placeholders are a key part of this, as they provide an easy way to embed views (of which there may be one or more for each specific template) within commonly shared layouts –aAnd because layouts serve a different purpose from view files (individual views for templates) and partials (smaller pieces of content intended to be embedded within layouts or view files), I've opted to store them separately. This is again one of those cases where it's all about finding the right balance and figuring out what should be available out of the box and what to leave for individual developers to figure out on their own, and I feel that current split between layouts/views/partials is a reasonable one – but because I know there are different opinions, much of this is actually already configurable. Also, since layouts are optional, one can always opt out from using them ?

Each year we cycle 1000km with our company to fight against cancer. To participate with 4 teams we have to collect 20.000 euros. Our graphic designers made some goodies en we also organise a spaghetti fundraiser. To help the sales we decided to make a webshop with our webteam. And of course we used our favourite CMS for the job! ? https://shop.typografics.be/ At this moment we raised more than 20.000 euros, so all our teams can participate. This is a very special project for us, unfortunately one of our colleagues has been diagnosed with cancer and currently is fighting against this terrible disease. Premium PW modules used in this project: PadLoper FormBuilder ProFields Variations With a few hooks here and there we managed to make it work. To handle the payments we made use of Mollie, we created our own payment module and will opensource this soon. You can read more about this project in our blog (in dutch) Unfortunately we're currently only shipping to Belgium We’re already brainstorming to make a 2.0 version of this webshop, so all your feedback is more than welcome.

Sorry for the delay, we had some busy weeks. But we found the time to put the files on github. https://github.com/Typografics/PaymentMollie-PW3 I also made a topic on the modules forum: