4 ms·

Now add 500 more features and 10 engineers and see if it scales. Hint: it doesn’t. Sure you can make it work, but as someone who regularly makes FE decisions fo

by qudat 4y ago

Now add 500 more features and 10 engineers and see if it scales. Hint: it doesn’t. Sure you can make it work, but as someone who regularly makes FE decisions for a team, I wouldn’t want to impose vanilla on them. What I will say is it’s tough. I don’t like the idea of react at this point. I like building products that don’t need something heavy like react/redux. I recently launched https://lists.sh https://lists.sh to scratch that no js itch. It was a ton of fun and I want to chase that feeling. But building a web app is what businesses want. And while you could make vanilla js work, you’d be reinventing a lot of tooling to get you there.

BiteCode_dev 4y ago
Also: - add time constraints, where you need to implement widgets that you could source from a JS framework ecosystem otherwise. - in your 10 engineers, make it 5 juniors, 2 interns and 3 seniors comming from PHP, and make sure they write all the code in the same style, follow a congruent architecture, can find solutions to common problem, get easy onboarding, etc. - request sub-routing, off-line mode, notifications, content udpated by multiple users and so on. - put a big table in there with 10000 rows and ask your team it renders fast.
1marc 4y ago
With some patterns they can follow, vanilla js does indeed scale so well that it becomes boring. There’s no longer any code to rewrite for the latest and greatest frameworks. No dependencies to manage. It just becomes almost too easy at some point, at least in my experience with many projects I’ve led. I’ve made millions and millions for major brands, including my own company, and customers go “wow how is your site so fast!!” All. The. Time. The biggest pressure I’ve found is from the engineers themselves. Not all engineers like to go counter culture and learn browser APIs and JavaScript. They would simply like to use what everyone else is using. They tend to argue against vanilla using canned arguments read off of framework websites that don’t apply much or aren’t even problems in the actual codebase. :shrug:

by qudat 4y ago

BiteCode_dev 4y ago

Also: - add time constraints, where you need to implement widgets that you could source from a JS framework ecosystem otherwise. - in your 10 engineers, make it 5 juniors, 2 interns and 3 seniors comming from PHP, and make sure they write all the code in the same style, follow a congruent architecture, can find solutions to common problem, get easy onboarding, etc. - request sub-routing, off-line mode, notifications, content udpated by multiple users and so on. - put a big table in there with 10000 rows and ask your team it renders fast.

1marc 4y ago

With some patterns they can follow, vanilla js does indeed scale so well that it becomes boring. There’s no longer any code to rewrite for the latest and greatest frameworks. No dependencies to manage. It just becomes almost too easy at some point, at least in my experience with many projects I’ve led. I’ve made millions and millions for major brands, including my own company, and customers go “wow how is your site so fast!!” All. The. Time. The biggest pressure I’ve found is from the engineers themselves. Not all engineers like to go counter culture and learn browser APIs and JavaScript. They would simply like to use what everyone else is using. They tend to argue against vanilla using canned arguments read off of framework websites that don’t apply much or aren’t even problems in the actual codebase. :shrug: