I don’t agree with the conclusion of this post:
Let’s define “front-end” to mean the parts of the app relating to user interface, rather than those that happen to be running in the browser’s JavaScript VM.
But I think the author definitely taps into a real issue:
The real problem is the perception that any code running in the browser is front-end code.
Let’s face it: programming something in Angular and Ember has much more in common with programming something in Rails or Django than it has with writing HTML, CSS, and JavaScript.
This is something we’re running into at Clearleft: we’ve never done backend programming (by choice), but it gets confusing if a client wants us to create something in Angular or Ember, “because that’s front end code, right?”
So instead of asking yourself, “How can I write code that does what I want?” Consider asking yourself, “Can I write code that ties together things the browser already does to accomplish what I want (or close enough to it)?”
Hannah runs through the details of making a grid-aware website:
The design adjusts between “low”, “moderate”, and “high” based on the quantity of fossil fuels on your local energy grid.
I like this idea, but I really think it needs to be on by default, rather than being opt-in.
And I’m really intrigued by the idea of a grid-aware browser!
This is a really thoughtful look at the evolution of CSS and the ever-present need to balance power with learnability.
Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.
There’s also this:
It’s really fast
One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.
When haters deny HTML’s status as a programming language, they’re showing they don’t understand what a language really is. Language is not instructing an interlocutor what to do in a way that leaves no room for other interpretations; it is better and richer than that. Like human language, HTML is conversational. It is remarkably adept at adapting to context. It can take a different shape on any machine, from a desktop browser or an e-reader screen to a mobile app or a screen reader for the blind (so long as that device is built to present hypertext).
Hell, yeah!
Ultimately, even as HTML has become the province of professionals, it cannot be gatekept. This is what makes so many programmers so anxious about the web, and sometimes pathetically desperate to maintain the all-too-real walls they’ve erected between software engineers and web developers.
Hell, yeeeeaaaaahhh!!!
What other programmers might say dismissively is something HTML lovers embrace: Anyone can do it. Whether we’re using complex frameworks or very simple tools, HTML’s promise is that we can build, make, code, and do anything we want.
A performance boost in Chrome.
Caches are for copies.
Back-end development isn’t the same as front-end development.
Maps—they don’t love you like I love you.
Inside me there are two wolves. They’re both JavaScript.