Tag: mean

What Does it Mean to Be “Full Stack”?

I was asked this recently by a fellow developer who was at the same web tech conference I was at. This developer had met a lot of new people who literally introduced themselves as full-stack developers sort of the way Bob Vance, Vance Refrigeration would on The Office, but it was Tony Frank, Full-Stack Developer instead.

I suspect the developer asking the question taken from the title of this post already knew the basic idea of what people mean by “full-stack developer,” but was wondering what the heck it’s all about. There was a tone in the question. A tone that suggested this person isn’t exactly in love with the term.

These days, probably a bit of DevOps (e.g. Git, testing, and getting sites to production). The “stack” is all these things combined, so a full-stack developer is shorthand for: when it comes to building websites, I can do it all.

There are some stacks that have achieved notoriety over the years. Maybe you’ve heard of the LAMP stack?

Linux Apache MySQL PHP

A full-stack developer on that stack means you know Linux, Apache, MySQL, and PHP. (Abstractly: server software, web server, database, back-end language.) This site runs on that stack, and I’m solely responsible for its development, so I guess I’m a full-stack developer in some loose sense.

But “loose” is a generous interpretation. I don’t know the first thing about Linux, except that’s what runs my web servers. I don’t know much about Apache, except that I sometimes use HTAccess directives to do things. I could count the number of MySQL queries I’ve written on my two hands, and I only really know PHP in the context of WordPress.

Looked at that way, I’m barely a developer at all. Full stack, on the other hand, generally refers to tossing front-end tasks into the mix and I’m competent enough in that space that my front-end skill set alone, has allowed me to build dozens (or hundreds!) of sites throughout my career. Full-stack-enough, anyway.

There are loads of other stacks.

LAMP isn’t particularly prescriptive about how you build the front-end. It came from an era where it was assumed you’d build a back end to spit out HTML and that’s your front end.

Another stack that’s achieved notoriety since the Grand Arrival of JavaScript is the MEAN stack.

MongoDB Express Angular Node

It is perfectly plausible to replace parts of a stack. Perhaps you’d use Nginx instead of Apache, or PostgreSQL instead of MySQL in what’s otherwise LAMP stack. MEAN is notable in that every layer of the stack was replaced with new technology. Node brought JavaScript to the back end, which could power web servers, handle routing, connect data sources, run build processes, compile code, and more.

A full-stack developer in this world is writing nearly everything in JavaScript. No wonder there is somewhat of an explosion of people considering themselves “full” stack. A single language, like JavaScript, that runs in browsers itself and is a paramount front-end technology is a widely transferrable skill.

The MEAN stack can have layers swapped out just as easily as LAMP. Perhaps you use a data store like Fauna or Firebase instead. Perhaps you use Vue or React instead of Angular. Perhaps you don’t need Express because you leave your routing to a framework or do it client-side.

Shawn Wang calls another a popular stack STAR:

Design Systems TypeScript Apollo React

That’s JavaScript all the way down.

It’s notable that, while we’re still thinking of this as a stack, we’re thinking less about our servers and server software to the point they aren’t really a key part of the stack. Not that developers and companies don’t take it seriously, but it’s more abstracted now than it has traditionally been. I’d point to the world of serverless as a case in point. The questions aren’t about what operating system our servers should use; it’s what platform is the most cost-effective to run our JavaScript functions.

So, stacks evolve over time. But it’s not just what technologies they use, but what technology we even consider a part of a stack. What full-stack means morphs over time.. We’re in a place right now where knowing JavaScript grants you a full-stack merit badge. You can work with client site frameworks, architect components and piece them together to build an entire front end. You can write web servers. You can write back-end code that talks to APIs. You can do all the state management you need. You can construct build processes and deployment pipelines. You can even bring CSS into JavaScript if you’re so inclined.

