4 ms·

Sorry but the tone of this article rubs me a bit wrong. Clearly the author didn't spend enough time in the bad old days maintaining massive piles of CSS and JQ

Sorry but the tone of this article rubs me a bit wrong. Clearly the author didn't spend enough time in the bad old days maintaining massive piles of CSS and JQuery vomit to appreciate why modern approaches are the way they are. If an app approaches any degree of non trivial complexity on the front end, a framework like react or angular can really pay off. On the other hand, if we are just talking about a little vanity site or something that isn't going to need to be maintianed long term, by all means go old school. Just don't tell me that it's better in all cases because I've got the scars.

cityofdelusion 9y ago
My experience and my scars are very similar. I remember the old days of maintaining piles of random JS and CSS -- it is not fun and it doesn't scale beyond blog-size without very good planning. I work for a huge national bank and I despise having to work on our older code. Sure, React/Angular/Redux have a learning curve -- but my company is able to deliver features at large scale significantly faster (and with full test coverage!). I cannot overstate how much better developer quality of life has gotten. I'd challenge people opposed to more complex frameworks to consider the challenge of delivering code at scale in the old-school style (say, Java EE with JSPs with shared components across multiple million-line applications, with 50% legacy code > 20 years old). These newer frameworks were created for a reason. I had some doubts at first, but I've seen huge productivity gains. I also don't care to hear complaints about "HTML in my JS". You only need to code a large application one time with a nest of document.createElement calls to see the rationale.
- vikingcaffiene 9y ago
  > I also don't care to hear complaints about "HTML in my JS". Yeah that critique never held much water with me either. When JQuery and other "unobtrusive JavaScript" frameworks came out, it seemed really logical to separate the markup from the logic but, as applications aged and changed things started getting really hairy. I worked for one company that literally could not change any of their front end markup because they had tens of thousands of LOC that interacted directly with the DOM via class and ID selectors. Everything had to be done with CSS which of course led to massive CSS files with 30k lines. Working with something like that made me appreciate a more modular approach that React or Angular bring. Being able to compartmentalize your code into these logical blocks is MUCH easier to manage in the long term. One of the golden rules of programming is "write code thats easy to delete".

cityofdelusion 9y ago

My experience and my scars are very similar. I remember the old days of maintaining piles of random JS and CSS -- it is not fun and it doesn't scale beyond blog-size without very good planning. I work for a huge national bank and I despise having to work on our older code. Sure, React/Angular/Redux have a learning curve -- but my company is able to deliver features at large scale significantly faster (and with full test coverage!). I cannot overstate how much better developer quality of life has gotten. I'd challenge people opposed to more complex frameworks to consider the challenge of delivering code at scale in the old-school style (say, Java EE with JSPs with shared components across multiple million-line applications, with 50% legacy code > 20 years old). These newer frameworks were created for a reason. I had some doubts at first, but I've seen huge productivity gains. I also don't care to hear complaints about "HTML in my JS". You only need to code a large application one time with a nest of document.createElement calls to see the rationale.

vikingcaffiene 9y ago
> I also don't care to hear complaints about "HTML in my JS". Yeah that critique never held much water with me either. When JQuery and other "unobtrusive JavaScript" frameworks came out, it seemed really logical to separate the markup from the logic but, as applications aged and changed things started getting really hairy. I worked for one company that literally could not change any of their front end markup because they had tens of thousands of LOC that interacted directly with the DOM via class and ID selectors. Everything had to be done with CSS which of course led to massive CSS files with 30k lines. Working with something like that made me appreciate a more modular approach that React or Angular bring. Being able to compartmentalize your code into these logical blocks is MUCH easier to manage in the long term. One of the golden rules of programming is "write code thats easy to delete".