article: Why You Should Stop Using UI Frameworks
-
Just as Jacquers said, this is a solid way to ensure that you end up developing your own UI framework that's both poorly tested, poorly documented, but worst of all is not known by anyone but the current developers working on it. How much time is a business really going to want to waste re-inventing the wheel when there's frameworks out there already? I would think it'd have an impact on recruitment as well. It's all well and nice to mention that the front-end is written using vanilla JS and CSS, but ultimately at some point the question is going to be asked "what sort of front-end libraries or frameworks do you use?" and someone is going to have to explain that this developer (with experience with Angular + React + Typescript + LESS/SASS/SCSS) is going to have to learn a whole new, custom framework. Yikes :laugh:
-
I've been doing web dev for many years and all I ever add is jquery and a common js file. There's no need to build your own ui framework. Keep it simple.
-
I could not find the obligatory XKCD, so here is the obligatory CommitStrip: Unintentional framework | CommitStrip[^] I never use Java frameworks... mainly because I do not use Java.
-
Frameworks are "good" if all you ever do is write the same type of app; typically featuring lots of "data grids". Want to model the solar system? Then forget it.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it. ― Confucian Analects: Rules of Confucius about his food
-
I agree with the line at the end of the article that says:
Quote:
But at the end of the day nothing works better and is easier to debug and maintain than just pain JS and native CSS.
:-\
-
Even if you forego the frameworks and use plain vanilla js, eventually you'll end up making your own helper classes / ui library to reuse functionality. Imo you may as well use something like Angular / React, etc. that is well tested and documented.
I ain't gonna use Angular. I am still baffled this pile of crap is so popular. My preferences and love would go to Vue.js, Knockout.js.. But me think I might drop it all and use Blazor! :D
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I ain't gonna use Angular. I am still baffled this pile of crap is so popular. My preferences and love would go to Vue.js, Knockout.js.. But me think I might drop it all and use Blazor! :D
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I use Angular regularly and like it, maybe because the setup is kind of like MVVM which I used with WPF. I've had a little bit of experience with React and it can do some cool stuff. Blazor does look cool, but I have yet to try it. I largely use whatever is required at work, so maybe we'll get a project someday where this would be an option. I had a look at [Svelte • Cybernetically enhanced web apps](https://svelte.dev/) recently and it looks nice.
-
I use Angular regularly and like it, maybe because the setup is kind of like MVVM which I used with WPF. I've had a little bit of experience with React and it can do some cool stuff. Blazor does look cool, but I have yet to try it. I largely use whatever is required at work, so maybe we'll get a project someday where this would be an option. I had a look at [Svelte • Cybernetically enhanced web apps](https://svelte.dev/) recently and it looks nice.
You should have a look at Vue.js! I tried Angular, but I found it a PITA to use. And was confused too easily by seemingly simple angular code. Compare o what I could do with Knockout.js, I saw little benefits and lot of pain...
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
8 versions of Angular in 6 years! The problem is not just keeping up with the latest version: some old projects are still using the older versions. When the customer comes back to you with a feature request, you have to write/maintain code that interacts with old Angular. Plus later versions of Angular use Typescript which developers have to learn as well. The learning curve is very steep with Angular and is difficult to troubleshoot when things go wrong.
-
I was going to object with "what's wrong with VCL or WPF", but then I've read it's about web UI frameworks, not UI frameworks in general.
-
Even if you forego the frameworks and use plain vanilla js, eventually you'll end up making your own helper classes / ui library to reuse functionality. Imo you may as well use something like Angular / React, etc. that is well tested and documented.
Point of article is that you should write your own helpers. Because then you are in control. With Angular we just got hit by what is written in article. We have angular 7 in our build process - which depends on node-saas and guess what that version of node-saas is now gone on github 404 not found. Yes we probably should have updated it to newer version earlier. But I am not product owner and guess what - when we told him how much it will take to update and how many regressions might be there decision was: "if it works leave it as is".
-
Point of article is that you should write your own helpers. Because then you are in control. With Angular we just got hit by what is written in article. We have angular 7 in our build process - which depends on node-saas and guess what that version of node-saas is now gone on github 404 not found. Yes we probably should have updated it to newer version earlier. But I am not product owner and guess what - when we told him how much it will take to update and how many regressions might be there decision was: "if it works leave it as is".
That sucks :( To be fair this could happen to any project with 3rd party dependencies on Nuget packages. Although it adds to the size of the repo (and many would argue against it) we check in node_modules to avoid this situation. You could maybe add (from a dev pc) just the ones you're missing to fix the build?
-
Even if you forego the frameworks and use plain vanilla js, eventually you'll end up making your own helper classes / ui library to reuse functionality. Imo you may as well use something like Angular / React, etc. that is well tested and documented.
-
Server side Blazor is very underrated for web work. Then again I don't have anything pushed out to production yet, but the development experience is so much nicer. It's going to get even better when they get hot reload to work.
-
And why not? Your personal lib will be both streamlined and controlled by you. Maybe I'm a coding megalomaniac, but I'd much rather have control of as much of my code as possible.
-
I like Angular, but the author has a really good point when you get to V7 of it. And I can't keep up with upgrading Angular versions, finally coming to a road block on V7.2 or something, breaking my entire app when compiling because my .Net framework won't play nice with it. Constantly having to change NPM packages to fix an issue. I need to revisit my website when I get time again. I may just dump it and write a new one in something else. I'm working on a PHP App Upgrade for a customer and decided to keep it in PHP but went 7.4.14 using objects I wrote, plain vanilla JavaScript ECMA6, and Plain CSS that I wrote from scratch along with BootStrap 5. I'm almost a year in now and I've been able to code in peace without having to upgrade anything. This app should be able to run another 10 years without an update.
If it ain't broke don't fix it Discover my world at jkirkerx.com
-
Even if you forego the frameworks and use plain vanilla js, eventually you'll end up making your own helper classes / ui library to reuse functionality. Imo you may as well use something like Angular / React, etc. that is well tested and documented.
I actually agree with the article in some aspects. if the project scope is small to medium: stick with basics: JS/CSS easier to maintain over the years/developers. if the project gets to be large to stupid big: frameworks do help out in at least keeping things organized. but are a super pain when updating to a new(er) version. (if possible, we still have a Angular 1 project that no one wants to touch in fear of it breaking) I was surprised the article mentioned Handlebars.js, since it's not much of a framework and more of a lightweight approach to making html partials with some customizing if needed. I feel like this belongs also in the medium range of projects, help keep you organized but not get in your way of development. technically it's a backend server side renderer, but it's also easy to build a front end version of the same thing, takes about a day to build most of the features. where I work we have technically 3 types of projects: * basic html5/JS/CSS -when no DB is needed * ASP.Net core/JS/bootstrap -when DB access is required * React/bootstrap. The first two I enjoy working in, the projects are quick and fun, the last takes way more time to work out the features and layouts, and just feels heavy in final implementation.