Even if you’re largely focused on JavaScript, people’s skillsets are generally wider than that. Throw in some HTML and CSS competency, Git foo, and a little DevOps hobby and you’re a real web powerhouse. You can do it all! A renaissance man! Lord of the seven kingdoms!

I think that’s kinda awesome, actually. It truly empowers developers. While it’s worth considering where the barriers of entrance for front-end development or high, it’s also interesting to consider all the places where that bar has been lowered. It’s particularly cool for me to see front-end development grow and grow to the point of nearly swallowing up the entire stack. The All-Powerful Front-End Developer, as it were.

It reminds me an awful lot of how powerful being a WordPress site-slinger feels. You can do a lot, even if you don’t deeply understand every little bit of it.

My conference acquaintance went on:

Why are some developers so proud of being a full stack? Many of them say it with a prideful smile. They, for some reason, feel the need to emphasize full stack when introducing themselves.

I suspect it’s just that: Pride.

Pride is a tricky thing. It meant the world to me when my parents ceaselessly told me they were proud of me or something I did. A positive thing on both sides. But, strangely enough, pride is also one of the seven deadly sins and one, as they say, that might be the root of all the rest. I don’t want to over-blow things, but I think there is some connection here. It’s one thing to be empowered and to feel strong and capable, but it’s another to be boastful and not sense the edges of your ability.

We’ve all got plenty of edges, particularly when it comes to doing an exemplary job versus merely getting the job done. Standing out these days requires being exemplary. How is your visual design skill? Are you building design systems or implementing existing ones? How many years have you maintained systems? Do you have a good eye for the most painful kinds of technical debt? How are you at helping co-workers succeed? Can you facilitate a user testing session? How good are you at diagnosing performance bottlenecks? What if there are serious server problems? Does your full stack moniker help you comprehend server logs? Are you versed in accessibility audits? Have you ever dealt with tricky relational data and slow queries?

I’m not trying to convince anyone they aren’t a full-stack developer or don’t deserve that particular merit badge — just that the web is a big place with divergent needs and ever-morphing stacks that all require different sets of skills. If you’re interviewing for a job asking for a full-stack developer, by all means, tell them how full-stack-y you are.

The post What Does it Mean to Be “Full Stack”? appeared first on CSS-Tricks.

CSS-Tricks

, ,

Edge Goes Chromium: What Does it Mean for Front-End Developers?

In December 2018, Microsoft announced that Edge would adopt Chromium, the open source project that powers Google Chrome. Many within the industry reacted with sadness at the loss of browser diversity. Personally, I was jubilant. An official release date has yet to be announced, but it will be at some point this year. With its release, a whole host of HTML, JavaScript and CSS features will have achieved full cross-browser support.

The preview build is now available for Windows, and coming soon for Mac.

Not so long ago, I penned an article titled “The Long Slow Death of Internet Explorer.” Some of us are lucky enough have abandoned that browser already. But it wasn’t the only thing holding us back. Internet Explorer was the browser we all hated and Edge was meant to be its much-improved replacement. Unfortunately, Edge itself was quite the laggard. EdgeHTML is a fork of Trident, the engine that powered Internet Explorer. Microsoft significantly under-invested in Edge. The apple didn’t fall far from the tree. Edge’s User Voice website was a nice idea, allowing developers to vote for which features they wanted to be implemented. Unfortunately, as Dave Rupert put it, voting on the site was “like throwing coins in a wishing well.” The most requested features were left unimplemented for years.

There are a lot of features that pre-Chromium Edge doesn’t currently support but are available in other modern browsers and, once they’ve made the switch, we’ll be able to use them. Many of them can’t be polyfilled or worked around, so this release is a big deal.

caniuse.com comparing the final non-Chromium version of Edge to the other popular modern browser

Features we can look forward to using

So just what are those features, exactly? Let’s outline them right here and start to get excited about all the new things we’ll be able to do.

Custom Elements and Shadow DOM

