Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
The description doesn't really give me enough to make a judgement. I don't know as to the competency or lack thereof on your team, but I can tell you the reasons I do that.
1. Composition
Many times I will want to be able to use components the same way I would write configurable code. Create a building or a strategy that will take a generic specification for the pieces needed and their interfaces, and then an executor that wires them all up.
tl;dr I'll define a shell, and then fill the shell with implementations decided at runtime
2. Tree-shaking
One of the nifty things about modern FE code is you have the ability to automatically exclude dead code through the use of abstract syntax trees. If your code is a giant blob of blobbish proportions with no segregation, the dead leaves are harder to shake and more prone to accidental inclusion by assocation.
3. Lazy loading and bundling
So I have 50 components. Some components are compositional components (accept other components at design or runtime). Others are functional components (perform work).
Breaking those components into various buckets allows you to plug an interface-specific piece of functionality into an existing compositional space.
The far end of this is, at compile time, you can create modules that can be fetched lazily. So instead of serving a 4mb package all at once, I can serve pieces of the application over time or via preloading as they are needed.
tl;dr my sites have a requirement of <1s from request start to running. This is mandatory to hit that on low power devices.
Found something true as 1 == 1
Implementing the application exactly like the client specified, because they won't listen.
Life when you didn't know about browsers developer tools
Can somebody explain to me why developers (especially web) have to micromanage every single thing into it's own f*ing component.
Story time: I have an input form with some tabs. I discovered that the UI Library (Devextreme) has a nice little component that handles forms, (including tabs, groups, etc.). So I make a page, configure tabs, inputs and whatnot.
Now, I already knew that my coworkers can't handle html that is bigger than a page. So instead of putting the configs in the frontend, I made nice files where I store those, to keep them nicely clean and seperated.
Me feeling very good, went off to have a nice lunch break.
I come back read the message from my coworker, asking me to make every tab it's own component and form and load them into a separate Tab-Component, instead of using the built in configuration
......
WHAT?
Like seriously. I have a f*ing library that handles that, why the f*ck do I need to reinvent the wheel here!?
Supposedly it's to make it more maintainable, easier to find bugs, flatten the hierarchy.
Here's a little wake up call you morons: Nesting hundreds of components into each other does *not* help you with that.
It just creates a rabbit-hole of confusing containers that you have to navigate and dissect every time you try to find something.
"Can I fix the bug in the detail Page? Sure I'll tell you tomorrow when I find out which fucking component the bug results from".
Components are there to be *reused*. It's using inheritance for reusing code all over again, but worse.
But maybe I'm just old fashioned, and conservative. Maybe I'm just a really bad software engineer, because nowadays everything seems to result in architectures spreading hundreds of folders, thousands of files with nothing but arbitrary cut-offs with no real benefit, that I don't see the value in.
rant
typescript
web
angular2
architecture