Frontend Icon

Frontend

Front End is the programming and layout that people see and interact with.
45 Stories
All Topics

Tom MacWright macwright.com

If not SPAs, what?

Tom MacWright shared some concerns for SPAs place in the modern web and followed it up with a post sharing suggestions to use instead.

The SPA pattern (Single-Page Apps), I tried to define, was about the React model, which also covers, to a large extent, the model of Vue, Angular, and other frontend frameworks.

Like any critique, it begs for a prescription and I didn’t give one, other than gesturing toward server-side frameworks like Rails and Django. But I think there are some trends starting to form. I had queued up some time to really dive into the frameworks, but things like walking in parks have taken priority, so here’s just a grand tour.

Chris Coyier CSS-Tricks

The widening responsibility for front-end developers

Chris Coyier:

This is an extended version of my essay “When front-end means full-stack” which was published in the wonderful Increment magazine put out by Stripe. It’s also something of an evolution of a couple other of my essays, “The Great Divide” and “Ooops, I guess we’re full-stack developers now.

This is a lengthy, sprawling piece on the evolution of frontend development by someone who really gets the web. It also has its own art-direction and design so you’ll want to read it onsite vs in an Instapaper-alike.

JavaScript hyperapp.dev

Hyperapp – the tiny framework for building web interfaces

Hyperapp claims to be twice as fast as React, weighs in at 1.8KB, and renders interactively in ~10ms.

Hyperapp is a modern VDOM engine, state management solution, and application design pattern all-in-one. once you learn to use it, there’ll be no end to what you can do.

Filed under: zero-minutes-since-last-frontend-framework

Josh Comeau joshwcomeau.com

A static future

Why is static the future? How do you define “static”? Read this deep dive from Josh Comeau to find out…

The term “static” can be a little overloaded, and occasionally a little misleading. Here’s how I’d define it:

“A static website is a website where the initial HTML is prepared ahead of time, not dynamically generated by a server on request.”

When you make a request to this website, for example, Netlify serves pre-generated HTML to you. I don’t have a Node server dynamically rendering HTML documents on-the-fly.

Crystal mint-lang.com

Mint – a programming language for writing single page apps

Mint has all the tools you need to write error free, easily readable and maintainable applications in record time.

Built-in styling, data management, language-level routing, and JavaScript interop make this a very interesting project, indeed. It’s still in heavy development, so the only real-world example you’re going to see is their implementation of realworld.io.

Marcy Sutton marcysutton.com

Links or buttons?

To button or not to button…the button element is “actually really cool”…

Something that comes up again and again in front-end accessibility is the issue of links versus buttons. You know, the HTML elements that open links in new windows or submit forms? In JavaScript web applications, it seems we’re still confused about which element to choose for user interaction. To try and clarify the haziness, I’ll define use cases for links and buttons in client-rendered applications and help you make better UI decisions, from design to development.

CSS Wizardry Icon CSS Wizardry

Time to first byte — What is it? Why does it matter?

Harry Roberts writing on CSS Wizardry:

One metric I feel that front-end developers overlook all too quickly is Time to First Byte (TTFB). This is understandable—forgivable, almost—when you consider that TTFB begins to move into back-end territory, but if I was to sum up the problem as succinctly as possible, I’d say: While a good TTFB doesn’t necessarily mean you will have a fast website, a bad TTFB almost certainly guarantees a slow one.

Even though, as a front-end developer, you might not be in the position to make improvements to TTFB yourself, it’s important to know that any problems with a high TTFB will leave you on the back foot, and any efforts you make to optimises images, clear the critical path, and asynchronously load your webfonts will all be made in the spirit of playing catchup.

Medium Icon Medium

I’ve spent 5 years writing a JavaScript framework on my own

Typescene is a robust front end library written in TypeScript: strongly typed, no dependencies, no nonsense. It’s really great for desktop-like (or mobile) applications, not so great for blogs and other content. It isn’t backed by some major corporation, not even a startup, but it’s been built by me: one developer on a mission to build a no-nonsense dependency-less framework

The author’s journey is noteworthy, but if you’re mostly wanting to know if this particular framework speaks to you, jump directly to its list of goals.

Pete Lambert petelambert.com

HTML is the web

My big concern is at the bottom of that technology pyramid. 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.

Solid rant with a nice list of resources at the end. 👌

Rich Harris DEV.to

Why Rich Harris doesn't use web components

Rich kicked the proverbial hornet’s nest yesterday. After you read his 10-point post, stick around for the comments, many of which rebut one or more of those points. I’ll weigh in on #3: Platform Fatigue

Every time we add a new feature to the platform, we increase that complexity — creating new surface area for bugs, and making it less and less likely that a new competitor to Chromium could ever emerge.

Co-sign! 💯

JavaScript martinfowler.com

Micro frontends

