Amazing to see the React crowd come around to realize that SSRs and Island Architecture leads to faster applications and better UX. Y’all just reinvented PHP with a bit of jQuery sprinkled in.
That’s fine, but while you are recognizing this, please stop using terms like monolith and calling React “modern” while also calling PHP + progressive enhancement not.
A few years ago I was on a new project at work as the frontend engineer. In code reviews I would recommend reordering of CSS properties, as many of us have a preferred order. One of my teammates pointed out that she would never remember my order and thus wouldn’t likely follow it, so I should find a way to automate it.
Stylelint and Stylelint Order enter chatroom.
As I have become accustomed to over the years, most JavaScript engineers are very familiar with ESLint. If you aren’t, please go research and use it. It cleans up your code, makes it consistent, and helps when you are on a larger team than just you. But, frankly, it even helps when it is just you. JavaScript allows chaos. Semicolons are optional. ‘Nough said. What engineers often don’t even think about is linting their CSS. Many don’t consider CSS a “real language,” but that is a different conversation.
Stylelint is exactly what you would expect if you’ve worked with ESLint. I use the stylelint-config-standard to start. This handles most things. I turn off a few items. The biggest part of my config is the custom ordering of properties using stylelint-order.
As you can see below, I separate my properties into groups (eg. display, grid, dimensions). This means position: absolute; is followed by top, which just makes sense. width and height are right by each other. Alphabetical and other sorts work for different people for different reasons, but logically sorting by type of property just keeps me sane.
The nice thing about this is if your run Stylelint, it’ll throw warnings on all things out of order. But, you can run Stylelint with --fix and it will reorder your properties for you.
I bring this with me on every project. The one below is from this very site. A couple days ago I got ESLint and Stylelint working against Astro— I’m used to using it in React projects. I then fixed over 400 linting issues and now feel a peace knowing my code is consistent.
/* You'll need the following packages: stylelint, stylelint-config-standard, stylelint-order */
{
"extends": "stylelint-config-standard",
"plugins": [
"stylelint-order"
],
"rules": {
"length-zero-no-unit": [true, {"ignore": ["custom-properties"]}],
"property-no-vendor-prefix": null,
"custom-property-pattern": null,
"selector-class-pattern": null,
"selector-id-pattern": null,
"at-rule-no-unknown": null,
"no-descending-specificity": null,
"order/properties-order": [
[
{
"groupName": "display",
"properties": [
"content",
"appearance",
"position",
"top",
"right",
"bottom",
"left",
"z-index",
"display",
"flex",
"flex-direction",
"flex-basis",
"flex-flow",
"flex-grow",
"flex-shrink",
"flex-wrap",
"align-content",
"align-items",
"justify-content",
"justify-items"
]
},
{
"groupName": "grid",
"properties": [
"grid",
"grid-area",
"grid-template",
"grid-template-areas",
"grid-template-rows",
"grid-template-columns",
"grid-row",
"grid-row-start",
"grid-row-end",
"grid-column",
"grid-column-start",
"grid-column-end",
"grid-auto-rows",
"grid-auto-columns",
"grid-auto-flow",
"grid-gap",
"grid-row-gap",
"grid-column-gap",
"gap"
]
},
{
"groupName": "dimensions",
"properties": [
"width",
"max-width",
"min-width",
"height",
"max-height",
"min-height"
]
},
{
"groupName": "margin and padding",
"properties": [
"margin",
"margin-top",
"margin-right",
"margin-bottom",
"margin-left",
"padding",
"padding-top",
"padding-right",
"padding-bottom",
"padding-left"
]
},
{
"groupName": "border and background",
"properties": [
"box-sizing",
"border",
"border-top",
"border-right",
"border-bottom",
"border-left",
"border-width",
"border-radius",
"outline",
"box-shadow",
"background",
"background-color",
"background-image"
]
},
{
"groupName": "font",
"properties": [
"font",
"font-family",
"font-size",
"font-style",
"font-weight",
"line-height",
"color",
"text-decoration",
"font-smoothing"
]
}
],
{
"unspecified": "bottom"
}
]
}
}
So many good points here. The gist? React is not a framework. Next.js barely is. Rails, Laravel, and other far more mature frameworks provide you with the majority of what you need to build an application, leading to you writing less code.
But come on: we’re living in the 2020s and if you’re not at like 95% “framework does it for you” for things that aren’t business logic, then you’ve lashed yourself to a very bad mast ‒ you’re stuck building rote infrastructure instead of working on your app, likely creating a bunch of nasty attack surfaces along the way.
I’m a roll-my-own kinda guy. In the itch the get this blog back in working order I considered both flat-file HTML and building a custom blogging app in PHP. Yeah, I’m a glutton at times. My point is I landed on Astro because I didn’t need a CMS and flat-file is just better for a site like this. Even though I have spent much of my career fighting the urge to reinvent wheels, I have largely used frameworks like CodeIgniter, Laravel, and Rails to get the job done better. Why? They handle the stuff that 1) I don’t want to handle and 2) I don’t know to handle.
React, well:
I would argue that React in itself gets you basically nowhere. It’s a templating language with benefits.
The hard part of an application— and I’ve built React applications for the better part of the last decade— is not the UI layer. HTML and CSS. It ain’t hard. No, the hard part is the business logic. The amount of reinventing routing in every app, reinventing connecting to APIs, the list goes on.
React itself is a templating language. It’s a good one. Half of what drew me to Astro— what powers this new blog— is the JSX syntax and components. But as Johan says, nearly every major framework has this now. Laravel, CraftCMS, Rails. This is standard. Plus they do everything else.
Once you start hitting the cursed parts of your application, the places full of dragons and cobwebs and sweary code comments, React won’t be there to hold your hand. It’ll shrug and say “add a Provider or something, idk.”
So why do we not just use these tried and true frameworks? They feel dated. Maybe many companies switched to mostly JavaScript engineers that don’t know anything other. Instead of hiring folks that can solve problems no matter the solution, they hired specialists. Same reason I warned years ago against hiring folks that listed jQuery on their résumé instead of JavaScript.
It might feel retro or oldtimey and maybe not as fun while you’re building, but your application will be better for it.
Now when you look at it like that, it makes you wonder why we give these people such a large stage while the very quiet majority don’t get a voice at all. The very quiet majority are out there building more than 90% of the web, after all.
Even a slight change in that dynamic would likely have a massive positive impact.
The (extremely) loud minority by Andy Bell
This is something bothering me a lot lately. There seems to be a sense that the majority are using JavaScript-heavy solutions for all the things, but the statistical truth is they are in the minority.
Even if you discount that: considering React has been around for a decade now, < 4% share of the top 10 million websites is pathetic, considering how much we are made to feel like it is the “biggest framework” (well, at least in bundle size, that’s true).
Small tweaks here and there. Added a section on article pages with other posts link the one you are reading. Using tags, I query posts with the tags for the current post and return the top latest few. Nothing complicated. But could help you find something good to read.
I remember when Sass was the only build tool in frontend projects. Then we got Gulp and started building more complex tools. And now you can’t make a “modern” frontend app without big complex build tools.
I wanna get back to not needing build tools.
But that likely won’t happen.
Tools like Astro and Remix might be the next best thing. Provide a “modern” DX— JSX, components, CSS imports, etc.— but have a focus on delivering a lean UX that relies on the platform.
Astro especially does this well in that the frontend is JS-free by default and with Islands you can rehydrate interactive sections of the page.
The cynical curmudgeon in me wants to point out that this is exactly what we did 10 years ago with HTML rendered on server and a jQuery-powered script to make a section of the page interactive. No build tool needed.
But I do get the counter-argument. This makes development “easier” for some. And I’m okay with that. As long as that easier DX doesn’t negatively affect the UX.
The good news is that other, lighter weight tools have come about like Vue, Preact, Lit, or even vanilla Web Components that allow us to build applications that perform much better in the browser while not compromising severely on the DX.
Especially in the long dark winter evenings, having your own website to constantly add to and improve is a great comfort blanket.
I want the vibe to be less like a pristine Apple store, and more like a chaotic second-hand bookstore.
This is one of the goals of this site. It is more stream of thought. But with that comes chaos. I relaunched Finley, I am. yesterday and quickly noted that the welcome article got pushed down because I published a second post. A quick, maybe not permanent fix was to add the Pinned Articles section on the homepage. I will be interating and dabbling on this site and have set it up to make that easier because of Astro. I deploy with a push to Github, making experimenting easy.
During a blizzard of suffering, I drew the blinds down in my heart. I pulled inward so I could survive. I eked out a small corner for myself and gave the bare minimum to the world. I didn’t know any other way forward. I met the needs of my family, I checked off the homekeeping list, and then I crawled back into the darkness. When I sat down for a check in with my psychiatrist, she said I had shut down—my eyes were distant and my voice monotone. I went into hibernation to finish the icy winds of our suffering.
I redesigned and rebuilt my site. Been wanting to do this for years. Then again, I haven’t really been writing for years. I’ve noted before that cynicism affects my ability to write. The last few years have sucked. But I’ve been trying to open the blinds. And some of that comes as writing more.
Over the last three years, I have dove further into music— especially the mandolin—, woodworking, and luthiery. I’ve built a couple ukuleles, a mandola, a mandolin, a beastly guitar, and even a harp. We bought a house. I built a table. And had another baby. I built a playground.
And the blessings have continued unabated. Yeah, I’ve been in a valley, but God’s been providing for us. Promotions, raises, the house, and a church that loves and supports us daily.
I recognize the work of God. And I need to get outta my funk.
So I rebuilt my site. I’ll likely be doing some write-ups on the tech and stuff sooner or later. But in the short, it’s powered by Astro and you should really check that out.
I’m opinionated. If you’ve worked with me or hung out with me for any period of time, you know this. I’ve been building for the web since 2001, before JavaScript libraries, before CSS, before Web Standards. That is a lot of years of experience and with it, one learns a few things. The Standards movement was a major thing just as I was getting started freelancing. jQuery was just coming about as I entered and assisted in teaching a JavaScript class in college. Responsive Web Design was coined and defined as I started my first role at an agency in Chicago.
One learns a few things.
Of the last few years, I have pushed hard against using jQuery. Simply put, most browsers have solid support for new technologies that emulate many of the great features of jQuery. Those native features do it faster, better, and require less code. Remove jQuery and you remove 30+kb of resource load.
I have pushed against Bootstrap. It is a large beast of a library when most sites that include it use it for a grid system and not much else. A grid system can be written in less than 100 lines of CSS that’ll achieve the needs of your site specifically, so why include 200+kb of resources?
I have pushed against WordPress. It’s not good for the developer and offers a not-great experience for the client. There are better CMSs.
So this Summer and Fall, I decided to dabble.
I hadn’t built a website on WordPress in many years. The last one I built was before ACF took off. So I built a client a site in WP and I didn’t hate it. Much of what I have said against WP remains true. Especially after launching a large site on Craft earlier this year. But, for what it does well, it does well. Build a couple of custom plugins was a breeze. ACF made storing complex data from two third-party sources easy and displaying it easier.
I have never used Bootstrap but always maintained that it is best suited for prototyping and administration panels. So as I started building an admin panel for a current project, I decided to try Bootstrap. And I didn’t hate it. There are parts that I won’t touch. The grid system is actually one of them. The spacing utility classes, while useful if you are not writing a lick of CSS, are another. But, the component structure isn’t far from something like Atomic CSS and is actually a welcome thing for the needs of the project. Unfortunately, it requires that the page resources weigh over 300kb, which means I will likely scrap Bootstrap in a few weeks and rewrite with my own CSS.
We must, as developers, not become set in our ways and get dogmatic about certain things. There are things that we should be more opinionated about than others. I wasn’t necessarily wrong with either WordPress or Bootstrap. But, now that I have worked more with each, I can see the lure of them when it comes to getting something done quick and dirty. Atop that, I now have a more solid argument against some points of them.
So if you haven’t dabbled with something in a while or at all, maybe try. You may learn a few things.