Together, custom elements and shadow DOM allow developers to define custom, reusable and encapsulated components. A lot of people were asking for this one. People have been voting for its implementation since 2014, and we’re finally getting it.

HTML details and summary elements

The <details> and <summary> elements are part of HTML5 and have been supported since 2011 in Chrome. Used together, the elements generate a simple widget to show and hide content. While it is trivial to implement something similar using JavaScript, the <details> and <summary> elements work even when JavaScript is disabled or has failed to load.

See the Pen
details/summary
by CSS GRID (@cssgrid)
on CodePen.

Javascript Font Loading API

This one means a lot to some people. All modern browsers now support the CSS font-display property. However, you still might want to load your fonts with JavaScript. Font-loading monomaniac Zach Leatherman has an explainer of why you might want to load fonts with JavaScript even though we now have broad support for font-display. Ditching polyfills for this API is important because this JavaScript is, according to Zach:

[…] usually inlined in the critical path. The time spent parsing and executing polyfill JavaScript is essentially wasted on browsers that support the native CSS Font Loading API.”

In an article from 2018, Zach lamented:

[…] browser-provided CSS Font Loading API has pretty broad support and has been around for a long time but is confoundedly still missing from all available versions of Microsoft Edge.”

No longer!

JavaScript flat and flatMap

Most easily explained with a code snippet, flat() is useful when you have an array nested inside another array.

const things = ['thing1', 'thing2', ['thing3', ['thing4']]] const flattenedThings = things.flat(2); // Returns ['thing1', 'thing2', 'thing3', 'thing4']

As its name suggests, flatMap() is equivalent to using both the map() method and flat().

These methods are also supported in Node 11. 🎉

JavaScript TextEncoder and TextDecoder

TextEncoder and TextDecoder are part of the encoding spec. They look to be useful when working with streams.

JavaScript Object rest and object spread

These are just like rest and spread properties for arrays.

const obj1 = {   a: 100,   b: 2000 }  const obj2 = {   c: 11000,   d: 220 }  const combinedObj = {...obj1, ...obj2}  // {a: 100, b: 2000, c: 11000, d: 220}

JavaScript modules: dynamic import

Using a function-like syntax, dynamic imports allow you to lazy-load ES modules when a user needs them.

button.addEventListener("click", function() {   import("./myModule.js").then(module => module.default()); });

CSS background-blend-mode property

background-blend-mode brings Photoshop style image manipulation to the web.

CSS prefers-reduced-motion media query

I can’t help feeling that not making people feel sick should be the default of a website, particularly as not all users will be aware that this setting exists. As animation on the web becomes more common, it’s important to recognize that animation can cause causes dizziness, nausea and headaches for some users.

CSS font-display property

font-display has been well-covered on CSS-Tricks before. It’s a way to control the perceived performance of font loading.

CSS caret-color property

Admittedly a rather trivial feature, and one that could have safely and easily been used as progressive enhancement. It lets you style the blinking cursor in text input fields.

8-digit hex color notation

It’s nice to have consistency in a codebase. This includes sticking to either
the RGB, hexadecimal or HSL color format. If your preferred format is hex, then you had a problem because it required a switch to rgba() any time you needed to define transparency. Hex can now include an alpha (transparency) value. For example, #ffffff80 is equivalent to rgba(255, 255, 255, .5). Arguably, it’s not the most intuitive color format and has no actual benefit over rgba().

Intrinsic sizing

I’ve not seen as much hype or excitement for intrinsic sizing as some other new CSS features, but it’s the one I’m personally hankering for the most. Intrinsic sizing determines sizes based on the content of an element and introduces three new keywords into CSS: min-content, max-content and fit-content(). These keywords can be used most places that you would usually use a length, like height, width, min-width, max-width, min-height, max-height, grid-template-rows, grid-template-columns, and flex-basis.

CSS text-orientation property

Used in conjunction with the writing-mode property, text-orientation, specifies the orientation of text, as you might expect.

