4 ms·

In my experience, the best way to avoid fighting frameworks, is to keep framework use minimal, and just write the 30 lines of UI code yourself for your custom f

by tonis2 5y ago

In my experience, the best way to avoid fighting frameworks, is to keep framework use minimal, and just write the 30 lines of UI code yourself for your custom form. Why does the JavaScript rendering require so many abstractions layers ?. I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework. I use Web Components and some minor libraries, having so much easier time going this way. Not to kick down the hard work on developing of Redwood, but I'm just tired of being forced to use these frameworks on jobs. At startup stage the team picks a monolithic framework, after 2 years the developers are depressed building with it and leave, then new developers that come are met with a mess and fixing even easy bugs, is practically rewriting 5000 lines of code of the app, because everything is so entangled.

KronisLV 5y ago
> I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework. For the most part, i'd say that frameworks being largely standardized and having ecosystems around them is a really good thing: people who are familiar with Vue/Angular/React (front end) and with Spring Boot/Express.js/Django/Rails (back end) can start working with your application more quickly than if it uses your custom "sort-of-like-jQuery-but-not-really" set of libraries/framework for the front end or your own thing for back end, which obviously will fall short in regards to documentation, consistency or ready made components. You can hire for Vue/Angular/React and Spring Boot/Express.js/Django/Rails, you cannot hire for your bespoke in-house solution. Also, the devs behind those solutions can spend more time and resources on making them better than your entire app will have put into it. That's why i largely avoid projects which have bespoke solutions like that, especially for back end frameworks, which typically are a minefield of badly written and badly tested code, as well as present numerous security related challenges. That stance was truly cemented when in one project i was stuck with an untested framework that stored half of the functionality in the DB, used JDBC directly through numerous abstractions, had commented out sections of code strewn about the codebase and had comments in Lithuanian, a language that i don't speak and had no documentation whatsoever. Of course, i've also seen things go into the opposite direction too far: instead of something like Bootstrap or its integration with any of the aforementioned popular frameworks/libraries being used, picking Tailwind CSS and spending weeks if not months mucking about with custom components without actually shipping features and solutions to business problems. If you are lucky enough to have front ends simple enough to be adequately handled by a few hundred/thousand lines of JS then by all means go ahead (right tool for the problem and all that), but that has never been my experience in any of the enterprise projects that i've worked on. Admittedly, however, i do feel these standard frameworks/libraries also getting more and more complicated as time goes on, because their eventual transformation into something that tries to do "everything" (and thus downfall) feels almost inevitable.

by tonis2 5y ago

KronisLV 5y ago

> I understand the promise that frameworks sort of do the heavy lifting for you, but after 2 years into the app, you are stuck with the framework, and the work hours to fix problems are going up, cause most of your code is hidden inside the framework. For the most part, i'd say that frameworks being largely standardized and having ecosystems around them is a really good thing: people who are familiar with Vue/Angular/React (front end) and with Spring Boot/Express.js/Django/Rails (back end) can start working with your application more quickly than if it uses your custom "sort-of-like-jQuery-but-not-really" set of libraries/framework for the front end or your own thing for back end, which obviously will fall short in regards to documentation, consistency or ready made components. You can hire for Vue/Angular/React and Spring Boot/Express.js/Django/Rails, you cannot hire for your bespoke in-house solution. Also, the devs behind those solutions can spend more time and resources on making them better than your entire app will have put into it. That's why i largely avoid projects which have bespoke solutions like that, especially for back end frameworks, which typically are a minefield of badly written and badly tested code, as well as present numerous security related challenges. That stance was truly cemented when in one project i was stuck with an untested framework that stored half of the functionality in the DB, used JDBC directly through numerous abstractions, had commented out sections of code strewn about the codebase and had comments in Lithuanian, a language that i don't speak and had no documentation whatsoever. Of course, i've also seen things go into the opposite direction too far: instead of something like Bootstrap or its integration with any of the aforementioned popular frameworks/libraries being used, picking Tailwind CSS and spending weeks if not months mucking about with custom components without actually shipping features and solutions to business problems. If you are lucky enough to have front ends simple enough to be adequately handled by a few hundred/thousand lines of JS then by all means go ahead (right tool for the problem and all that), but that has never been my experience in any of the enterprise projects that i've worked on. Admittedly, however, i do feel these standard frameworks/libraries also getting more and more complicated as time goes on, because their eventual transformation into something that tries to do "everything" (and thus downfall) feels almost inevitable.