
Principles of scalable front end projects - PetraIgnjatovic
https://www.bornfight.com/blog/10-principles-of-scalable-frontend-projects/
======
Etheryte
As someone who builds reasonably large web apps for a living, this list
doesn't really address anything that's specific for large scale. Separation of
concerns, a common API layer, tests, linters and etc are the baseline of good
development today, not something to consider only for bigger projects.

What I've dealt with over the years, and would've loved to see addressed, is
questions that are actually specific to projects at scale. Having hundreds of
views, how do you classify and manage components? How do you manage shared
components? How to achieve (and keep) architectural consistency across
thousands of components? How do you address death-by-a-thousand-cuts
performance regressions in big web apps? And so on. Sadly, this article
doesn't address any of these.

~~~
_bxg1
It very much comes off as a marketing piece. Heck, the name of the company
splashes the page for several seconds before you even see the article. They
say some things that aren't really wrong but also aren't really interesting,
and it makes them sound like they Really Know What They're Talking About so
that you'll pay them to build something for you.

------
gregdoesit
The article does not mention what the author means by “scaleable” projects.
Scaleable in terms of the codebase being used by tens or hundreds of apps?
Scaleable in terms of tens or hundreds of developers working in the same
codebase? Scaleable in terms of millions of users with different hardware and
devices using the web sites?

My guess is that it is “scaleable in terms of a team of 10-20 developers
working on the same codebase”. The practices are fair in this sense, though
I’m a bit unsure on the specific library recommendations and why they are
better than the alternatives not listed. I was also missing things like
tooling om test coverage - and agreeing with the team on how to go about this
- or code review practices and enforcing (or not enforcing) this.

When it comes to scaling for millions of users, things like monitoring,
alerting, logging, measuring performance in smart ways are things that also
need to be done.

I happen to head up a web team who is building “scaleable” web apps in this
latter regard (we have millions of monthly paying users around the globe whom
we need to scale for) and I’ll write up the additional practices we use to
“scale” with w small team in a later post on my blog [1] for anyone
interested.