See the Pen
text-orientation: upright
by CSS GRID (@cssgrid)
on CodePen.

CSS :placeholder-shown pseudo-element

placeholder-shown was even available in Internet Explorer, yet somehow never made it into Edge… until now. UX research shows that placeholder text should generally be avoided. However, if you are using placeholder text, this is a handy way to apply styles conditionally based on whether the user has entered any text into the input.

CSS place-content property

place-content is shorthand for setting both both the align-content and justify-content.

See the Pen
place-content
by CSS GRID (@cssgrid)
on CodePen.

CSS will-change property

The will-change property can be used as a performance optimization, informing the browser ahead of time that an element will change. Pre-Chromium Edge was actually good at handling animations performantly without the need for this property, but it will now have full cross-browser support.

CSS all property

button { background: none; border: none; color: inherit; font: inherit; outline: none; padding: 0; }

Sadly, though, the revert keyword still hasn’t been implemented anywhere other than Safari, which somewhat limits the mileage we can get out of the all property.

CSS Shapes and Clip Path

Traditionally, the web has been rectangle-centric. It has a box model, after all. While we no longer need floats for layout, we can use them creatively for wrapping text around images and shapes with the shape-outside property. This can be combined with the clip-path property, which brings the ability to display an image inside a shape.

Clippy is an online clip-path editor

CSS :focus-within pseudo-class

If you want to apply special styles to an entire form when any one of its inputs are in focus, then :focus-within is the selector for you.

CSS contents keyword

This is pretty much essential if you’re working with CSS grid. This had been marked as “not planned” by Edge, despite 3,920 votes from developers.

For both flexbox and grid, only direct children become flex items or grid items, respectively. Anything that is nested deeper cannot be placed using flex or grid-positioning. In the words of the spec, when display: contents is applied to a parent element, “the element must be treated as if it had been replaced in the element tree by its contents,” allowing them to be laid out with a grid or with flexbox. Chris goes into a more thorough explanation that’s worth checking out.

There are, unfortunately, still some bugs with other browser implementations that affect accessibility.

The future holds so much more promise

We’ve only looked at features that will be supported by all modern browsers when Edge makes the move to Chromium. That said, the death of legacy Edge also makes a lot of other features feel a lot closer. Edge was the only browser dragging its feet on the Web Animation API and that showed no interest in any part of the Houdini specs, for example.

Credit: https://ishoudinireadyyet.com

The impact on browser testing

Testing in BrowserStack (left) and various browser apps on my iPhone (right)

Of course, the other huge plus for web developers is less testing. A lot of neglected Edge during cross-browser testing, so Edge users were more likely to have a broken experience. This was the main reason Microsoft decided to switch to Chromium. If your site is bug-free in one Chromium browser, then it’s probably fine in all of them. In the words of the Edge team, Chromium will provide “better web compatibility for our customers and less-fragmentation of the web for all web developers.” The large variety of devices and browsers makes browser testing one of the least enjoyable tasks that we’re responsible for as front-end developers. Edge will now be available for macOS users which is great for the many of us who work on a Mac. A subscription to BrowserStack will now be slightly less necessary.

Do we lose anything?

To my knowledge, the only feature that was supported everywhere except Chrome is SVG color fonts, which will no longer work in the Edge browser. Other color font formats (COLR, SBIX, CBDT/CBLC) will continue to work though.

What about other browsers?

Admittedly, Edge wasn’t the last subpar browser. All the features in this article are unsupported in Internet Explorer, and always will be. If you have users in Russia, you’ll need to support Yandex. If you have users in Africa, you’ll need to support Opera Mini. If you have users in China, then UC and QQ will be important to test against. If you don’t have these regional considerations, there’s never been a better time to ditch support for Internet Explorer and embrace the features the modern web has to offer. Plenty of PC users have stuck with Internet Explorer purely out of habit. Hopefully, a revamped Edge will be enough to tempt them away. An official Microsoft blog entry titled “The perils of using Internet Explorer as your default browser” concluded that, “Internet Explorer is a compatibility solution…developers by and large just aren’t testing for Internet Explorer these days.” For its remaining users, the majority of the web must look increasingly broken. It’s time to let it die.

