6 ms·

Seriously, people in this thread should really stop complaining about 'complexity' in the web space if they really haven't written & maintained a jQuery applica

Seriously, people in this thread should really stop complaining about 'complexity' in the web space if they really haven't written & maintained a jQuery application. Most of JS tooling stems from 1. different browsers and 2. (the once) nonexistent module system. Until very recently, 2 didn't have any solutions (so Browserify, Webpack, Parcel, and various different bundlers exist) and 1 still doesn't (and so Babel exists). These tools aren't the simplest things, but so is everything, everywhere. Complexity needs to exist somewhere, and using an abstraction to hide them is something natural. Do people think we shouldn't use compilers because we 'can' write binary ELF files directly? Same goes to JS.

acemarke 7y ago
Exactly. There's very good reasons why tools like Webpack and Babel exist. Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem: http://tinselcity.net/whys/packers http://tinselcity.net/whys/packers https://www.swyx.io/writing/jobs-of-js-build-tools https://www.swyx.io/writing/jobs-of-js-build-tools As a counter-point, there's also valid reasons why a lot of the JS tooling ecosystem is painful to work with: https://increment.com/development/the-melting-pot-of-javascript/ https://increment.com/development/the-melting-pot-of-javascr... https://www.swyx.io/writing/js-tooling/ https://www.swyx.io/writing/js-tooling/ For myself personally, I'm quite happy with the React ecosystem. For the kinds of "desktop-app-in-a-browser" apps I work on, it's fantastic. (Caveat: I'm a Redux maintainer, so I'm also a bit biased here.)
- dmix 7y ago
  Plus theres a ton of starter kits for newbies on Github to get rolling without having to figure out the details. They are like mini-frameworks. Plenty for react, vue, etc, every combination.
deleted 7y ago
[deleted]
GiorgioG 7y ago
I disagree. I spend most of my time at work in an Angular app and it sucks. The compile times suck, the developer experience sucks and it's not getting better, it's only getting worse. I had a chance to do some side work and decided against building a SPA. I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order. If I need some more complex interactivity then I might sprinkle in something lightweight but I expect that to be the exception not the rule. Death to complexity on the frontend for complexity's sake.
- deleted 7y ago
  [deleted]
- coenhyde 7y ago
  These sound like implementation issues. Why does compile time suck? Do you cache compiled files and update only what has changed? Are you doing minimization and / or compressing in development? If compile time isn't under a second during development, you're doing it wrong.
- pcr910303 7y ago
  > I spend most of my time at work in an Angular app and it sucks. The compile times suck, the developer experience sucks and it's not getting better, it's only getting worse. > I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order. Okay, so I've never worked in Angular, so I can't really speak (maybe there are Angular killer features that justifies using Angular?), but... If it looks like it'll be simpler in ASP.NET pages, go for it! Everybody likes lighter pages, if your app is simple * doesn't need to be a heavy Angular SPA, you shouldn't be using them.
  - GiorgioG 7y ago
    Most apps are simple, no I’m not talking about Facebook. The problem is templated pages apps are not considered sexy, so we build SPAs so we can look good (and pad the resume,) to the detriment of productivity.
hanoz 7y ago
For the vast majority of web users the only sites they ever visit that really need any of these front end frameworks are their webmail and social network platforms of choice. For everywhere else a combination of backend processing with a smattering of vanilla javascript, or jquery, would provide a far superior user experience.
- Zelphyr 7y ago
  I don't see what's wrong with this post that it should be downvoted like it has been. I personally agree with this sentiment. It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I've seen it time and again... they get bogged down in making sure the app can scale when they have yet to have a single paying customer for the product. At that point, they don't even know if there is even a market for the product and they're trying to build something that millions of users can use right out of the box. The priorities are off. If a combination of back-end processing with some vanilla javascript, or jquery will get you to market for your first 100-1000 users (which, we know it will because that used to be the only way we could do things, on much less powerful hardware no less) then I say go with that. In the mean time you can work with the stakeholders to put together a strategy for scaling up as demand increases.
  - lukevp 7y ago
    I replied to one of your other posts about how great I think React development is, but I want to also state my wholehearted agreement with this thread. For things you would use a SPA framework for, it’s really the types of thing that are apps that happen to be hosted through a web browser. They’re very distinct from web pages. Most user facing websites should be built with backend server processing and js/query. React is nice because you can progressively enhance particular components, so it works well as a complement to a backend language, but in that case the tooling overhead is pretty high for what you get. So in those cases I typically go the jQuery route as well.
  - philbarr 7y ago
    > It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I just finished working in the public sector and it's absolutely terrible for this. We had a microservice based event-driven architecture, all on AWS, load balancers everywhere. It was so complicated not a single person knew the entire architecture. Current number of users: 65 Expected maximum number of users ever: 8000
