Tags: complexity

60

sparkline

Wednesday, September 18th, 2019

Keeping it simple with CSS that scales - Andy Bell

The transcript of Andy’s talk from this year’s State Of The Browser conference.

I don’t think using scale as an excuse for over-engineering stuff—especially CSS—is acceptable, even for huge teams that work on huge products.

Thursday, August 1st, 2019

The web without the web - DEV Community 👩‍💻👨‍💻

I love React. I love how server side rendering React apps is trivial because it all compiles down to vanilla HTML rather than web components, effectively turning it into a kickass template engine that can come alive. I love the way you can very effectively still do progressive enhancement by using completely semantic markup and then letting hydration do more to it.

I also hate React. I hate React because these behaviours are not defaults. React is not gonna warn you if you make a form using divs and unlabelled textboxes and send the whole thing to a server. I hate React because CSS-in-JS approaches by default encourage you to write completely self contained one off components rather than trying to build a website UI up as a whole. I hate the way server side rendering and progressive enhancement are not defaults, but rather things you have to go out of your way to do.

An absolutely brilliant post by Laura on how the priorites baked into JavaScript tools like React are really out of whack. They’ll make sure your behind-the-scenes code is super clean, but not give a rat’s ass for the quality of the output that users have to interact with.

And if you want to adjust the front-end code, you’ve got to set up all this tooling just to change a div to a button. That’s quite a barrier to entry.

In elevating frontend to the land of Serious Code we have not just made things incredibly over-engineered but we have also set fire to all the ladders that we used to get up here in the first place.

AMEN!

I love React because it lets me do my best work faster and more easily. I hate React because the culture around it more than the library itself actively prevents other people from doing their best work.

Wednesday, July 31st, 2019

The Real Dark Web

Charlie’s thoughts on dev perception:

People speak about “the old guard” and “stupid backwards techniques”, forgetting that it’s real humans, with real constraints who are working on these solutions. Most of us are working in a “stupid backwards way” because that “backwardsness” WORKS. It is something that is proven and is clearly documented. We can implement it confident that it will not disappear from fashion within a couple of years.

Tuesday, July 30th, 2019

Don’t build that app! – Luke Jackson - YouTube

This is a fascinating look at how you can get the benefits of React and npm without using React and npm.

Here’s an accompanying article on the same topic.

Thursday, July 25th, 2019

Approachable Tooling | TimKadlec.com

It’s fantastic that our web plumbing has gotten more powerful—tooling today is capable of so much. But all too often, that power comes with increased complexity that negatively impacts developer efficiency. Sometimes that’s unavoidable. The simplest approach doesn’t always win. But that should be the goal—to make things as simple as possible while still accomplishing what needs to be done. Like excellent plumbing, these systems should be as mostly invisible—chugging along, doing what we need them to do without getting in our way.

Monday, July 1st, 2019

Why Did I Have Difficulty Learning React? - Snook.ca

When people talk about learning React, I think that React, in and of itself, is relatively easy to understand. At least, I felt it was. I have components. I have JSX. I hit some hiccups with required keys or making sure I was wrapping child elements properly. But overall, I felt like I grasped it well enough.

Throw in everything else at the same time, though, and things get confusing because it’s hard at first to recognize what belongs to what. “Oh, this is Redux. That is React. That other thing is lodash. Got it.”

This resonates a lot with Dave’s post:

React is an ecosystem. I feel like it’s a disservice to anyone trying to learn to diminish all that React entails. React shows up on the scene with Babel, Webpack, and JSX (which each have their own learning curve) then quickly branches out into technologies like Redux, React-Router, Immutable.js, Axios, Jest, Next.js, Create-React-App, GraphQL, and whatever weird plugin you need for your app.

Sunday, June 16th, 2019

HTML is the Web ~ Pete Lambert

The lowest common denominator of the Web. The foundation. The rhythm section. The ladyfingers in the Web trifle. It’s the HTML. And it is becoming increasingly clear to me that there’s a whole swathe of Frontend Engineers who don’t know or understand the frontend-est of frontend technologies.

Tuesday, June 11th, 2019

Baking accessibility into components: how frameworks help

A very thoughtful post by Hidde that draws a useful distinction between the “internals” of a component (the inner workings of a React component, Vue component, or web component) and the code that wires those components together (the business logic):

I really like working on the detailed stuff that affects users: useful keyboard navigation, sensible focus management, good semantics. But I appreciate not every developer does. I have started to think this may be a helpful separation: some people work on good internals and user experience, others on code that just uses those components and deals with data and caching and solid architecture. Both are valid things, both need love. Maybe we can use the divide for good?

Thursday, June 6th, 2019

Designing for actual performance by Adam Silver

This is something I’ve been thinking about a lot lately. The justification for single page apps feels like circular thinking to me. A JavaScript framework is needed to avoid full page refreshes because full page refreshes are expensive because that means assets will be reloaded …assets like the JavaScript framework that only exists to avoid the full page refresh.

This is how it goes. We put a load of shit into a single web page. This makes the page slow. Slow to load, slow to render. Slow.

Instead of getting rid of the shit, we blame the page refresh.

Wednesday, May 22nd, 2019