Is Google a megalomaniac?

Life is about to get easier for web developers, yet the response to the Microsoft’s announcement was far from positive. Mozilla, for one, had a stridently pessimistic response, which accused Microsoft of “officially giving up on an independent shared platform for the internet.” The statement described Google as having “almost complete control of the infrastructure of our online lives” and a “monopolistic hold on unique assets.” It concluded that “ceding control of fundamental online infrastructure to a single company is terrible.”

Many have harked back to the days of IE6, the last time a browser achieved such an overwhelming market share. Internet Explorer, having won the browser war, gave in to total stagnation. Chrome, by contrast, ceaselessly pushes new features. Google participates actively with the web standards bodies the W3C and the WHATWG. Arguably though, it has an oversized influence in these bodies and the power to dictate the future shape of the web. Google Developer Relations does have a tendency to hype features that have shipped only in Chrome.

From competition to collaboration

Rather than being the new IE, Edge can help innovate the web forward. While it fell behind in many areas, it did lead the way for CSS grid, CSS exclusions, CSS regions and the new HTML imports spec. In a radical departure from historical behavior, Microsoft have become one of the world’s largest supporters of open source projects. That means all major browsers are now open source. Microsoft have stated that they intend to become a significant contributor to Chromium — in fact, they’ve already racked up over 300 merges. This will help Edge users, but will also benefit users of Chrome, Opera, Brave, and other Chromium-based browsers.

The post Edge Goes Chromium: What Does it Mean for Front-End Developers? appeared first on CSS-Tricks.

CSS-Tricks

, , , , ,
[Top]

What Hooks Mean for Vue

Not to be confused with Lifecycle Hooks, Hooks were introduced in React in v16.7.0-alpha, and a proof of concept was released for Vue a few days after. Even though it was proposed by React, it’s actually an important composition mechanism that has benefits across JavaScript framework ecosystems, so we’ll spend a little time today discussing what this means.

Mainly, Hooks offer a more explicit way to think of reusable patterns — one that avoids rewrites to the components themselves and allows disparate pieces of the stateful logic to seamlessly work together.

The initial problem

In terms of React, the problem was this: classes were the most common form of components when expressing the concept of state. Stateless functional components were also quite popular, but due to the fact that they could only really render, their use was limited to presentational tasks.

Classes in and of themselves present some issues. For example, as React became more ubiquitous, stumbling blocks for newcomers did as well. In order to understand React, one had to understand classes, too. Binding made code verbose and thus less legible, and an understanding of this in JavaScript was required. There are also some optimization stumbling blocks that classes present, discussed here.

In terms of the reuse of logic, it was common to use patterns like render props and higher-order components, but we’d find ourselves in similar “pyramid of doom” — style implementation hell where nesting became so heavily over-utilized that components could be difficult to maintain. This led me to ranting drunkenly at Dan Abramov, and nobody wants that.

Hooks address these concerns by allowing us to define a component’s stateful logic using only function calls. These function calls become more compose-able, reusable, and allows us to express composition in functions while still accessing and maintaining state. When hooks were announced in React, people were excited — you can see some of the benefits illustrated here, with regards to how they reduce code and repetition:

In terms of maintenance, simplicity is key, and Hooks provide a single, functional way of approaching shared logic with the potential for a smaller amount of code.

Why Hooks in Vue?

You may read through this and wonder what Hooks have to offer in Vue. It seems like a problem that doesn’t need solving. After all, Vue doesn’t predominantly use classes. Vue offers stateless functional components (should you need them), but why would we need to carry state in a functional component? We have mixins for composition where we can reuse the same logic for multiple components. Problem solved.