[1] [http://blog.pragmaticengineer.com](http://blog.pragmaticengineer.com)

~~~
cutety
I hate to sound elitist or whatever, but I’m just tired of seeing a blog title
something about writing a scalable or “enterprise” web app and the content
almost always being “write modular code, write comprehensive tests, and don’t
write spaghetti code though usually through the veil of domain drive design
jargon (whether or not they don’t use the term DDD or they are literally
quoting Dr Bob blog posts and including vague graphics showing the
“boundaries”). But, any decent developer will literally come to the same
realizations after spending a significant amount on anything that’s not a
toy/pet project. I also get that not everyone has had that realization and
this blog may be insightful/helpful to them, it’s just not the content I was
hoping to come across as it’s something I’m very interesting to hear what
others are doing.

I’m not going to pretend I’m some hardass enterprise engineer, but my only
time spent on frontend work these days are on two different applications that
solely exist because the actual enterprise software sucked so much that these
applications exist. So, I like to think I at least have an idea. As over the
years the features have been added to the apps, and more of the “fun little
quirks” in the data. Which is why I want to hear how real “enterprise” level
frontends are being handled. Believe me, I know the value of keeping my code
modular, and I really know the value of keeping logic out of presentation, but
if working with enterprise software, and software that’s deployed to 30+
different departments to standardize and centralize processes they’ve been
doing themselves for 50+ years (under the guise of “making their jobs easier”
but really they central office where just tired of having to deal with the
random of assortment and varying quality of data, lol) there’s always another
edge case. I cringed when they mentioned that using one of the big frameworks,
and forgoing global styles, because after a couple years of “the frameworks
built in css isn’t totally the way we need it” (or more likely, “fucking
updates broke the UI on a minor release for no reason”) or “oh using the
current components we use to do that don’t take data that way or return it the
way we need either, and it’d take too long to replace, just create a new set
for this feature” it’s not going to be the nice paradise where everything is
siloed off just like in Uncle Bob’s blog. I just this week got sick of UI
framework’s because the built in component I needed wasn’t able to handle the
task in the exact right way, so I had to make adjustments to it, and I’m just
that’s never going to break in the future... not to mention that absolutely
none of them are really doing any more than the bear minimum accessibility
wise, which is one of the reasons to use a framework was to eliminate that
boilerplate. So, I just started tinkering with the new Vue3 composition API to
build a UI framework that literally has no styles attached just dom elements
that know how to setup their aria-attributes, handle keyboard events so a
mouse isn’t the only method, etc (as well as if they weren’t passed given
enough information to make themselves complaint with the aria guidelines). To
style them, I’m just going to make pass in a list of tailwind classes in a
config files at build time, that they can (optionally) but will in no way the
actual core framework itself is dependent on.

I just want to hear how some real enterprise team are managing their frontend
(and more importantly their commentary — I can find code online but without
the context it’s not the same) when they have 100x the amount of edgecase
legacy bullshit I have to deal with and likely 1000x the burden of buroqracey

------
couchand
And apparently principle zero is make scrolling janky for some godforsaken
reason.

------
sidcool
> 10 — Keeping a changelog

I have thought about a changelog and inclined to like it, but I haven't come
across a strategy to have a good changelog structure.

~~~
lukabratos
This might be a good starting point:
[https://keepachangelog.com/en/1.0.0/](https://keepachangelog.com/en/1.0.0/)

~~~
sidcool
Thanks. This helps

------
FlorianRappl
I thought this one might be about microfrontends. It was not...

We are currently working on a solution for this problem (scalable SPA where
multiple teams can develop and deploy independently). Its been used by some of
our clients for quite a bit now. Their dev teams seem to like it so far.

If anyone is interested our GitHub repo is at
[https://github.com/smapiot/piral](https://github.com/smapiot/piral) \-
thanks!

~~~
Etheryte
I've seen many authors bring up micro frontends recently, but I haven't seen
anyone address size overhead. In modern web apps, third party dependencies can
easily be the bulk of your final deliverable volume. With micro frontends and
complete separation, this overhead cost can easily end up being paid multiple
times. How does your project address this?

~~~
pandler
We make heavy use of peer dependencies, so microfrontends rarely end up
actually bundling their own dependencies. Build tools like rollup help with
that.

It’s not a silver bullet and requires A bit of overhead. I’m interested too to
hear how other people manage the problem.

~~~
Etheryte
That is true, however one of the main arguments for micro frontends is the
freedom to use anything: one team can use React, the other Vue, one uses this
table library, the other another. If you don't do that, micro frontends offer
very little in benefit as far as I see. If you do do that, what you're left
with is pretty much regular architecture, just in separate repos and harder to
keep in sync.

~~~
FlorianRappl
Personally, I think this is a myth ([https://blog.bitsrc.io/11-popular-
misconceptions-about-micro...](https://blog.bitsrc.io/11-popular-
misconceptions-about-micro-frontends-d5daecc92efb)).

Most our projects where microfrontends have been actively demanded (and we did
now quite a lot of them) did not come up due to use of multiple frameworks.
Yes, it is possible to use multiple technologies, but quite often there is key
technology in place anyway. E.g., one of our clients had a huge pattern
library written in React and demanded all microfrontends to be written in
React.

So why then microfrontends at all? Well, all parts are still independent from
each other, i.e., independently developed and deployed. Our client has
multiple teams and like that these teams can just work in their own pace using
a few guiding principles that have been given by the solution architecture.

~~~
pandler
FYI your link is broken.

Agreed, the only mention of using different technology has come up in the
current project is in discussions of Typescript vs plain JavaScript. That’s
been the only bring-your-own-technology for the most part, since we’ve
standardized on React and some shared libraries like Lodash.

We’ve primarily benefitted from the forced feature and team isolation (aka
domain boundaries if you would), plus it gives teams more granular control
over their deployments. So, pretty much just what you described.

Another benefit has been our ability to build once and share features across
different applications, since we have a few of those for reasons. Teams can
build out different “views” (roughly) for different use cases on different
apps which share the core functionality.