Complexity Explorables

A cornucopia of interactive visualisations. You control the horizontal. You control the vertical. Networks, flocking, emergence, diffusion …it’s all here.

Wednesday, April 24th, 2019

Interview with Kyle Simpson (O’Reilly Fluent Conference 2016) - YouTube

I missed this when it was first posted three years ago, but now I think I’ll be revisiting this 12 minute interview every few months.

Everything that Kyle says here is spot on, nuanced, and thoughtful. He talks about abstraction, maintainability, learning, and complexity.

I want a transcript of the whole thing.

Friday, April 12th, 2019

Disenchantment - Tim Novis

I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.

Friday, April 5th, 2019

You probably don’t need that hip web framework - Charged

This is a bit ranty but it resonates with what I’ve been noticing lately:

I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.

Tuesday, April 2nd, 2019

Dev perception

Chris put together a terrific round-up of posts recently called Simple & Boring. It links off to a number of great articles on the topic of complexity (and simplicity) in web development.

I had linked to quite a few of the articles myself already, but one I hadn’t seen was from David DeSandro who wrote New tech gets chatter:

You don’t hear about TextMate because TextMate is old. What would I tweet? Still using TextMate. Still good.

I think that’s a very good point.

It’s relatively easy to write and speak about new technologies. You’re excited about them, and there’s probably an eager audience who can learn from what you have to say.

It’s trickier to write something insightful about a tried and trusted (perhaps even boring) technology that’s been around for a while. You could maybe write little tips and tricks, but I bet your inner critic would tell you that nobody’s interested in hearing about that old tech. It’s boring.

The result is that what’s being written about is not a reflection of what’s being widely used. And that’s okay …as long as you know that’s the case. But I worry that theres’s a perception problem. Because of the outsize weighting of new and exciting technologies, a typical developer could feel that their skills are out of date and the technologies they’re using are passé …even if those technologies are actually in wide use.

I don’t know about you, but I constantly feel like I’m behind the curve because I’m not currently using TypeScript or GraphQL or React. Those are all interesting technologies, to be sure, but the time to pick any of them up is when they solve a specific problem I’m having. Learning a new technology just to mitigate a fear of missing out isn’t a scalable strategy. It’s reasonable to investigate a technology because you genuinely think it’s exciting; it’s quite another matter to feel like you must investigate a technology in order to survive. That way lies burn-out.

I find it very grounding to talk to Drew and Rachel about the people using their Perch CMS product. These are working developers, but they are far removed from the world of tools and frameworks forged in the startup world.

In a recent (excellent) article comparing the performance of Formula One websites, Jake made this observation at the end:

However, none of the teams used any of the big modern frameworks. They’re mostly Wordpress & Drupal, with a lot of jQuery. It makes me feel like I’ve been in a bubble in terms of the technologies that make up the bulk of the web.

I think this is very astute. I also think it’s completely understandable to form ideas about what matters to developers by looking at what’s being discussed on Twitter, what’s being starred on Github, what’s being spoken about at conferences, and what’s being written about on Ev’s blog. But it worries me when I see browser devrel teams focusing their efforts on what appears to be the needs of typical developers based on the amount of ink spilled and breath expelled.

I have a suspicion that there’s a silent majority of developers who are working with “boring” technologies on “boring” products in “boring” industries …you know, healthcare, government, education, and other facets of everyday life that any other industry would value more highly than Uber for dogs.

Trys wrote a great blog post called City life, where he compares his experience of doing CMS-driven agency work with his experience working at a startup in Shoreditch:

I was chatting to one of the team about my previous role. “I built two websites a month in WordPress”.

They laughed… “WordPress! Who uses that anymore?!”

Nearly a third of the web as it turns out - but maybe not on the Silicon Roundabout.

I’m not necessarily suggesting that there should be more articles and talks about older, more established technologies. Conferences in particular are supposed to give audiences a taste of what’s coming—they can be a great way of quickly finding out what’s exciting in the world of development. But we shouldn’t feel bad if those topics don’t match our day-to-day reality.

Ultimately what matters is building something—a website, a web app, whatever—that best serves end users. If that requires a new and exciting technology, that’s great. But if it requires an old and boring technology, that’s also great. What matters here is appropriateness.

When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.

Friday, March 29th, 2019

City life | Trys Mudford

Not only does the differentiation of terms create a divide within the industry, the term ‘web app’ regularly acts as an excuse for corner cutting and the exclusion of users.

Straight-talkin’ Trys:

We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.

CSS { In Real Life } | Building a dependency-free site in 2019

I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.

Monday, March 25th, 2019

Simple & Boring | CSS-Tricks

Let’s take a meandering waltz through what other people have to say about simplicity.

Monday, March 18th, 2019

The Lean Web video from Boston CSS | Go Make Things

A good talk from from Chris Ferdinandi, who says:

One of the central themes of my talk on The Lean Web is that we as developers repeatedly take all of the great things the web and browsers give us out-of-the-box, break them, and then re-implement them poorly with JavaScript.

Wednesday, March 6th, 2019

The “Backendification” of Frontend Development – Hacker Noon

Are many of the modern frontend tools and practices just technical debt in disguise?

Ooh, good question!