4 ms·

>Scale that to a VERY large application. I have. Without problems. >In practice, CSS blows up, other portions of the app stop working correctly. Perhaps in

>Scale that to a VERY large application. I have. Without problems. >In practice, CSS blows up, other portions of the app stop working correctly. Perhaps in your practice, tracker1. But not in mine. That's what everyone seems to be missing here. This is all a bunch of hand waving to me, because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me. If you need all of this stuff to ship robust, maintainable code, then you would be foolish not to use it. But I would be foolish to use some complex framework that I do not need to ship robust, maintainable code. I think the facade is starting to crack with many of these JS frameworks. More and more people are writing articles like the OP and saying that this particular emperor has no clothes.

tracker1 8y ago
> because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations. The application above was around 2007-2008 IIRC... different parts made by different teams, cobbled together. Layers of backend cruft as well. I did help start a new project, that had much more consistent/clean structure. But when you have too many hands in a pie, and no automated testing in place, you wind up with that eventually. I've been developing web based applications since 1996. I've lived through the eras without the browsers and abilities we have today... the growth of the DOM and the JS language from a few interfaces for forms, to being able to do so very much. You don't have to use anything to ship your code... but you have to do something to get a few dozen devs working on something cohesive.
- rhapsodic 8y ago
  >Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using the latest fads -- at the time it was the Rational Unified Process, with all the attendant documentation, and EJBs. I knew that Entity Beans were a monumentally stupid idea when I first read the O'Reilly book about them. And I said so, to anyone who would listen, to no avail. I think the team reached 40 developers at its peak, of which maybe half were totally incompetent. (By my standards.) The schedule slipped rapidly, we were put on mandatory 6 day work weeks, I bailed out, easily finding another job, and eventually the whole project cratered. I'm not going to argue with your experience, tracker1, but all of my experience tells me that the ability of the developers is the best predictor of the outcome of a software development project. And our profession, unfortunately, is awash with incompetent people. For example, people who have worked for over 5 years as a Java developer, who are unable to write a Hello World program in Java from scratch in a plain text editor, and compile it and run it from the command line.
  - tracker1 8y ago
    I came into my example above 5 years in... it was "Enterprise" .Net and not Java, but a lot of the same techniques at play... I hated it all. I'll take today's JS/NPM ecosystem over those days. I rally against ORM, and DI/IOC frameworks to the end, they aren't needed in JS. That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers. As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad. I did learn C# from the command line compiler and a book early on, I didn't have VS to hold my hand. I later did learn VS etc, and that was nicer still. Getting the pieces together with node/js has been difficult, and painful and a slow process even keeping up with node since it was first announced in 2009. It's taken effort. But anything more than a quick demo, I'd rather have it. I'll leave TypeScript/flow and similar alone though, I don't think they bring more than they take most of the time.
    - rhapsodic 8y ago
      >That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers. I realize I'm outside the mainstream schools of thought. My approach to developing software absolutely depends on having a rare and special kind of developer doing the work. The emphasis is on deep expertise in the core technologies - JS, HTML and CSS -- that will stay around while fads come and go. And quite frankly, my approach does not scale well. It's not that I couldn't keep 40 developers of the caliber I require productive, it's just nigh on impossible for a non-Google-class company to hire that many in one place. (Considering all you've heard about Google's hiring process, imagine how much it costs them to hire a single developer -- even before the first paycheck is cut.) >As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad. Maybe you're reversing cause and effect. Maybe your exposure has been so bad because you've never made the effort to learn it from scratch. When I adopt a technology for use, I go really deep. I'll get a book, start on page 1, and work through it to the end. (Sometimes I might deem the last few chapters skippable.) After a few months I'll re-read parts of it as a refresher. (That has proven super-helpful.) That's why I think Reactjs and its like are a lot of fuss and bother to do something that I can already do easily with a lot fewer moving parts. And also, if I decide to use React, I, and (perhaps to a slightly lesser extent) my developers, will go deep into it, and that takes a lot of time and effort. So I have to be very judicious in what new shiny thing I go chasing after. I need to see an obvious, significant return on that type of investment. (I don't care about my resume having the latest buzzwords.) And I just don't see it with any of these frameworks.

tracker1 8y ago

