So it’s okay to use frameworks when you’re small and scrappy, but they will slow you down when you grow into an enterprise… because build processes?
Enterprises have processes, lots of them, to maintain continuity for their many customers and compliance with their many legal obligations. They tend to adopt frameworks as teams to ensure some consistency in practices. Adding one more build step is minute, but creating a commonjs style guide and state management system isn’t.
No, you don’t get to FTP into prod anymore and edit static files in vim. We use build processes to make sure code works efficiently and effectively across many browsers and devices. Editing CSS by hand makes sense for small and medium projects, but gets to be pretty large pretty quickly and serves users way faster if tree-shook and code-split. We use source control so we can make changes forward and back, with approval, constraint, and automation.
There is a bitter tone here that tastes like sour grapes. Slogging through webpack can do that to be certain :) but this dismisses the collective work of hundreds of thousands of engineers who have worked to make the web do things it was never imagined to do, for an unthinkably vast and diverse audience. How they reason about organizing their tools and processes reflects the scale of the unique things they need to accommodate. They are not wrong for not just sticking with jquery.
Sure I miss the HotDog HTML days sometimes, but then I look around and see that my desktop is in my pocket, and my bank is an app, and my word processor is a webpage.
Angular is THE #1 enterprise framework in my market.
React is also extremely popular. Those have massive adoption and exist for a long time now. React exists for 8 years now.
JS compilers / transpilers were part of every enterprise JS toolchain i have seen in the last years.
Sure, dont include every f'ing npm lib there is, but using established and well supported frameworks like these actually is a REQUIREMENT if you want to do enterprise FE work right now (or in the last 5 years for that matter)
The author's chief complaint about Angular boils down to... version numbers? Is he also upset that Chrome has reached version 92? Bumping the major version number doesn't mean you have to rewrite your app (with the sole exception of the O.G. Angular 2).
I think the article is a cry for help by the author who is a middle aged software developer panicking at the sight of the speed the frontend world is moving at.
At first I did not want to question the credentials of the author, he calls himself an "elite developer" and I assume is is pretty good at HTML/CSS and the software development process (gathering requirements etc.) in general.
I understand he feels left out, so many job and gig postings now requiring in-depth knowledge of declarative frameworks such as React or Angular, something he has skipped over on purpose, on principle, and now feels more and more left out.
However, having checked out this guys website https://beaubeauchamp.com/ I now understand basically what this person does is create static landing-page-style websites.
I understand that plain HTML/CSS might be the best fit for that.
But writing a full-fledged interactive application, something that would have been released as a desktop app a few years ago, is simply a different league.
In addition, even regarding plain HTML/CSS landing pages, I don't understand how this person can call himself "elite":
I got annoyed by the "fake smooth scroll" feature on his website and low contrast of various UI elements compared to the background.
And the public portfolio was mediocre at best. I mean sure, you could definitely find clients that would still be happy with the Web 2.0 style design and functionality (e.g. https://harleyaustin.com/ simply one large HTML page with the top navbar making you scroll to the position on the page), but I wouldn't exactly call this "elite frontend development".
I guess what this person is good at is finding real-economy clients (book authors, travel companies, etc.) and get well-paid gigs (I assume).
And this type of job still works, even with React/Angular creating entire new markets and a lot of hype around them.
I just don't think this person is the best source for state of the art web application development.
> I understand he feels left out, so many job and gig postings now requiring in-depth knowledge of declarative frameworks such as React or Angular, something he has skipped over on purpose, on principle, and now feels more and more left out.
Ooh boy, is this it. And take a look at his other blog articles to see how deep he's digging his heels in to his rally cry against modernity.
>However, having checked out this guys website https://beaubeauchamp.com/ I now understand basically what this person does is create static landing-page-style websites.
Since I thought the theme looked familiar, I checked with builtwith and it shows the site is using Wordpress.
I think it's quite interesting that they're not a fan of UI frameworks, but are using wordpress for their personal site.
I just realized that Harley Austin from harleyaustin.com is the same guy that wrote the article. He writes romance novels, horrible blog posts, and websites.
jQuery is great at generating tech debt. It can also do DOM binding.
Any attempts to organize and make sense of someone's unstructured jQuery code will result in an ad hoc "hot-rodding, fly-by-the-seat-of-my-pants" framework that only the guy(s) who originally wrote it know(s). That won't fly in the "enterprise world".
Also, I'm not an Angular guy (I actively refuse to work with it), but to lambast Angular 2+ for its version numbering -- which I think is just semver?, and give React a pass for the same thing (hey guess what, React is at v17 now) is odd to me.
By dismissing TypeScript on principle, this guy is losing out immensely (hey guess what #2, if you're using Gulp or Grunt (uh, in 2021?) which the author says he's OK with, it's a 10 minute job to add a TS or Sass compilation step)).
Unless you only use that for production builds, I suppose. But if so, does that mean the author maintains an ordered list of JavaScript/CSS files to import during dev time? Oh. Oh no. That won't save you any time.
If you're that afraid of learning new things, maybe just frontend isn't for you. And that's OK. But maybe don't be so proud of it.
Agree completely. I’ve seen projects grind to a a halt because of broken build processes too. I won’t use anything that needs a build step. I work on multiple large-ish sites in different business domains and manage without any front-end frameworks.
I hope people don’t read this and start taking it seriously. UI frameworks are more important if you are a large company. It encourages consistency, re-use of components and CSS, and helps teams remain true to a design system.
I’ve never had to wait or consider build times using React at a large tech company. Everything hot reloads and the iteration cycles are fast.
It’s not clear what argument the author is putting forward. It comes off as an emotional argument disguised as “I have 20 years experience so do as I say”. No thanks.
Enterprises have processes, lots of them, to maintain continuity for their many customers and compliance with their many legal obligations. They tend to adopt frameworks as teams to ensure some consistency in practices. Adding one more build step is minute, but creating a commonjs style guide and state management system isn’t.
No, you don’t get to FTP into prod anymore and edit static files in vim. We use build processes to make sure code works efficiently and effectively across many browsers and devices. Editing CSS by hand makes sense for small and medium projects, but gets to be pretty large pretty quickly and serves users way faster if tree-shook and code-split. We use source control so we can make changes forward and back, with approval, constraint, and automation.
There is a bitter tone here that tastes like sour grapes. Slogging through webpack can do that to be certain :) but this dismisses the collective work of hundreds of thousands of engineers who have worked to make the web do things it was never imagined to do, for an unthinkably vast and diverse audience. How they reason about organizing their tools and processes reflects the scale of the unique things they need to accommodate. They are not wrong for not just sticking with jquery.
Sure I miss the HotDog HTML days sometimes, but then I look around and see that my desktop is in my pocket, and my bank is an app, and my word processor is a webpage.