What’s the front-end equivalent of a micro-services architecture? A micro-frontends architecture of course. This approach makes a ton of sense, though in my opinion you will definitely want to have an internal components library and some cross-frontend coordination so your UI doesn’t degrade into a series of disconnected, disjointed experiences.

It’s hard to argue against the benefits stated by author Cam Jackson:

Micro frontends are all about slicing up big and scary things into smaller, more manageable pieces, and then being explicit about the dependencies between them. Our technology choices, our codebases, our teams, and our release processes should all be able to operate and evolve independently of each other, without excessive coordination.

freeCodeCamp Icon freeCodeCamp

Fundamental design principles for non-designers

Front-end developers are often in a position of trying to interpolate between a (static) design and the (dynamic) needs of a product. When something comes up that isn’t quite covered by the design, what should you do? In an ideal world we could have a conversation with the designer, but the world is rarely ideal, so it’s useful to have at least a sense of good practices to apply.

This article is great because it keeps it simple - just four straightforward principles. As author Anna 4erepawko Mészáros says:

Will this help you create shiny beautiful designs? No. Will this help you create great, clear and comprehensible designs that everyone can easily understand and interact with? Absolutely.

Kay Singh singhkays.com

It's time to replace GIFs with AV1 video

It is 2019 and we need to make a decision about GIFs. GIFs take up a massive amount of space (often multiple megabytes!) and if you’re a web developer, then that’s completely against your ethos!

If your goal is to improve your website your loading performance, then a GIF needs to be yanked! But then how do you have moving pictures? The answer is a video. And in most cases, you’ll get better quality as well as almost 50-90% size savings!

AV1 videos give us smaller file sizes and better quality?! There must be a catch…maybe…read on to find out.

Google Icon Google

Flutter for web

Flutter for web is a code-compatible implementation of Flutter that is rendered using standards-based web technologies: HTML, CSS and JavaScript. With Flutter for web, you can compile existing Flutter code written in Dart into a client experience that can be embedded in the browser and deployed to any web server. You can use all the features of Flutter, and you don’t need a browser plug-in.

This means Flutter is now on mobile, web, desktop, and embedded systems. What surprises me is how dedicated to Dart Google seems to be, despite community malaise and the success of TypeScript.

Rich Harris svelte.dev

Svelte 3: rethinking reactivity

After several months of being just days away, we are over the moon to announce the stable release of Svelte 3. This is a huge release representing hundreds of hours of work by many people in the Svelte community, including invaluable feedback from beta testers who have helped shape the design every step of the way.

Lots of folks (myself included) have been eagerly awaiting this release after Rich teed it up on The Changelog #332. We’d love to hear your first impressions!

JavaScript whatisjasongoldstein.com

Help! None of my projects want to be SPAs

There’s a lot of wisdom in this post alongside some opinions that I find myself nodding along with:

My strategy for dealing with the absurd pace of change in web development has been as follows: ignore 99% of it and see if it goes away.

While we cover (and talk about) new technologies on a daily basis here at Changelog, that doesn’t mean we adopt everything that hits our radar.

Given the hype cycle, it works pretty well. Mongo isn’t exciting anymore, Angular 1 is dead, CoffeeScript is obsolete, I haven’t heard a word about Meteor since it launched…

These are all specific technologies. But what about the Single Page App pattern in general?

Back in the early days of SPAs, some people argued that it would be faster to only pass the data you need as JSON than to render whole pages. Nearly a decade later, this is almost never true.

He goes on to explain how he’s building a side project SPA-style and all the repercussions of that decision. Really insightful stuff here, please do click through and read for yourself.

Rachel Andrew rachelandrew.co.uk

HTML, CSS and our vanishing industry entry points

As chronicled in the latest JS Party we continue to track the conversations and insights being shared about the great divide on the front-end. Even DHH shared his thoughts.

This post from HTML & CSS expert and advocate Rachel Andrew shares her perspective drawn from the 20 years she’s been working on the front and backend of the web.

When we talk about HTML and CSS these discussions impact the entry point into this profession. Whether front or backend, many of us without a computer science background are here because of the ease of starting to write HTML and CSS. The magic of seeing our code do stuff on a real live webpage! We have already lost many of the entry points that we had. We don’t have the forums of parents teaching each other HTML and CSS, in order to make a family album. Those people now use Facebook, or perhaps run a blog on wordpress.com…

David Heinemeier Hansson Signal v. Noise

Designing for the web ought to mean making HTML and CSS

DHH shared his thoughts on The Great Divide. After all, the web IS just…HTML, CSS, and JavaScript…

…as The Great Divide points out, regression is lurking, because the industry is making it too hard to work directly with the web. The towering demands inherent in certain ways of working with JavaScript are rightfully scaring some designers off from implementing their ideas at all. That’s a travesty.

At Basecamp, web designers all do HTML, CSS, and frequently the first-pass implementations of the necessary JavaScript and Rails code as well! It means they get to iterate on their design ideas with full independence. In the real app!

0:00 / 0:00