Tags: frameworks

38

sparkline

Wednesday, May 31st, 2017

HN PWA - Hacker News readers as Progressive Web Apps

Of all the sites to pick to demo progressive web apps, we get the cesspit that is Hacker News …I guess it is possible to polish a turd.

Anyway, here are some examples of using frameworks to create alternative Hacker News readers. So the challenge here is to display some text to read..

Four of them render absolutely no content without JavaScript.

In the Hall of Shame we have React, Preact, Angular, and Polymer.

In the Hall of Fame, we have the ones doing it right: React, Vue, and Viper.

That’s right: React appears in both. See, it’s not about the tools; it’s about how you use ‘em.

Monday, May 22nd, 2017

Are we making the web too complicated? | Seldo.Com Blog

Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:

Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.

I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:

Are there some people using a huge pile of JavaScript and a monstrous build chain to throw together a single-pager web site with one box that collects an email address? For sure. And that’s silly and unnecessary. But so what? The misuse of technology does not invalidate it.

I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.

But we can all agree that the web is a wonderful thing:

Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.

Sunday, March 19th, 2017

Frameworks without the framework: why didn’t we think of this sooner? • Svelte

Interesting ideas around front-end frameworks:

The common view is that frameworks make it easier to manage the complexity of your code: the framework abstracts away all the fussy implementation details with techniques like virtual DOM diffing. But that’s not really true. At best, frameworks move the complexity around, away from code that you had to write and into code you didn’t.

Instead, the reason that ideas like React are so wildly and deservedly successful is that they make it easier to manage the complexity of your concepts. Frameworks are primarily a tool for structuring your thoughts, not your code.

The proposed alternative here is to transpile from the idiom of the framework into vanilla JavaScript as part of the build process, which should result in better performance and interoperability.

Thursday, March 2nd, 2017

The benefits of learning how to code layouts with CSS | Jen Simmons

A really inspiring post by Jen outlining all the benefits of the new CSS layout features …and the problems with thinking framework-first.

I know a lot of people will think the “best” way to use CSS Grid will be to download the new version of Bootstrap (version 5! now with Grid!), or to use any one of a number of CSS Grid layout frameworks that people are inevitably going to make later this year (despite Rachel Andrew and I begging everyone not to). But I don’t. The more I use CSS Grid, the more convinced I am that there is no benefit to be had by adding a layer of abstraction over it. CSS Grid is the layout framework. Baked right into the browser.

Sunday, January 15th, 2017

Browser Support for evergreen websites

Oh, how I wished everyone approached building for the web the way that Rachel does. Smart, sensible, pragmatic, and exciting!

Monday, November 21st, 2016

You Are Not Paid to Write Code – Brave New Geek

Gall’s Fundamental Theorem of Systems is that new systems mean new problems. I think the same can safely be said of code—more code, more problems. Do it without a new system if you can

A cautionary tale of the risks involved with embracing new frameworks.

But when you introduce a new system, you introduce new variables, new failure points, and new problems.

almost anything is easier to get into than out of.

Thursday, November 17th, 2016

Less JavaScript

Every front-end developer at Clearleft went to FFConf last Friday: me, Mark, Graham, Charlotte, and Danielle. We weren’t about to pass up the opportunity to attend a world-class dev conference right here in our home base of Brighton.

The day was unsurprisingly excellent. All the speakers brought their A-game on a wide range of topics. Of course JavaScript was covered, but there was also plenty of mindfood on CSS, accessibility, progressive enhancement, dev tools, creative coding, and even emoji.

Normally FFConf would be a good opportunity to catch up with some Pauls from the Google devrel team, but because of an unfortunate scheduling clash this year, all the Pauls were at Chrome Dev Summit 2016 on the other side of the Atlantic.

I’ve been catching up on the videos from the event. There’s plenty of tech-related stuff: dev tools, web components, and plenty of talk about progressive web apps. But there was also a very, very heavy focus on performance. I don’t just mean performance at the shallow scale of file size and optimisation, but a genuine questioning of the impact of our developer workflows and tools.

In his talk on service workers (what else?), Jake makes the point that not everything needs to be a single page app, echoing Ada’s talk at FFConf.

He makes the point that if you really want fast rendering, nothing on the client side quite beats a server render.

They’ve written a lot of JavaScript to make this quite slow.

Unfortunately, all too often, I hear people say that a progressive web app must be a single page app. And I am not so sure. You might not need a single page app. A single page app can end up being a lot of work and slower. There’s a lot of cargo-culting around single page apps.

Alex followed up his barnstorming talk from the Polymer Summit with some more uncomfortable truths about how mobile phones work.

