Disclaimer: I'm a backend developer. I used to do full-stack (the real deal, ops/backend/frontend/design) but nowadays all these specialisations are too fragmented to keep up with everything. I do use React when needed and I like Svelte. I used to do Angular, but I quit about the time when version 6 came to be.
I also like GOTO talks, they're awesome. Probably it's the best conference series in development. There's always something good there, something to learn. Including this little gem of a talk by Stuart Langridge.
It's a worthwhile talk and by the end it did open my eyes to many advancements in the field of pure HTML/CSS. If you're a frontend dev, watch it thoroughly all through to the end (if you don't know Langridge, he's with the Web Standards Project and W3C).
The gist of the talk (spoiler alert) is that we should be much more critical of the tools we choose and how we choose them, with a focus on the fact that too many people default to all sorts of fancy frontend frameworks for every little bit of frontend work when in fact a great of that work could be covered by advancements in HTML and CSS (I did not know of the <portal> element before this talk).
He begins the talk by outlining various shortcomings of SPAs and defaulting to client-side rendering, moves on to offering alternatives and examples and ends up praising React a bit for the fact that it's modular and meant to be used for components of a page rather than defaulting to SPA all the time.
It's a nice talk, though I took some issues with the first part (the reasons why JS/frameworks could be bad) and it goes a bit like this:
First meaningful paint: a HTML of 23k worth of Tweets (~9Mb) beats a React app the displays just one of those tweets by a whopping 200ms. Nothing to say here, tested it myself, that's how it goes.
Client side computing power is no match for a cloud machines => you should always do as much work on the server as possible. I wish I could break it to him that I have an app served by 3 Azure VMs, each being a 2 vCPU / 4Mb RAM kind of thing, serving hundreds of thousands of users overall. Each of those machines is much less powerful that your average PC sold nowadays and there are phones that could give them a run for their money. Since each request is served by one such VM, I have no qualms offloading to the client.
Your customer might not get to run your JS this was interesting, because it wasn't about those users with JS off, but rather showed some interesting cases where ISPs ended up blocking some CDNs serving jQuery or React (UK's Skye and US' Comcast). Also said Comcast at one point was injecting adverts with loaded JS (I have seen this firsthand while living in Berlin - ISP injecting JS/HTML in some pages and breaking the experience). It's something to think about, at least in terms of having a fallback.
Frameworks promote reusing of someone else's components that's something I've also hit on the backend side. The happy moment of a product is when it's matured and grown as a useful market thing. As time goes by people are less inclined to change a working thing, until years later when the need suddenly comes. I can't tell how many projects I worked on revolved around helping a web app move on from a dated component or framework which was dead (or newer versions of the underlying platform or language brought breaking changes). Again => have a plan B.
Frameworks are after the fact rationalisations, we didn't decide we want all of that, but they came along the way so we rationalised them that was a bit I didn't agree with. Few frameworks had as a goal to be what they are today. 100% of them (hell, even some languages as whole) came out of a few people trying to solve a recurring problem, and created a systematic solution which grew to incorporate more things. Some of the things that came after the moment on which the initial need was satisfied may have been after the fact rationalisations but another fact is that all frameworks came off real problems and are backed by pragmatic reasoning. Some of those problems may have totally different alternative solutions today but another fact is that people are productive with tools they know.
All in all, the reasoning introduction felt quite forced. I'm always of the opinion to not put the tool before the problem. Understand the problem, define the solution but don't define it so that it needs a framework, but rather design it with an open mind and if a framework does fit the constraints, then ok.
I've had the same issue on the backend side of things (mainly with PHP). We have an API to build: great, let's use Symfony! Cue: spend time understanding all the yaml definitions, dig through annotations to create a couple of HTTP endpoints. Today: take a router, add a DI container, add a ORM if needed and be on your merry way and take your performance bonus!
Top comments (0)