6 ms·
We do 100% vanilla web development for our B2B product now. Our roadmap went something like: (Client Authoritative State) Angular 2.x/??? => RiotJS/Bootstrap =
by bob1029 4y ago
We do 100% vanilla web development for our B2B product now. Our roadmap went something like:
(Client Authoritative State) Angular 2.x/??? => RiotJS/Bootstrap =>
(Server Authoritative State) Blazor/Bootstrap => Custom/Vanilla
The Angular and Riot apps were a nightmare to maintain long-term. We sign contracts with our customers that are 5+ years long, so having autonomy over this sort of stuff is critical. The rate of change with these frameworks was too much to deal with, especially at our scale of <10 employees.The big solve moving to Blazor from RiotJS was keeping the state on the server and being able to reuse existing C# codebase to manage UI. This continues to be very productive for us. Server-authoritative state is the answer for keeping complex UIs on rails.
We still have quite a few interfaces on top of Blazor, but those aren't really a pain point for us (at least until Microsoft does what they usually do in a few major versions...). The biggest catalyst for moving from Blazor/Bootstrap to Vanilla was 2-fold: On one hand, the power of modern web APIs, such as CSS Grid, eliminates a large reason why you need a 3rd party layout system in the first place. On the other, we realized that dynamically updating the DOM using a 2-way web socket setup is actually not that complicated or scary, assuming you have well-scoped requirements and aren't afraid of javascript.
For hand-rolled vanilla, the way we sync the DOM is with a simple 2-way web socket protocol where the server has a dictionary of elements per active client, and hashes of state are used to detect required updates after client events are processed. No shadow DOM or any of that crap. We just blow it all out and redraw on update. None of our UIs has enough elements to justify all that extra complexity right now. We could easily iterate into several directions if we needed to over time. The key point is that we understand 100% of our stack. Every line of code makes sense to us. At no point do we have to worry about someone pulling support or shifting their framework in an adverse direction.
Finally, we also have major security concerns with vendoring out anything, since our product is used - in part - for in-branch banking. The hottest PII you can imagine flows through our web app every day. Being able to tell various CTOs that there is no supply chain risk with our web UI is a very fun hat trick for me.
- P5fRxh5kUvp2th 4y agoI have a mini-rant about that. When a company decides to use Angular (for example), they're also deciding to jump on the rat-wheel that is constant upgrades to the next version. Meanwhile, that vanilla app will just keep working in perpetuity.
- nfw2 4y agoA company can just stick to one version of Angular in perpetuity if it wants to. The code in some Angular X.X.X release will always be the same, and the Angular org can't magically break your code by releasing a new version of it.
- tqkxzugoaupvwqr 4y agoBut if your framework of choice is big, you’ll have trouble extending/modifying it and be locked in.
- nfw2 4y agoAnd if your hand-rolled solution is big, you'll also have trouble extending/modifying it. The argument was that hand-rolled code doesn't break on its own, and my point is neither does framework code.
- P5fRxh5kUvp2th 4y agoThat was never the argument.
- P5fRxh5kUvp2th 4y agoHow sure are you of that?
- n3t 4y agoYou can vendor your project's framework of choice. Or, more generally, all your dependencies. Moreover, I believe you should be able to build your project without expecting npm to host all your dependencies ~forever and being online when you need it.
- P5fRxh5kUvp2th 4y agoA PCI auditor will ding the shit out of you for using a version of Angular that has known security vulnerabilities, even more so if you've decided to "vendor your project of choice" and it's been EoL'd. And for good reason. While you can theoretically do this, the point is that you really can't, nor would anyone call it responsible to do so even if they weren't worried about regulatory compliance. The question isn't "can you keep it forever", the question is "how long can you keep it". With these frameworks that answer is typically 18-24 months. For more mature systems that answer is going to be 3-5 years, and for even more mature systems it's going to be 8-10. FOR EXAMPLE asp.net https://docs.microsoft.com/en-us/lifecycle/products/microsoft-net-framework https://docs.microsoft.com/en-us/lifecycle/products/microsof... 2015-2022 = 7 years Angular https://en.wikipedia.org/wiki/Angular_(web_framework)#Support_policy_and_schedule https://en.wikipedia.org/wiki/Angular_(web_framework)#Suppor... 2021-2022 = 1.5 years. And the status is LTS (LONG TERM SUPPORT). But it gets even worse than that because the asp.net is worrying about the _runtime_, Angular is worrying about the _framework_. If we were going to compare apples-to-apples here, the support term for asp.net is even longer than 7 years. --- The reason so many developers don't consider this is specifically because they move on every 18-24 months, and they're happy wasting time upgrading systems on the ratwheel. But businesses aren't, instead they're held hostage by it. --- There's another thread on HN right now with people bitching about SAP. SAP will still run functions that were written 20 years ago.