I thought the same thing, but after talking to Evan You, he pointed out a major use case I missed: mixins can’t consume and use state from one to another, but Hooks can. This means that if we need chain encapsulated logic, it’s now possible with Hooks.

Hooks achieve what mixins do, but avoid two main problems that come with mixins:

  • They allows us to pass state from one to the other.
  • They make it explicit where logic is coming from.

If we’re using more than one mixin, it’s not clear which property was provided by which mixin. With Hooks, the return value of the function documents the value being consumed.

So, how does that work in Vue? We mentioned before that, when working with Hooks, logic is expressed in function calls that become reusable. In Vue, this means that we can group a data call, a method call, or a computed call into another custom function, and make them freely compose-able. Data, methods, and computed now become available in functional components.

Example

Let’s go over a really simple hook so that we can understand the building blocks before we move on to an example of composition in Hooks.

useWat?

OK, here’s were we have, what you might call, a crossover event between React and Vue. The use prefix is a React convention, so if you look up Hooks in React, you’ll find things like useState, useEffect, etc. More info here.

In Evan’s live demo, you can see where he’s accessing useState and useEffect for a render function.

If you’re not familiar with render functions in Vue, it might be helpful to take a peek at that.

But when we’re working with Vue-style Hooks, we’ll have — you guessed it — things like: useData, useComputed, etc.

So, in order for us look at how we’d use Hooks in Vue, I created a sample app for us to explore.

In the src/hooks folder, I’ve created a hook that prevents scrolling on a useMounted hook and reenables it on useDestroyed. This helps me pause the page when we’re opening a dialog to view content, and allows scrolling again when we’re done viewing the dialog. This is good functionality to abstract because it would probably be useful several times throughout an application.