grok2 7y ago
I think part of the thing that people complain as complexity is the fact that there is too much choice in the web world and no one framework/tool/language is dominant and clearly better than the rest.
Zelphyr 7y ago
The problem is--in my experience anyway--that too many people equate complexity with quality. That exists as part of human nature, it seems, and so naturally that has followed into the JavaScript ecosystem. I've written and maintained several jQuery applications and if I'm being honest, I much prefer it over all the tooling we have today. jQuery isn't perfect because nothing is of course, but with a little discipline I never really had any trouble maintaining a jQuery application. In my opinion, all the tooling we have today does is obfuscates me away from my code and actually makes it harder to maintain.
- josteink 7y ago
  > The problem is--in my experience anyway--that too many people equate complexity with quality. I find that a strange attitude. Complex systems are by definition harder to reason about, and therefore guaranteed to contain more bugs given the same amount of mental effort. Sometimes complexity is unavoidable, but in general I find myself attracted to simpler systems, and consider that a sign of good engineering rather than the other way around.
  - regularfry 7y ago
    I agree with you, but you and I do not represent a majority.
mnm1 7y ago
Tools don't have to be complex. We have about a fifteen line json config for brunch for the usual build chain. It took a day or two to develop and can be copied with few changes to other projects. Compare this to one of our devs spending over a week and hundreds of lines of config with webpack and still couldn't achieve an identical config. The de facto tools like webpack, gulp, grunt, etc. are unnecessary complexity monsters. That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools. Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project. The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.
- pcr910303 7y ago
  > Compare this to one of our devs spending over a week and hundreds of lines of config with webpack and still couldn't achieve an identical config. The de facto tools like webpack, gulp, grunt, etc. are unnecessary complexity monsters. > That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools. Well, the complexity is because webpack/gulp/grunt are do-everything tools. There are lots of features to assist everyone, and usually if you have some obscure requirements, webpack has an solution. Yeah, webpack is complex - IMO one shouldn't use webpack just to bundle up JS files. There are opinionated tools like Parcel or CRA(which automatically configures webpack under-the-hood), and those will fit 90% of the users. Only the left 10% which existing opinionated solutions cannot accommodate can fiddle with the webpack config directly. > Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project. Well, do you really think JS has low-quality tools? I really don't see them as low-quality... And you should know npm/yarn before starting a JS project; it's like knowing gcc/clang before starting a C project, or knowing cargo before starting a Rust project. > The complaints are more than valid when there are tools that do the same job without the unnecessary complexity. (Assuming you're talking about npm/yarn) If you can do the same job without all the dependencies, you don't have to know package managers. If you want to, you should know the package managers.
csande17 7y ago
> Most of JS tooling stems from 1. different browsers Do people struggle a lot with cross-browser issues these days? It isn't like it was back in the day, when basic stuff like the box model worked wildly differently in IE. And almost everyone's on a rolling-release, auto-updated browser, so you don't have to worry about testing on old versions; even big websites like Stack Overflow only support the last couple releases of the most popular browsers: https://meta.stackexchange.com/questions/56161/which-browsers-are-officially-supported-and-what-else-do-i-need https://meta.stackexchange.com/questions/56161/which-browser... I still test on multiple browsers, and every once in a while I'll need to fix a bug that only shows up in one browser. But JavaScript frameworks and build tooling don't really help with that, do they? (Am I missing out?)
- PetahNZ 7y ago
  A lot of features are still wildly different between browsers. SVG being one particular pain point for me. And Safari is the browser that I have the most issues with recently.
- Kiro 7y ago
  No idea why you're getting downvoted. I'm wondering the same thing. I've even stopped prefixing anything and haven't seen any issues in any browser.
- avip 7y ago
  Yes. If you're a front-end developer at some capacity, developing anything of use for > 0 users, you'll have hell of a lot of browser compatibility issues. People will browse your app from ancient mobile phones. Weird smart TVs. play consoles. Chinese browsers you've never heard of but come bundled with some we-something, they will browse your app from PoS, from a DJI smart RC, from a fridge. And from IE6. And you know what's the best way to mitigate all that mental load? You just start upfront with a framework that was already battle-tested on all these weird browsers.
  - csande17 7y ago
    What framework do you recommend for wide browser support? React certainly doesn't claim to support anything like feature-phones or IE 6; the lowest they go is IE 9, and that's only if you load additional polyfills: https://reactjs.org/docs/react-dom.html#browser-support https://reactjs.org/docs/react-dom.html#browser-support
jamil7 7y ago
I think you're right in that all this complexity didn't come out of a vacuum but I also feel the complexity in front end web development and the development costs that come from it are a real issue and shouldn't be dismissed. Yes I've worked in jQuery spaghetti and experienced that, but just because it might have been worse doesn't mean the situation in front end web development is good or can't be improved. Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore. anecdotally I got out of JS / frontend mid last year after many many years in it and felt at the time that I was burnt out and had lost my passion for development. Maybe it was just too long for me in one area.
- stringyham 7y ago
  What do you do now?
- root_axis 7y ago
  > the complexity in front end web development and the development costs that come from it are a real issue and shouldn't be dismissed I would argue that it's an absurdly overblown issue. The "costs" are a clear net gain which is why these tools are all but ubiquitous. Developer hype only goes so far, these tools are a proven success across every major tech company with a front-end presence. All this supposed complexity is a holistic improvement over the past, especially because all the same libraries and techniques from 20 years ago and everything in between work exactly the same way today. > Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore. Sounds like literally every piece of corporate software I've worked on that's older than 10 years. 10 year old php app? 15 year old c++ app? 15 year old vb6 app? 15 year old c app? Those are all examples of previous nightmares I have experienced and none of them were any easier to handle than a shitty angular mess. At least the browser is incredibly resilient with regard to failure states... try debugging intermittent crashes in a legacy c++ app preserved in a tacky lacquer of clever templating voodoo; nothing in js land even comes close to my time in the c++ insane asylum.
Cthulhu_ 7y ago
> Do people think we shouldn't use compilers because we 'can' write binary ELF files directly? Same goes to JS. The problem however is that JS is a perfectly fine programming language by now. Think about it, why are we still stuck with Webpack et al? It's because of inconsistent or missing support for modules / imports, or because of a risk that a JS feature you use does not work on a certain browser. And there's JSX of course. JS is not assembly.
_pmf_ 7y ago
> These tools aren't the simplest things, but so is everything, everywhere. No. An insanely complex Eclipse based Java product I maintained had hundreds of dependencies (including transitive), from a handful of vendors (> 20). Apparently, an simple JS app[0] can have 40000 packages (from hundreds of vendors). This is insane. [0] https://stackoverflow.com/questions/55416657/why-do-i-have-40000-packages-in-my-angular-7-project-how-to-remove-unused-depe https://stackoverflow.com/questions/55416657/why-do-i-have-4...
esjeon 7y ago
jQuery still can be used with webpack, but you'll be cursing webpack while configuring it to work like that. The thing about webpack is that it exposes too much complexity that setting it up is always painful. Not many people are against compilation itself.
NohatCoder 7y ago
Browser incompatibilities are mostly gone, where they still exist frameworks tend to do nothing to solve them. I write web stuff and I used to do the dance of testing with a bunch of browsers and fixing stuff. Since IE 11 there have been basically nothing to fix, the browsers really do behave the same.
- mfontani 7y ago
  > Browser incompatibilities are mostly gone Not really, and not even something that pertains to "really old" browsers. As a somewhat recent example, in order to implement "SameSite=None" properly, one has to ensure it's _not_ sent to browsers (including recent Safaris and Chromes) which implement it badly. See also: https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie...
csomar 7y ago
Not only that. But even if you are making a very simple static HTML website, you start bumping into problems very quickly. Here are a few things where Gulp/Webpack have helped. - Auto-browser reloading. - Minification and compiling all JS/CSS into single files. - Partials for Header/Footer/Menus. - CSS/JS files versioning (the browser-caching issue). Sure you can build a static website without all these niceties. But these are a one time investment (gulp+webpack) that you can re-use for your future websites and work.
amelius 7y ago
> Complexity needs to exist somewhere, and using an abstraction to hide them is something natural. Yes but designing the right abstraction is an artform, and I suppose that these tools haven't yet found it.
tlrobinson 7y ago
Agreed. I've concluded the reason there's so much disagreement about the "right" level of tooling/abstraction is because there's a such a wide variety of "web applications" and developers with varying amounts of experience building complex applications.

acemarke 7y ago

Exactly. There's very good reasons why tools like Webpack and Babel exist. Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem: http://tinselcity.net/whys/packers http://tinselcity.net/whys/packers https://www.swyx.io/writing/jobs-of-js-build-tools https://www.swyx.io/writing/jobs-of-js-build-tools As a counter-point, there's also valid reasons why a lot of the JS tooling ecosystem is painful to work with: https://increment.com/development/the-melting-pot-of-javascript/ https://increment.com/development/the-melting-pot-of-javascr... https://www.swyx.io/writing/js-tooling/ https://www.swyx.io/writing/js-tooling/ For myself personally, I'm quite happy with the React ecosystem. For the kinds of "desktop-app-in-a-browser" apps I work on, it's fantastic. (Caveat: I'm a Redux maintainer, so I'm also a bit biased here.)

dmix 7y ago
Plus theres a ton of starter kits for newbies on Github to get rolling without having to figure out the details. They are like mini-frameworks. Plenty for react, vue, etc, every combination.

deleted 7y ago

[deleted]

GiorgioG 7y ago

I disagree. I spend most of my time at work in an Angular app and it sucks. The compile times suck, the developer experience sucks and it's not getting better, it's only getting worse. I had a chance to do some side work and decided against building a SPA. I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order. If I need some more complex interactivity then I might sprinkle in something lightweight but I expect that to be the exception not the rule. Death to complexity on the frontend for complexity's sake.

deleted 7y ago
[deleted]
coenhyde 7y ago
These sound like implementation issues. Why does compile time suck? Do you cache compiled files and update only what has changed? Are you doing minimization and / or compressing in development? If compile time isn't under a second during development, you're doing it wrong.
pcr910303 7y ago
> I spend most of my time at work in an Angular app and it sucks. The compile times suck, the developer experience sucks and it's not getting better, it's only getting worse. > I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a breath of fresh air - I haven't enjoyed myself this much writing web software in ages because I can get stuff done in very short order. Okay, so I've never worked in Angular, so I can't really speak (maybe there are Angular killer features that justifies using Angular?), but... If it looks like it'll be simpler in ASP.NET pages, go for it! Everybody likes lighter pages, if your app is simple * doesn't need to be a heavy Angular SPA, you shouldn't be using them.
- GiorgioG 7y ago
  Most apps are simple, no I’m not talking about Facebook. The problem is templated pages apps are not considered sexy, so we build SPAs so we can look good (and pad the resume,) to the detriment of productivity.

hanoz 7y ago

For the vast majority of web users the only sites they ever visit that really need any of these front end frameworks are their webmail and social network platforms of choice. For everywhere else a combination of backend processing with a smattering of vanilla javascript, or jquery, would provide a far superior user experience.

Zelphyr 7y ago
I don't see what's wrong with this post that it should be downvoted like it has been. I personally agree with this sentiment. It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I've seen it time and again... they get bogged down in making sure the app can scale when they have yet to have a single paying customer for the product. At that point, they don't even know if there is even a market for the product and they're trying to build something that millions of users can use right out of the box. The priorities are off. If a combination of back-end processing with some vanilla javascript, or jquery will get you to market for your first 100-1000 users (which, we know it will because that used to be the only way we could do things, on much less powerful hardware no less) then I say go with that. In the mean time you can work with the stakeholders to put together a strategy for scaling up as demand increases.
- lukevp 7y ago
  I replied to one of your other posts about how great I think React development is, but I want to also state my wholehearted agreement with this thread. For things you would use a SPA framework for, it’s really the types of thing that are apps that happen to be hosted through a web browser. They’re very distinct from web pages. Most user facing websites should be built with backend server processing and js/query. React is nice because you can progressively enhance particular components, so it works well as a complement to a backend language, but in that case the tooling overhead is pretty high for what you get. So in those cases I typically go the jQuery route as well.
- philbarr 7y ago
  > It's like the developers who immediately rush to massive scale when all they've been asked to build is effectively a prototype. I just finished working in the public sector and it's absolutely terrible for this. We had a microservice based event-driven architecture, all on AWS, load balancers everywhere. It was so complicated not a single person knew the entire architecture. Current number of users: 65 Expected maximum number of users ever: 8000

grok2 7y ago

I think part of the thing that people complain as complexity is the fact that there is too much choice in the web world and no one framework/tool/language is dominant and clearly better than the rest.

Zelphyr 7y ago

The problem is--in my experience anyway--that too many people equate complexity with quality. That exists as part of human nature, it seems, and so naturally that has followed into the JavaScript ecosystem. I've written and maintained several jQuery applications and if I'm being honest, I much prefer it over all the tooling we have today. jQuery isn't perfect because nothing is of course, but with a little discipline I never really had any trouble maintaining a jQuery application. In my opinion, all the tooling we have today does is obfuscates me away from my code and actually makes it harder to maintain.

josteink 7y ago
> The problem is--in my experience anyway--that too many people equate complexity with quality. I find that a strange attitude. Complex systems are by definition harder to reason about, and therefore guaranteed to contain more bugs given the same amount of mental effort. Sometimes complexity is unavoidable, but in general I find myself attracted to simpler systems, and consider that a sign of good engineering rather than the other way around.
- regularfry 7y ago
  I agree with you, but you and I do not represent a majority.

mnm1 7y ago

Tools don't have to be complex. We have about a fifteen line json config for brunch for the usual build chain. It took a day or two to develop and can be copied with few changes to other projects. Compare this to one of our devs spending over a week and hundreds of lines of config with webpack and still couldn't achieve an identical config. The de facto tools like webpack, gulp, grunt, etc. are unnecessary complexity monsters. That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools. Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project. The complaints are more than valid when there are tools that do the same job without the unnecessary complexity.

pcr910303 7y ago
> Compare this to one of our devs spending over a week and hundreds of lines of config with webpack and still couldn't achieve an identical config. The de facto tools like webpack, gulp, grunt, etc. are unnecessary complexity monsters. > That's what people are complaining about here and they have a right to. It's not the idea that's flawed, it's the ridiculously over complex, constantly breaking implementations like the ones above and most similar tools. Well, the complexity is because webpack/gulp/grunt are do-everything tools. There are lots of features to assist everyone, and usually if you have some obscure requirements, webpack has an solution. Yeah, webpack is complex - IMO one shouldn't use webpack just to bundle up JS files. There are opinionated tools like Parcel or CRA(which automatically configures webpack under-the-hood), and those will fit 90% of the users. Only the left 10% which existing opinionated solutions cannot accommodate can fiddle with the webpack config directly. > Not too mention the low quality of such tools and npm itself requiring one to now be an expert on not only the build chain, but npm and yarn before even starting any project. Well, do you really think JS has low-quality tools? I really don't see them as low-quality... And you should know npm/yarn before starting a JS project; it's like knowing gcc/clang before starting a C project, or knowing cargo before starting a Rust project. > The complaints are more than valid when there are tools that do the same job without the unnecessary complexity. (Assuming you're talking about npm/yarn) If you can do the same job without all the dependencies, you don't have to know package managers. If you want to, you should know the package managers.

csande17 7y ago

> Most of JS tooling stems from 1. different browsers Do people struggle a lot with cross-browser issues these days? It isn't like it was back in the day, when basic stuff like the box model worked wildly differently in IE. And almost everyone's on a rolling-release, auto-updated browser, so you don't have to worry about testing on old versions; even big websites like Stack Overflow only support the last couple releases of the most popular browsers: https://meta.stackexchange.com/questions/56161/which-browsers-are-officially-supported-and-what-else-do-i-need https://meta.stackexchange.com/questions/56161/which-browser... I still test on multiple browsers, and every once in a while I'll need to fix a bug that only shows up in one browser. But JavaScript frameworks and build tooling don't really help with that, do they? (Am I missing out?)

PetahNZ 7y ago
A lot of features are still wildly different between browsers. SVG being one particular pain point for me. And Safari is the browser that I have the most issues with recently.
Kiro 7y ago
No idea why you're getting downvoted. I'm wondering the same thing. I've even stopped prefixing anything and haven't seen any issues in any browser.
avip 7y ago
Yes. If you're a front-end developer at some capacity, developing anything of use for > 0 users, you'll have hell of a lot of browser compatibility issues. People will browse your app from ancient mobile phones. Weird smart TVs. play consoles. Chinese browsers you've never heard of but come bundled with some we-something, they will browse your app from PoS, from a DJI smart RC, from a fridge. And from IE6. And you know what's the best way to mitigate all that mental load? You just start upfront with a framework that was already battle-tested on all these weird browsers.
- csande17 7y ago
  What framework do you recommend for wide browser support? React certainly doesn't claim to support anything like feature-phones or IE 6; the lowest they go is IE 9, and that's only if you load additional polyfills: https://reactjs.org/docs/react-dom.html#browser-support https://reactjs.org/docs/react-dom.html#browser-support

jamil7 7y ago

I think you're right in that all this complexity didn't come out of a vacuum but I also feel the complexity in front end web development and the development costs that come from it are a real issue and shouldn't be dismissed. Yes I've worked in jQuery spaghetti and experienced that, but just because it might have been worse doesn't mean the situation in front end web development is good or can't be improved. Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore. anecdotally I got out of JS / frontend mid last year after many many years in it and felt at the time that I was burnt out and had lost my passion for development. Maybe it was just too long for me in one area.

stringyham 7y ago
What do you do now?
root_axis 7y ago
> the complexity in front end web development and the development costs that come from it are a real issue and shouldn't be dismissed I would argue that it's an absurdly overblown issue. The "costs" are a clear net gain which is why these tools are all but ubiquitous. Developer hype only goes so far, these tools are a proven success across every major tech company with a front-end presence. All this supposed complexity is a holistic improvement over the past, especially because all the same libraries and techniques from 20 years ago and everything in between work exactly the same way today. > Anyone who's had to maintain one of these projects long term without a massive team or inherited an older codebase understands that there are serious churn / depenency hell / code rot and complexity issues here and layering more and more abstractions on top to try and dig ourselves out of the hole we're in might not be working anymore. Sounds like literally every piece of corporate software I've worked on that's older than 10 years. 10 year old php app? 15 year old c++ app? 15 year old vb6 app? 15 year old c app? Those are all examples of previous nightmares I have experienced and none of them were any easier to handle than a shitty angular mess. At least the browser is incredibly resilient with regard to failure states... try debugging intermittent crashes in a legacy c++ app preserved in a tacky lacquer of clever templating voodoo; nothing in js land even comes close to my time in the c++ insane asylum.

Cthulhu_ 7y ago

> Do people think we shouldn't use compilers because we 'can' write binary ELF files directly? Same goes to JS. The problem however is that JS is a perfectly fine programming language by now. Think about it, why are we still stuck with Webpack et al? It's because of inconsistent or missing support for modules / imports, or because of a risk that a JS feature you use does not work on a certain browser. And there's JSX of course. JS is not assembly.

_pmf_ 7y ago

> These tools aren't the simplest things, but so is everything, everywhere. No. An insanely complex Eclipse based Java product I maintained had hundreds of dependencies (including transitive), from a handful of vendors (> 20). Apparently, an simple JS app[0] can have 40000 packages (from hundreds of vendors). This is insane. [0] https://stackoverflow.com/questions/55416657/why-do-i-have-40000-packages-in-my-angular-7-project-how-to-remove-unused-depe https://stackoverflow.com/questions/55416657/why-do-i-have-4...

esjeon 7y ago

jQuery still can be used with webpack, but you'll be cursing webpack while configuring it to work like that. The thing about webpack is that it exposes too much complexity that setting it up is always painful. Not many people are against compilation itself.

NohatCoder 7y ago

Browser incompatibilities are mostly gone, where they still exist frameworks tend to do nothing to solve them. I write web stuff and I used to do the dance of testing with a bunch of browsers and fixing stuff. Since IE 11 there have been basically nothing to fix, the browsers really do behave the same.

mfontani 7y ago
> Browser incompatibilities are mostly gone Not really, and not even something that pertains to "really old" browsers. As a somewhat recent example, in order to implement "SameSite=None" properly, one has to ensure it's _not_ sent to browsers (including recent Safaris and Chromes) which implement it badly. See also: https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie...

csomar 7y ago

Not only that. But even if you are making a very simple static HTML website, you start bumping into problems very quickly. Here are a few things where Gulp/Webpack have helped. - Auto-browser reloading. - Minification and compiling all JS/CSS into single files. - Partials for Header/Footer/Menus. - CSS/JS files versioning (the browser-caching issue). Sure you can build a static website without all these niceties. But these are a one time investment (gulp+webpack) that you can re-use for your future websites and work.

amelius 7y ago

> Complexity needs to exist somewhere, and using an abstraction to hide them is something natural. Yes but designing the right abstraction is an artform, and I suppose that these tools haven't yet found it.

tlrobinson 7y ago

Agreed. I've concluded the reason there's so much disagreement about the "right" level of tooling/abstraction is because there's a such a wide variety of "web applications" and developers with varying amounts of experience building complex applications.