Cell networks are basically kryptonite to the protocols and assumptions that the web was built on.

And JavaScript frameworks aren’t helping. Quite the opposite.

But make no mistake: if you’re using one of today’s more popular JavaScript frameworks in the most naive way, you are failing by default. There is no sugarcoating this.

Today’s frameworks are mostly a sign of ignorance, or privilege, or both. The good news is that we can fix the ignorance.

Thursday, November 3rd, 2016

Adoption

Tom wrote a post on Ev’s blog a while back called JavaScript Frameworks: Distribution Channels for Good Ideas (I’ve been hoping he’d publish it on his own site so I’d have a more permanent URL to point to, but so far, no joy). It’s well worth a read.

I don’t really have much of an opinion on his central point that browser makers should work more closely with framework makers. I’m not so sure I agree with the central premise that frameworks are going to be around for the long haul. I think good frameworks—like jQuery—should aim to make themselves redundant.

But anyway, along the way, Tom makes this observation:

Google has an institutional tendency to go it alone.

JavaScript not good enough? Let’s create Dart to replace it. HTML not good enough? Let’s create AMP to replace it. I’m just waiting for them to announce Google Style Sheets.

I don’t really mind these inventions. We’re not forced to adopt them, and generally, we don’t. Tom again:

They poured enormous time and money into Dart, even building an entire IDE, without much to show for it. Contrast Dart’s adoption with the adoption of TypeScript and Flow, which layer improvements on top of JavaScript instead of trying to replace it.

See, that’s a really, really good point. It’s so much easier to get people to adjust their behaviour than to change it completely.

Sass is a really good example of this. You can take any .css file, save it as a .scss file, and now you’re using Sass. Then you can start using features (or not) as needed. Very smart.

Incidentally, I’m very curious to know how many people use the scss syntax (which is the same as CSS) compared to how many people use the sass indented syntax (the one with significant whitespace). In his brilliant Sass for Web Designers book, I don’t think Dan even mentioned the indented syntax.

Or compare the adoption of Sass to the adoption of HAML. Now, admittedly, the disparity there might be because Sass adds new features, whereas HAML is a purely stylistic choice. But I think the more fundamental difference is that Sass—with its scss syntax—only requires you to slightly adjust your behaviour, whereas something like HAML requires you to go all in right from the start.

This is something that has been on my mind a lately while I’ve been preparing my new talk on evaluating technology (the talk went down very well at An Event Apart San Francisco, by the way—that’s a relief). In the talk, I made a reference to one of Grace Hopper’s famous quotes:

Humans are allergic to change.

Now, Grace Hopper subsequently says:

I try to fight that.

I contrast that with the approach that Tim Berners-Lee and Robert Cailliau took with their World Wide Web project. The individual pieces were built on what people were already familiar with. URLs use slashes so they’d be feel similar to UNIX file paths. And the first fledging version of HTML took its vocabulary almost wholesale from a version of SGML already in use at CERN. In fact, you could pretty much take an existing CERN SGML file and open it as an HTML file in a web browser.

Oh, and that browser would ignore any tags it didn’t understand—behaviour that, in my opinion, would prove crucial to the growth and success of HTML. Because of its familiarity, its simplicity, and its forgiving error handling, HTML turned to be more successful than Tim Berners-Lee expected, as he wrote in his book Weaving The Web:

I expected HTML to be the basic waft and weft of the Web but documents of all types: video, computer aided design, sound, animation and executable programs to be the colored threads that would contain much of the content. It would turn out that HTML would become amazingly popular for the content as well.

HTML and SGML; Sass and CSS; TypeScript and JavaScript. The new technology builds on top of the existing technology instead of wiping the slate clean and starting from scratch.

Humans are allergic to change. And that’s okay.

Sunday, October 9th, 2016

You Can’t Get Comfortable Anymore in Web Development | Rey Bango

We should be asking why we need a framework or a tool before just dropping it in. It’s not to say that you shouldn’t learn new things. YOU ABSOLUTELY SHOULD BE CONTINUOUSLY LEARNING! But you should ensure that you have a solid base to work from.

Thursday, October 6th, 2016

Down with the tool fetish - QuirksBlog

PPK responds in his typically strident way to posts by Tim and Bastian. I don’t agree with everything here, but I very much agree with this:

It’s not about what works for you. It’s about what works for your users.

If a very complicated set-up with seven brand-new libraries and frameworks and a bunch of other tools satisfies you completely as a web developer but slows your sites down to a crawl for your users, you’re doing it wrong.

If serving your users’ needs requires you to use other tools than the ones you’d really like to use, you should set your personal preferences aside, even though it may make you feel less good. You have a job to do.