> because I have a lot of experience shipping a lot of robust, maintainable code, and none of it has been true for me Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. Frameworks and modern tools help to take care in these situations. The application above was around 2007-2008 IIRC... different parts made by different teams, cobbled together. Layers of backend cruft as well. I did help start a new project, that had much more consistent/clean structure. But when you have too many hands in a pie, and no automated testing in place, you wind up with that eventually. I've been developing web based applications since 1996. I've lived through the eras without the browsers and abilities we have today... the growth of the DOM and the JS language from a few interfaces for forms, to being able to do so very much. You don't have to use anything to ship your code... but you have to do something to get a few dozen devs working on something cohesive.

rhapsodic 8y ago
>Ave you ever had to work on an application that's more than 5 years old, with an active dev team of 30+ (just the web developers) that have had over 200 hands in the pie including contractors then? I have, and it was a nightmare. I was a rank and file developer on a similar shit show years ago. The main difference was that it was a greenfield project at a startup. The people calling the shots were dead set on using the latest fads -- at the time it was the Rational Unified Process, with all the attendant documentation, and EJBs. I knew that Entity Beans were a monumentally stupid idea when I first read the O'Reilly book about them. And I said so, to anyone who would listen, to no avail. I think the team reached 40 developers at its peak, of which maybe half were totally incompetent. (By my standards.) The schedule slipped rapidly, we were put on mandatory 6 day work weeks, I bailed out, easily finding another job, and eventually the whole project cratered. I'm not going to argue with your experience, tracker1, but all of my experience tells me that the ability of the developers is the best predictor of the outcome of a software development project. And our profession, unfortunately, is awash with incompetent people. For example, people who have worked for over 5 years as a Java developer, who are unable to write a Hello World program in Java from scratch in a plain text editor, and compile it and run it from the command line.
- tracker1 8y ago
  I came into my example above 5 years in... it was "Enterprise" .Net and not Java, but a lot of the same techniques at play... I hated it all. I'll take today's JS/NPM ecosystem over those days. I rally against ORM, and DI/IOC frameworks to the end, they aren't needed in JS. That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers. As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad. I did learn C# from the command line compiler and a book early on, I didn't have VS to hold my hand. I later did learn VS etc, and that was nicer still. Getting the pieces together with node/js has been difficult, and painful and a slow process even keeping up with node since it was first announced in 2009. It's taken effort. But anything more than a quick demo, I'd rather have it. I'll leave TypeScript/flow and similar alone though, I don't think they bring more than they take most of the time.
  - rhapsodic 8y ago
    >That said, I'm not saying no frameworks/libraries/tools, and am okay minimizing. But I'd rather use Vue, React, Redux and other libraries/patterns than not in most cases, and find them better overall than ad-hoc jQuery. And don't get me wrong, I've written a lot of ad-hoc and organized code without modern tooling. I'll take today's module systems, builders and bundlers. I realize I'm outside the mainstream schools of thought. My approach to developing software absolutely depends on having a rare and special kind of developer doing the work. The emphasis is on deep expertise in the core technologies - JS, HTML and CSS -- that will stay around while fads come and go. And quite frankly, my approach does not scale well. It's not that I couldn't keep 40 developers of the caliber I require productive, it's just nigh on impossible for a non-Google-class company to hire that many in one place. (Considering all you've heard about Google's hiring process, imagine how much it costs them to hire a single developer -- even before the first paycheck is cut.) >As to Java hello world, frankly every time I've had to touch a Java project, it takes 2-3 days to get a build environment running on a local dev machine... it's nightmarish. I've never even taken to learning Java from scratch my exposure has been so bad. Maybe you're reversing cause and effect. Maybe your exposure has been so bad because you've never made the effort to learn it from scratch. When I adopt a technology for use, I go really deep. I'll get a book, start on page 1, and work through it to the end. (Sometimes I might deem the last few chapters skippable.) After a few months I'll re-read parts of it as a refresher. (That has proven super-helpful.) That's why I think Reactjs and its like are a lot of fuss and bother to do something that I can already do easily with a lot fewer moving parts. And also, if I decide to use React, I, and (perhaps to a slightly lesser extent) my developers, will go deep into it, and that takes a lot of time and effort. So I have to be very judicious in what new shiny thing I go chasing after. I need to see an obvious, significant return on that type of investment. (I don't care about my resume having the latest buzzwords.) And I just don't see it with any of these frameworks.