import { useDestroyed, useMounted } from "vue-hooks";  export function preventscroll() {   const preventDefault = (e) => {     e = e || window.event;     if (e.preventDefault)       e.preventDefault();     e.returnValue = false;   }    // keycodes for left, up, right, down   const keys = { 37: 1, 38: 1, 39: 1, 40: 1 };    const preventDefaultForScrollKeys = (e) => {     if (keys[e.keyCode]) {       preventDefault(e);       return false;     }   }    useMounted(() => {     if (window.addEventListener) // older FF       window.addEventListener('DOMMouseScroll', preventDefault, false);     window.onwheel = preventDefault; // modern standard     window.onmousewheel = document.onmousewheel = preventDefault; // older browsers, IE     window.touchmove = preventDefault; // mobile     window.touchstart = preventDefault; // mobile     document.onkeydown = preventDefaultForScrollKeys;   });    useDestroyed(() => {     if (window.removeEventListener)       window.removeEventListener('DOMMouseScroll', preventDefault, false);      //firefox     window.addEventListener('DOMMouseScroll', (e) => {       e.stopPropagation();     }, true);      window.onmousewheel = document.onmousewheel = null;     window.onwheel = null;     window.touchmove = null;     window.touchstart = null;     document.onkeydown = null;   }); } 

And then we can call it in a Vue component like this, in AppDetails.vue:

<script> import { preventscroll } from "./../hooks/preventscroll.js"; ...  export default {   ...   hooks() {     preventscroll();   } } </script>

We’re using it in that component, but now we can use the same functionality throughout the application!

Two Hooks, understanding each other

We mentioned before that one of the primary differences between hooks and mixins is that hooks can actually pass values from one to another. Let’s look at that with a simple, albeit slightly contrived, example.

Let’s say in our application we need to do calculations in one hook that will be reused elsewhere, and something else that needs to use that calculation. In our example, we have a hook that takes the window width and passes it into an animation to let it know to only fire when we’re on larger screens.

In the first hook:

import { useData, useMounted } from 'vue-hooks';  export function windowwidth() {   const data = useData({     width: 0   })    useMounted(() => {     data.width = window.innerWidth   })    // this is something we can consume with the other hook   return {     data   } }

Then, in the second we use this to create a conditional that fires the animation logic:

// the data comes from the other hook export function logolettering(data) {   useMounted(function () {     // this is the width that we stored in data from the previous hook     if (data.data.width > 1200) {       // we can use refs if they are called in the useMounted hook       const logoname = this.$  refs.logoname;       Splitting({ target: logoname, by: "chars" });        TweenMax.staggerFromTo(".char", 5,         {           opacity: 0,           transformOrigin: "50% 50% -30px",           cycle: {             color: ["red", "purple", "teal"],             rotationY(i) {               return i * 50             }           }         },         ...

Then, in the component itself, we’ll pass one into the other:

<script> import { logolettering } from "./../hooks/logolettering.js"; import { windowwidth } from "./../hooks/windowwidth.js";  export default {   hooks() {     logolettering(windowwidth());   } }; </script>

Now we can compose logic with Hooks throughout our application! Again, this is a contrived example for the purposes of demonstration, but you can see how useful this might be for large scale applications to keep things in smaller, reusable functions.

Future plans

Vue Hooks are already available to use today with Vue 2.x, but are still experimental. We’re planning on integrating Hooks into Vue 3, but will likely deviate from React’s API in our own implementation. We find React Hooks to be very inspiring and are thinking about how to introduce its benefits to Vue developers. We want to do it in a way that complements Vue’s idiomatic usage, so there’s still a lot of experimentation to do.

You can get started by checking out the repo here. Hooks will likely become a replacement for mixins, so although the feature still in its early stages, it’s probably a concept that would be beneficial to explore in the meantime.

(Sincere thanks to Evan You and Dan Abramov for proofing this article.)

The post What Hooks Mean for Vue appeared first on CSS-Tricks.

CSS-Tricks

,
[Top]

Designing for the web ought to mean making HTML and CSS

David Heinemeier Hansson has written an interesting post about the current state of web design and how designers ought to be able to still work on the code side of things:

We build using server-side rendering, Turbolinks, and Stimulus. All tools that are approachable and realistic for designers to adopt, since the major focus is just on HTML and CSS, with a few sprinkles of JavaScript for interactivity.

And it’s not like it’s some well kept secret! In fact, every single framework we’ve created at Basecamp that allows designers to work this way has been open sourced. The calamity of complexity that the current industry direction on JavaScript is unleashing upon designers is of human choice and design. It’s possible to make different choices and arrive at different designs.

I like this sentiment a whole lot — not every company needs to build their websites the same way. However, I don’t think that the approach that Basecamp has taken would scale to the size of a much larger organization. David continues:

Also not interested in retreating into the idea that you need a whole team of narrow specialists to make anything work. That “full-stack” is somehow a point of derision rather than self-sufficiency. That designers are so overburdened with conceptual demands on their creativity that they shouldn’t be bordered or encouraged to learn how to express those in the native materials of the web. Nope. No thanks!

Designing for the modern web in a way that pleases users with great, fast designs needn’t be this maze of impenetrable complexity. We’re making it that! It’s possible not to.

Again, I totally agree with David’s sentiment as I don’t think there’s anyone in the field who really wants to make the tools we use to build websites overly complicated; but in this instance, I tend to agree with what Nicolas recently had to say on this matter:

The interesting thing to note here is that the act of front-end development changes based on the size and scale of the organization. As with all arguments in front-end development, there is no “right” way! Our work has to adapt to the problems that we’re trying to solve. Is a large, complex React front-end useful for Basecamp? Maybe not. But for some organizations, like mine at Gusto, we have to specialize in certain areas because the product that we’re working on is so complicated.

I guess what I also might be rambling about is that I don’t think it’s engineers that are making front-end development complicated — perhaps it’s the expectations of our users.

Direct Link to ArticlePermalink

The post Designing for the web ought to mean making HTML and CSS appeared first on CSS-Tricks.

CSS-Tricks

, , , ,
[Top]