But it’s worth remembering this caveat too.

Friday, September 23rd, 2016

Web development as a hack of hacks - QuirksBlog

PPK reads a Hacker News thread so you don’t have to.

Tuesday, August 23rd, 2016

What is React?

I’m in a similar position to Remy:

I don’t use React. I don’t really gravitate towards larger frameworks, only because my daily work doesn’t require it, and I’m personally more interested in the lower level techniques and parts of the web and JavaScript.

But, like Remy, I’m interested in knowing what are the ideas and techniques embedded within large frameworks that will end up making their way into the web stack:

What I want to know is: what should I be taking away from React into my own continued evolution as a web developer?

There are some good responses in the comments.

Monday, August 8th, 2016

Progressive Enhancement for JavaScript App Developers | De Voorhoede

Build JS apps responsibly - cover your basics, render strategically and enhance into true apps.

Tuesday, July 12th, 2016

EmberCamp London Keynote 2016 // Speaker Deck

I really, really like what Ember is aiming for here:

First, we deliver the raw content, ensuring those on slow connections or without JavaScript get they’re after as soon as possible. Next, we load the minimum set of JavaScript needed to interactivity for that page, keeping transfer time and parsing time low. Once the user has an interactive page, we can start preemptively loading other parts of the application, including frequently-accessed data.

That’s how you get the holy grail of resilience and performance:

Subsequent visits and interactions are therefore nearly instantaneous, because they don’t rely on the network.

I sincerely hope other frameworks are paying attention to this layered approach.

Oh, and I also like this observation:

There’s an age-old argument about the difference between “web pages” and “web apps”. In reality, there’s a continuum between the two.

Thursday, June 2nd, 2016

Progressive Enhancement and Modern JavaScript ― Caolan

I think JavaScript frameworks have been blinkered to the needs of many developers (most websites are not SPAs or run by Node, nor should they be) for too long. We need to find a way to apply the lessons of modern frameworks to the rest of the web - it would be sad if everyone had to run JavaScript on their server and good-old resilient HTML was considered only as a fallback.

Thursday, February 4th, 2016

Together • Ludwig Wendzich

Bootstrap is a product of Twitter. If you want your team to work like Twitter’s team, then by all means use Bootstrap. Pick up their design language. Their tool chain. Their decisions. Don’t be surprised when it feels off every time you use it. It will.

The same goes for Material Design. Foundation. These are all products built by other teams to work for their process. Their structure.

Finding the right tool is not what I am advocating for. Making it is.

Monday, December 28th, 2015

JavaScript: 2015 in Review

Use a framework if you must but never presume it’s viable over the long-term. Newer and better alternatives will appear before you’re half-way through your project. Never forget frameworks are an option — you don’t have to use one.

Monday, November 16th, 2015

Aerotwist - The Cost of Frameworks

Here’s Paul’s write-up of his excellent talk at FF Conf.

Previously I’ve used the term “developer convenience” when describing the benefits of using a framework. Paul uses the term “ergonomics” to describe those benefits. I like that. I worry sometimes that the term “developer convenience” sounds dismissive, which isn’t at all my intention—making our lives as developers less painful is hugely important …but it’s just not as important as improving the lives of the end users (in my opinion …and Paul’s).

As I look at frameworks, I see the ergonomic benefits (and those are important, I agree!), but I can’t help but feel that, for many developers, investing in knowledge of the web platform itself is the best long-term bet. Frameworks come and go, it just seems to be the ebb and flow of the web, and, as I said above, they do contribute ideas and patterns. But if you ever find that the one you use no longer works for you, or has a bug that remains unfixed, being able to understand the platform that underpins it will help enormously.

You should use [insert library/framework], it’s the bestestest! / Paul Lewis - YouTube

This was one of favourite talks at this year’s FF Conf. But I will readily admit there’s a hefty dollop of confirmation bias in my enjoyment.

Thursday, August 20th, 2015

Confidence and Overwhelm

Following on from her great conversation with Jen on The Web Ahead podcast, Rachel outlines a strategy to avoid feeling overwhelmed by the deluge of tools, frameworks, libraries, and techniques inundating front-end developers every day:

Learn your core skills well. Understand HTML and CSS, be able to build a layout without leaning on a framework. Get a solid understanding of how a website actually gets from the server to a browser, an understanding of security and accessibility. These are the basics, the constants. These things change slowly. These things sit underneath all the complexity and the tooling, the CMSs and the noise of thousands of people all trying to make their mark on this industry.

She also makes this important point:

As you are doing this don’t forget to share what you know.