Suggestions
Brent Miller
Director of Front-end Engineering and Design
Brent Miller is a seasoned professional with over 20 years of experience in the software industry, specializing in creating solutions for high-profile clients like NFL, NHL, MLB, Orbitz, PBS, National Geographic, and The Washington Post.
He is passionate about exploring the limitless potential of web and mobile technologies while ensuring that his solutions prioritize accessibility requirements.
Brent holds a bachelor's degree in Computer Science, Psychology, and Communications from Benedictine University, where he honed his skills and knowledge.
Throughout his career, Brent has held key positions at various esteemed organizations, including Director of Front-end Engineering and Design at Trusona, Principal Frontend Engineer at The Washington Post, and Lead UI Engineer at OfficeMax, among others.
His extensive background includes roles as a Front End Consultant at EPRI, National Geographic, Accenture, National Geographic, Simply Accessible, and Public Broadcasting Service, as well as Senior and Consultant Software Engineer positions at multiple organizations like MultiPlan, TRAVELCLICK, The Nielsen Company, and Viant, among others.
Brent's diverse experience spans across industries such as technology, media, healthcare, and finance, demonstrating his versatility and adaptability to various sectors and challenges.
With a strong belief in the power of communication as the foundation for successful project implementation, Brent emphasizes the importance of effective collaboration and clear messaging in achieving desired outcomes.
Highlights
Why I Hate React
You know what I hate? React. There, I said it. I can practically hear the front-end developers collectively gasping, as if I’ve just suggested using tables for layout. But let’s be honest—do we really need React? I don’t think so.
When React first came out, I was on board. The lifecycle methods made sense, and it felt like a breath of fresh air compared to the tangled mess of jQuery spaghetti code. It was like discovering a new tool in the shed that actually made yard work enjoyable. But then, the hooks came along. At first, they seemed like a simpler API—no need for higher-order components or convoluted render props. It was like finding out your favorite tool had a hidden feature. But as I started writing more complex components, hooks turned out to be more complicated than trying to assemble IKEA furniture without the instructions.
Let's talk about those hooks. They promise simplicity, but once you get into the weeds with them, you realize they're like those infomercial gadgets that look easy on TV but leave you with more mess than you started with. The dependency arrays, the endless useEffect calls—it's enough to make your head spin. Managing state and side effects in hooks is like trying to juggle while riding a unicycle on a tightrope. One wrong move, and everything comes crashing down.
And then there's the community obsession with React. It's become the default choice for every new project, like avocado toast at a hipster brunch spot. But do we really need React for everything? With modern web standards, we have tools like Lit and Web Components that the browser natively supports. These technologies are like a sturdy, well-built house—future-proof and reliable. Meanwhile, React feels like a trendy, overpriced loft—flashy but not always practical for the long term.
Web Components let you create reusable, encapsulated elements that work across different frameworks and libraries. It's like having a universal remote that actually controls all your devices. With React, you're locking yourself into a specific ecosystem that may not age well. It's like buying a Betamax player just before VHS took over.
The complexity of React also means more time spent on boilerplate and configuration. Setting up a new React project often feels like preparing for a NASA launch. There's the webpack config, the Babel setup, and don’t even get me started on state management libraries. It’s like needing an engineering degree just to get your project off the ground.
So, there you have it. React might be the darling of the front-end world, but to me, it's an overcomplicated, trendy mess. With modern browser capabilities, we've got all the tools we need to create dynamic, efficient web applications without the need for React. Now, if you'll excuse me, I've got some real coding to do—no hooks required.
Why I Hate TypeScript
You know what I hate? TypeScript. There, I said it. I can practically hear the seasoned developers groaning, as if I’ve just suggested using inline styles. But let’s be honest—do we really need TypeScript? I don’t think so.
First off, TypeScript feels like overkill. Remember when JavaScript was simple? It was like a friendly neighborhood diner where you could get a burger and fries without any fuss. Now, with TypeScript, it's like that diner turned into a five-star restaurant with a dress code. Suddenly, you need to declare types and interfaces for everything. Mr. TypeScript demands that you wear a tuxedo just to write a basic function.
And don't get me started on the learning curve. We spend years mastering JavaScript, getting to know its quirks and nuances, only to be told that we need to learn an entirely new language on top of it. It's like being fluent in English and then being told you need to learn Esperanto to just write a button click handler. Sure, TypeScript promises fewer bugs and better code, but at what cost? More time spent debugging type errors and less time doing what we actually enjoy—writing code that works.
Speaking of bugs, let’s talk about those type errors. Have you ever tried to compile a TypeScript project? It feels like having a backseat driver who criticizes every turn you make. "Oh, you can't assign a string to a number," it says. Well, thanks for the heads-up, but I knew that! JavaScript lets you get the job done quickly and efficiently. TypeScript, on the other hand, feels like it's constantly second-guessing you, like a nosy neighbor peeking over the fence to make sure your lawn is mowed to their standards.
And let's be honest, do we really need static typing in JavaScript? The beauty of JavaScript is its flexibility, its ability to adapt and change on the fly. TypeScript, with its strict typing, feels like it’s trying to shove JavaScript into a suit and tie. It's like inviting your free-spirited friend to a formal dinner party—they’re not going to have a good time, and neither are you.
Then there's the tooling. With JavaScript, you can just jump in and start coding. But with TypeScript, you have to set up your environment, configure your compiler options, and install a bunch of dependencies. It’s like needing a manual to operate a light switch. Simplicity is sacrificed at the altar of type safety.
Finally, there's the smug satisfaction of the TypeScript enthusiasts. You know the type—they look at you like you're still using dial-up internet if you prefer JavaScript. Well, listen you Java and C# developers who wandered in on my language, telling me to embrace static typing, I say this: get off my lawn!
So, there you have it. TypeScript is just an unnecessary time sink. With JavaScript, we’ve got all we need. Now, if you'll excuse me, I've got some real coding to do—no TypeScript required.
