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.
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.
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.
> 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.
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.
Re "complexity", for reference: the dependency tree (as in yarn list) of production-only installation of a default angularJS app created with ng new --minimal app is...
(I wanted to paste it, but it's too long = 2500 lines)
I think this is a separate problem. The JS ecosystem's love of dependencies is not about complexity, but about "not re-inventing the wheel" - everyone has been trained that for any problem there is a library to solve it, and writing code to solve the problem yourself is a waste of time.
This attitude is already hurting everyone, and it's only going to get worse. But it's a different thing than the complexity problem.
For me it's the definition of complexity. Something that has many parts is complex.
If I want to dig into "how my angular app works", I can't, because I cannot browse 2500 npm packages on github to find out what they are doing. Even answering the question "does my app actually require this dependency" is completely impractical.
To be fair, I had this problem learning Rails too. I like knowing how and why something works, and so the "it just does this because that's the convention for Rails" was confusing and annoying rather than helpful, and trying to dig into the Rails code base to work out why was pointless.
Part of the reason I love Go is because there's no magic. I can look at the definition of a std lib function and it's right there, in plain code, and makes sense.
But despite Go being simpler than Rails (for this reason), I'm not sure that any given Go project is simpler than any given Rails project. The moving parts are more obscure, definitely, but I'm not sure there are more of them or that they're providing more complexity.
> 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.
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.
At my day job, the meme that won and now dominate is "the percieved performance of a SPA is greater than that of a non-SPA". My calls for making our backend more performant are ignored (and probably ridiculed, because of how out-of-the-loop I seem). React for the win!
Personal anecdote: Angular 1.x at the time was a breath of fresh air because it allowed to create very clean, very modular front-ends with a lot of (unit) testing opportunities. The next best thing we had at the time (again, in my own experience) was Backbone, which was a lightweight layer on top of jquery but we didn't have any tests on that one.
So for us Java developers it was great. I don't know about Angular 2 and beyond, but I'm sure it has its place.
I get the impression that OP's day job requires that they use Angular but they were able to use ASP.NET Core Razor Pages for a side project. I could be wrong.
Either way, I can confirm to OP's findings with Angular. I worked on an Angular project not too long ago and every time I hit Command-S I had to wait 10 seconds before the page would refresh. Manually refreshing wasn't an option, of course, because it was busy compiling. I tried to explain to my client that those 10 seconds were quickly adding up considering what my billable rate was but they didn't seem to mind. It was from Google and that's all they needed to know.
React native’s fast refresh is... I’m not even sure of the words to describe it. Revelatory? I had no idea it was possible to develop apps so quickly and seamlessly while maintaining state as you code. I thought edit and continue debugging was the holy grail in C# until I used fast refresh and redux. I would not be exaggerating by saying that I would choose react native as a technology strictly because of how much fast refresh speeds up development of GUIs (but it’s great for many other reasons too). I can’t wait for fast refresh to make its way into react web. We have several large, complex apps in ionic/Cordova/angular stack and now that ionic react is stable it won’t be long for us to jump off Angular altogether.
We have a large desktop application that hosts tabs of other react applications and provides windowing features, all built in Electron, that is written in React. we can edit a component within an app and save it and have the UI update with the same state and the new component change in under a second. react native fast refresh is even better because it’s understanding of life cycles and hooks is better but hot reloading within a react app is extremely performant for us. I wonder why you’re having to wait so long?
I've started playing around with React Native lately and so far have been pleasantly surprised. I have also used NativeScript quite a bit and it too has a very fast compile and refresh. I don't know what it is about Angular that makes the refresh so slow.
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.
It does not suck. The compile times are OK and are getting better. Angular (and other) SPAs have capabilities no RoR, ASP.NET or Django setup can even begin to touch. Separating the back-end from the front-end with an independent API is also a god-send.
Death to remaining in the dark ages for nostalgia's sake.
Oh, it does suck, hugely. Longer time to first paint, more bandwidth, more cpu and battery usage, huge dependency chains, slow "live" updates...
A lot of my issue with the Javascript-heavy present of "modern" SPA websites is that they have to recreate native browser functionality, which is inevitably slower and worse.
Way too many websites could have the same functionality, in a simpler form, with better performance with a more "traditional" stack. You can even have your API separated front-end and back-end via server-side rendering (by which I mean old-style server-side rendering).
The modern zeitgeist is mostly hype, fad, and novelty.
> The compile times are OK and are getting better.
Our frontend Angular test runs take 25 minutes to run less than 2,000 unit (not integration) tests. That's just nonsense. I don't blame Angular so much as I blame the JS ecosystem. For comparison our backend unit test runs (ASP.NET Core) take 3 minutes to run 6,000 tests.
You can argue we're doing something wrong, but as a company with a a thousand or so devs - reaching out to the most experienced frontend devs we have, their answer is: you've got too many tests, split up your SPA into smaller SPAs. Great, more complexity and dependency management hell.
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.
> 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.
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.
> 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.
What I mean when I say by 'know npm/yarn' is that you have to know the internals, how they operate, and why they break. You have to debug npm/yarn themselves. That's not something one should know to build anything on the frontend. In many years with other languages' dependency tools like PHP's composer and Clojure's leiningen, I've had to deal with dependency and internal package manager issues maybe once or twice and that's being generous as I really don't remember any times. So do I think the JS tools are shitty? They are shitty beyond all fucking imagination and comparing them to tools in other languages can objectively prove that by simply looking at the number of times and the way these tools break vs. the tools that don't break. I wouldn't be so adamant about it except I spend more time (as I'm sure many here do) dealing with breakages in npm and yarn than in any other system related deployment task. And the insanity of it is that this isn't even application code. It just concats some files and runs them through a few code processors like babel and scss. That's fucking insanely bad tooling.
As far as webpack, I understand that it's a jack of all trades. But if even trying to replicate a simple bundling config takes many days, then it's a perfect example of a tool that's not only overly complex, but one that doesn't do its own core job well.
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.
It's incrediy subjective obviously, but in my 25 years of web dev (full stack) rendering speed has been the number one gripe from users. I've spent thousands of hours optimizing web things. The biggest impact on user perception of speed was the move to Web 2.0 eg JS apps that fetch data with 'ajax' and update the DOM.
If my experience is anything to go by users absolutely prefer client side rendered apps (with SSR, hydration, caching, memoization, optimal data structuring, etc, etc).
No doubt a huge amount of client side JS is garbage, and users would be better served by a server rendered website than a bad client side rendered app, but they'd be even better off still with a good client side rendered site.
I often use a mix, with ASP.NET Core MVC doing most of the work, but using Javascript to load some things at the client-side - for example, table data.
This provides fast page loads, with the ability to load additional data without reloading the whole page.
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.
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.
> 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.
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.
> 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).
> 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.
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.
> 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-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?)
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.
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
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.
It's not about struggling so much as about avoiding a situation where one small problem makes a site either look visually 'broken' or (worse) fail to function correctly.
There are way too many small bugs and incompatibilities like these, and way, way too many browser versions still seeing use by at least a small percentage of users, to worry about them individually, unless you want that to eat up all your time.
So your choice is between "be okay with a broken experience for some users", or "use build tools to compile to a common-ancestor target of near-universally-supported CSS and JS".
What build tools do you use that ensure your site works consistently across different browser versions without needing any browser-version-specific testing/fixes on your part?
I've worked on web pages that use what seems to be a pretty standard Webpack/Babel/PostCSS/etc setup, and they still ran into some issues where layout or behavior was different between browsers. Either because they used a CSS property value or JavaScript API (or API parameter/option) that wasn't available everywhere, or because of more subtle disagreements between browsers about things like where an inline element's containing block is.
You're right, it's not possible to eliminate the need for testing/fixes. I didn't say it was. It's a tradeoff; compiling to a stable older set of features reduces bugs but doesn't eliminate them.
Part of the work has to be on the developer. There are certain properties that will screw up positioning when used with flex elements in IE, for example, and knowing what those are and how to avoid those combinations is part of the cost of skillfully using flexbox. The compiler can't always do the work, but we should let it do as much as it can.
1. the most of JS tooling stemming from browser compatibility issues does not mean that the issues still need to exist at the point that the tooling was established - it can take a while for established stuff to be moved out.
2. I think for most sites it isn't a problem, but for me the last 3 years has been work on big SPAs that need to generally also handle IE9 (degrade gracefully). And there is always stuff going on.
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.
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-clie...
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.
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.
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.