One of the things I was most surprised about recently is just how buggy and unpleasant to use the Cloudflare dashboard is. We only moved to them recently and I was really shocked. I had one situation where the dashboard literally showed me the wrong domain but rules for another, which I think was a session or caching bug. I really thought it would be better for a company that size!
You'd be surprised... I did a LOT of cleanup work for a private college that had a lot of "clever" developers that didn't understand static variables in C#, or how the ASP.Net lifecycle worked. Race conditions and all kinds of weird errors when the system got busy. Not to mention a lot of "fun" performance issues.
Just because someone has a CS degree doesn't mean they actually know what they're doing.
That's different, those are clever people who are bad developers. But too proud to admit it even to themselves. You come across them a lot in small/mid sized companies and non-tech IT teams.
Cloudflare's no longer the darling of HN, but they unquestionably have clever people who are excellent developers. Just maybe not excellent at web dev and cache invalidation by the sound of it.
My main point is, you can be working with people that are pretty smart and well educated, with a pretty good baseline understanding of theory but that doesn't always mean they have the actual experience and/or thorough enough understanding of a given set of tooling and environment to implement correctly.
I say this as someone who is autodidactic (self-taught) with regards to software engineering. I never stop learning, reading, experimenting and just gaining as much understanding over everything I touch as I can. My mind doesn't always work like most people. And my statements are not meant to be insulting, just my point of view from the outside...
In that, I feel that a lot of FAANG (whatever the correct/current conflation is) tend to rely on a lot of focus that tends to favor those with a formal education, and those closer to that education (less experienced outside school). In practice, my experience is that this will lead to an excess in "Enterprise Pattern" usage as well as unnecessary complexity which leads to an increased risk of error.
I followed this project from when it was announced but it was unfortunately abandoned a few years ago. It's probably not worth wasting any time on now.
I haven't seen a .tk domain in probably 20 years. It was super popular with young gamers during the early 00s due to the free domain. What a blast from the past!
Yeah! I don't know if it's still there but I kitted out my first company's office with chairs from there! It was a cool place.
There's also a junk shop, for want it a better phrase, just off the top of Brick Lane that is similar, it has office stuff but also way more general stuff too.
The mural on the wall is of the guy who used to own the shop. He'd sit outside all day in his car. I can't remember his name now but he was famous locally.
https://metroretro.io - started as a hackathon project in 2016. I found people using the barely functioning prototype a year later for actual work meetings and decided to started improving it. I went perm on the project 3 years ago and this year passed 10k MRR (100% self funded). Still doing all the dev and ops solo, but I have two co-founders doing all the sales, support and finance stuff. We are going for a specialized whiteboard for software/agile angle rather than generalist whiteboard app currently.
I think I'll be working on this product for a long time as I believe there is a new generation of collaboration software coming to replace the current leaders and I would like to be one of them. I think about this product night and day, and wouldn't want to be building anything else!
Usually it is to detect the user is registered to (or their domain is mapped to) an account with SSO or Social Auth and prompt them for that login mechanism. If the user is being required to go via the SSO provider, it makes sense to ask for the email first before they input their password so that they can be redirected it neccesary.
You know you are getting old when you watch the arrival of the fourth JavaScript build tool of your career. I still remember when everyone was waving goodbye to Gulp in favour of Webpack. Webpack was going to save us all from the hell of massive convoluted gulp.js files. Fast forward five years and it's the same mess it was supposed to avoid. Slow, bloated and confusing.
I just switched to esbuild on our main project and the build time went from 7 minutes on CI to 1 second. Kinda stupid really. Anyway, here's to the future, let's hope it works out this time!
I always found it amusing going from Grunt (unwieldly huge object based config) to Gulp (config is code, pipe transformations together in a simple unix'y way) to being told webpack is the future (huge unwieldly config objects again). Definitely felt like a step backwards although I appreciate the power webpacks gives to people building boilerplates like Create-react-app. I rarely use Gulp anymore but I still appreciate it's UX/DX.
As someone who liked Gulp (SOOO much more than Grunt/Browserify) the transition from v3 to v4 felt really, really bad. Lots of unknowns around release timing, poor community support for the new version, "beta" tags sticking around forever long after it should have been released, maintainer turnover, etc...
It was enough at the time to get me to jump to Webpack, since it seemed like gulp was dying, and if I had to pick a configuration based tool it wasn't going to be Grunt.
Now I'm actually swinging back towards a combination of Gulp and ESBuild on my personal projects. I honestly debated trying a mix of Make and ESBuild (Since Gulp still feels pretty dead, and hasn't had a real release in 2+ years), but Make has enough subtle gotchas that I stuck with something familiar.
You're right about the community being mostly dead.
There are a lot of bugs and performance issues in the underlying libraries, and Gulp's developers have not been able to get the upstream updates integrated.
I just redid our Grunt stuff in Gulp. It was painful - difficult to find up-to-date information, and the result was not that great. I expected a much greater SCSS compilation performance increase compared to FS-based tooling. Maybe I'm doing something wrong.
I'd switch to something like ESBuild and leave SCSS for dead, but it's not an option for me yet :(
I remember when we just served the javascript we wrote. Of course we are back to that. You can just write es6 in as many files as you would like and serve it over http/2 without any webpack/esbuild/babble/etc.
Indeed, the best build chain is no build chain at all. I've been ridiculed at work for not using node, npm, web pack etc -- but I'm not spending 20% of my time on tooling issues.
I'm interested to know who you know spends 20% of their time on tooling issues... I use node, npm and webpack pretty regularly (albeit parcel has mostly replaced webpack for me) and other than setting up some npm scripts and a tsconfig to output the right js for my node version at the start of a project, I barely interact with them.
I think it's more like 80% of time at the start of any project, and then trickles down to no time, then up to 80% again when there's a new feature/config/incompatibility with tooling.
In larger projects and in orgs, you often have legacy choices that you have to deal with, that you can't remove or spend time replacing.
I would say that's within a believable range of improvement (although on the high end).
We're playing with ESBuild at work, TS/React build that takes 45+ seconds to run with webpack cold, 8 second for a rebuild. With ESBuild/Gulp, the full gulp watch task will refresh in about 1.2 seconds, of which ESBuild ran for about .4 seconds.
So the builds are ~100 times faster with ESBuild, and we're just running it cold every time because it's so fast.
---
It's also really exciting for run-time based compilation. I've been playing around with a server-side React rendering project, and I literally just run esbuild in the controller action in development (some prebuilding for releases) and it's wonderful. Live updates in roughly .6 seconds on average, even for relatively heavy components.
plus, if you're careful with your react code, you can build a react codebase that will actually run if client-side JS is disabled (you can render it all serverside)
Probably not an exaggeration. My build times aren't that long, but I've seen similar speedups in switching the esbuild (our smaller codebases currently build in less than 0.1 of a second with esbuild)
