#20: Read Now - Fantastic Frontend Engineering (3 minutes)
Interesting read, NK!
For small apps this may seem overkill. E.g. some back-office that a few internal people use
But for larger apps at scale, growing more means degrading user experience. I found that Amazon really takes it into account: I have had to create investigate increases of sub millisecond latency in the retail Search page to ask leadership support on launching a feature. I imagine Discord also found the same, people would leave if they can't access information fast
Some interesting read about it: https://www.gigaspaces.com/blog/amazon-found-every-100ms-of-latency-cost-them-1-in-sales
What every happened to modularization? If you spend half a day thinking about how a software project is going to grow, it should be pretty clear, pretty quickly that the only way to have a sliver of a chance to stay ahead of the impending success disaster is to PLAN for it. Spend a bit of of effort understanding where the ticking bombs lie. Finally, what ever happened to the understanding that Programming is not “coding” and it is not done with an IDE, or anything else with a keyboard. Rome was not built by “running fast to get away from things that are breaking.” But don’t mind me - I’m a Geezer, and I Geeze professionally.
Great article as usual!
It’s the first time I heard about code split, interesting to know how often is it implemented. As Fran mentioned, for small websites it’s probably less common (although we definitely have a bloat problem, never removing any feature…)