I've seen visualisations similar to this before, but this one is by far the most beautiful and I could watch it all day.
I echo the sentiments on the TfL API, I've built the same Tube Tracker app over and over for more than 10 years[1] as my go-to for learning new tools[2] or testing changes to frameworks[3] and I'm not sure it's ever improved. A chap called Chris Applegate wrote extensively about his battles more than a decade ago[4], did they ever add the stations between Latimer Road and Goldhawk Road on the Hammersmith & City/Circle line?
Agreed! About 5 or 6 years ago I wrote a library to demonstrate to my teams that JSX a) was not magic b) not limited to React. After that was done I became a little obsessed with making the library the fastest JSX renderer - which I think is still true: https://github.com/i-like-robots/hyperons
Congrats, this looks really nice! I recently finished a side project using Fastify and the Fastify Swagger plugin (which extends the built-in request and response validation and can dynamically generate an Open API definition) which was a good experience overall but the addition of request mocking and the solid documentation site shown here could tempt me to revisit it.
I mostly agree - that was the intention of the caveat - although I don't think there would be too much harm done if somebody started with ES5 then layered ES20xx features or new browser APIs on top as needed.
Perhaps look for web development books published around 2010-2012, before the large JS frameworks gained a major foothold. These will be missing some of the very valuable and useful developments in CSS and JavaScript (e.g. grid layout and promises) but for the other topics much of their content will still be relevant.
> Webpack's loaders can't really check your types because, without doing a lot of extra magic, they operate on one file at a time.
This is the point folks really must understand when setting up a new tooling pipeline to deal with TypeScript. Certainly all of the module bundlers I'm aware of operate in this way.
To explain further for anyone curious; for TSC to work effectively it must construct and understand the entire "compilation". To do this it starts by performing a glob match (according to your include/exlude rules) to find every TypeScript file within the project. Resolving and type checking the entire compilation every time the bundler calls for a transform on a file is very slow due to lots of repeated and unnecesssary work so most TS bundler plugins have to work around this. Unfortunately, they're still relatively slow so type checking and bundling code separately is often the best way to go.
Like you I tend to agree that the effort delivering front end projects often seems to outweigh the value added over recent years. I can think of half a dozen projects I've seen over the last few years where the effort teams put into figuring out stacks of new tools was an order of magnitude greater than the value added (and most of the projects failed to deliver or became haunted forests soon afterwards which is even worse!) It's not sustainable, businesses are wasting far too much money and too many talented developers are left feeling inadequate.
The most important thing in any organisation is to ensure teams are setup to succeed - that means they're using tools which enable them to work efficiently, ship easily and reliably, and their work can be maintained in future.
With that in mind, my advice would be:
1. Ensure there is a process where new tools are scrutinised by peers. I always push developers and teams to explain their tech choices in terms of the value added and often as we dig into this together the justifications melt away. Asking for a timeboxed proof of concept can also be effective - battling toolchain woes and trying to manipulate tools into solving the problems a team actually has often helps lead to better decision making (think https://boringtechnology.club/)
2. Try to work in organisations where developers can be close to their users and are empowered to suggest new features and self serve analytics data. Teams able to build empathy with their users and are motivated to solve problems for those users are more likely to favour choices which provide value quickly - this is a big nudge towards making simpler choices.
3. Give developers space for learning and experimenting. Whilst tempting, picking up a suite of new tools to deliver each new project is a really crap way to encourage self development because those new tools will more often be a big distraction than a force multiplier. Many developers are highly motivated by trying out new tools and frameworks, and some of those might lead to something great in future, so give developers the time and space to try them and make sure their learnings are shared with the team to help level them up too.
Prior to my current company I think I'd only met two candidates face-to-face who had sent misleading CVs (one of whom memorably tried to tell me MooTools was a new Linux based operating system.)
But so far this year I've cut short half a dozen interviews once it became clear the candidate was hopeless, despite having good CVs. In some cases they seemed to struggle to even to use their own computer.
And in the last 12 months we've also cut ties with somebody who joined during lockdown after it became clear that they'd falsified details of their background and experience.
I work four days in my current role and will continue doing so in my next one. I don't have much choice in the matter so I always raise it at the earliest opportunity and have even added it to my CV to make sure I don't waste anybody's time.
I've found the majority of the companies I've spoken to over the last few years (in the UK) have been open to me working 4 days a week but I've also had the frustrating experiencing of being told this isn't an option after interviewing successfully.
At the moment people with my experience are in huge demand so having this leverage must be a big help and I'm happy to take advantage of it while it lasts.
(The article is also available on my personal site - about 18kb all in - for anybody who would like to read it not on a slow and increasingly walled garden website.)
I'm super pleased to see the FT towards the top of the charts. It's a couple of years since I worked on the project[1] to make it faster and it's really great the team have been able to keep it that way.
We bet on measuring site speed with user centered metrics early on which was going against the grain at the time - removing above the fold CSS, are you crazy!? It took a lot of demos to convince people that what we were doing was faster, and that they really needed to trust their own eyes even when the tools disagreed!
Same, although I'd add it wasn't easy (in the UK.) I found most of the companies I spoke to the last time I was on the job market were open to me working 4 days a week. I made sure to raise my part time status at the earliest opportunity and added it to my CV to make sure I was only interviewing for positions where this could be accommodated.
However, when it eventually came to negotiating after successfully interviewing it was still difficult and I had at least a few companies - to my huge frustration - try to push me into a full time role or even tell me they weren't setup to handle my request yet but would be in future! With the role I eventually accepted I still had to work full-time during my probation period before I could reduce my hours due to limitations with their processes (apparently.)
To help answer the originl question, at my former employer - The Financial Times - a 4 day week was fairly common amongst folks with young children.
Agreed, and there are some innacuracies that could have been corrected with a little research. For example, the description under the Girl logo states "The company doesn’t only make skateboarding products for females, but it has launched skateboards for male skaters." but the company name never had anything to do with products for girls at all.
As an aside, I'd always assumed that the Birdhouse logo is what it is because it's based on the Bauhaus typeface and the names are similar... I'm surprised that's not picked up on here.
My experience is similar. I also "burned out" a couple of USB-C hubs (including a very similar Anker branded unit) so eventually upgraded to a decent monitor with integrated USB-C hub. Being able to switch between all the laptops in our household and my PC with only one cable has been really great. Although, we often find our Apple laptops have problems recognising the connected devices so we have to connect and re-connect a few times to ensure everything is working as it should. No such problems with the PC!
Absolutely, we can always try to assume that our predeccesors or past selves had the best of intentions but nothing beats writing down the context and problems at that moment in time for future reference.
I suppose we can only accurately define a problem when there are no big unknowns, so I wouldn't prescribe readme based development in every scenario - a quick and dirty exploration of the space which can then be scrapped is more important sometimes.
I echo the sentiments on the TfL API, I've built the same Tube Tracker app over and over for more than 10 years[1] as my go-to for learning new tools[2] or testing changes to frameworks[3] and I'm not sure it's ever improved. A chap called Chris Applegate wrote extensively about his battles more than a decade ago[4], did they ever add the stations between Latimer Road and Goldhawk Road on the Hammersmith & City/Circle line?
[1]: https://www.matthinchliffe.dev/2014/03/05/building-robust-we...
[2]: https://svelte-tube-tracker.vercel.app/
[3]: https://github.com/i-like-robots/react-through-time/pulls
[4]: https://web.archive.org/web/20150620042340/http://www.qwghlm...