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.
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.
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.
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.
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.
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.
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?)
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.
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.
I was once working on a small tool that I tried different iterations of using a small variety of approaches; I tried implementing it in bash, perl, python, ES6 JS (classes and more), and a few other methods (I think at one point I even tried a LibreOffice spreadsheet).
But I kept getting mired and "stuck" in how I should architect things, or what framework to use, or this or that. I eventually decided that I wanted it to be a browser-based app of some sort (thus the road of ES6) - but then I started to wonder what tooling to use there. Lots of questions, etc - and I never got that far with it.
I eventually wised up and realized that it didn't matter what I chose - what I needed was the application to work. Who cares about frameworks, requirejs, css frameworks, etc - I just wanted something working. So I stepped back...and decided to chuck all of that away.
I ended up with a basic webpage, with a script tag and the code inside that - nothing fancy, purely procedural, old-school javascript functions, tied to events. Bare bones, basic.
...and I made real progress for the first time.
Basically, by regressing to the relative simplicity of Javascript back from the 1990s, I was able to get my tool finally going, without having to worry about the last two decades of cruft around that language. Now, I could have also done it using Python or anything else, in the same manner - but again, I wanted it to be browser based.
As you note, my own journey, and not something I'd tell anyone else to do (and certainly not something meant for a production environment!) - but for myself, and my need, this fit the bill. I'm still working on it; I figure when I complete it proper-like, I can go back and refactor it to something more respectable. Or maybe not.
After all, if it works, why try to break it? In the end, I want the results from the tool - who cares what it looks like under the hood, so long as it works.
I write react professionally, but for my freelance projects or any personal projects I came to a similar stack when it comes to simplicity.
Laravel
NGINX
VanillaJS/WebComponents (toying with Svelte right now)
MariaDB
Fast prototyping, simple deployment, almost no time spent with tooling.
A recent example with too much tooling I had was with Root's bedrock+trellis+sage. They do make working with WordPress management for a developer (a lot less clicking that with normal WP setup). But the frontend setup, webpack, backend, browserify and all of that is so complicated and slow. I was able to set it up on one machine, but failed to git clone the same project on two others. Scripts would be missing, things wouldn't load etc. Nightmare.
I wrote my own (minimal) library to do what intercooler does in an effort to strictly progressively enhance a UI for dynamic updates while embracing server-side templating and rendering (ASP.NET Core). I can’t believe I didn’t find this at the time! It’s much more thorough and capable than what I wrote, I’m definitely using this going forward, thank you!
With regards to tooling I agree it is too complicated. I really wish that everyone would coalesce around a standard set of tools. But it would be the equivalent of cat herding.
I agree with your goal. Have you looked into Elixir/Phoenix? Phoenix is a great server-side web framework, and with the recent addition of Phoenix LiveView you can do really nice rich client side stuff, but all written server-side in Elixir.
LiveView is an alternate architecture to intercooler.js but with the same goal. There is a standard JS bundle that goes to the client that opens a websocket to the server. You annotate HTML tags (like intercooler) and then handle the events on the server. This is all abstracted away though so you end up writing a controller that looks a lot like a normal server side rendered page.
> - Anyone who loves tooling-heavy development! This isn’t sarcastic, I promise! By dropping the bundler, you can’t do the magic that Webpack is famous for. Using import to load CSS, Images, and other non-JS resources is non-standard and unsupported in the browser (for now). You may appreciate a dev environment that is true to what standard JavaScript browsers support. Or, you may find this annoying.
---
I like that they make this a point, and I'm very much in the "let's not overload the standards" camp so I appreciate this as a feature, not a bug. This convinces me to give this tool a go!
Consider the series of bad decisions that allowed such complexity to ooze in the first place. It all eventually boils down to developers putting their needs and concerns ahead of the product/user. I am not convinced this new tool will solve for bad/undisciplined developers.
I used to use 1000 NPM packages as a sarcastic example about bad decisions and death by dependency overkill then I installed Angular which pulls in 1100 packages alone. The end user doesn’t care about your framework choice, favorite language, tech stack, or build process. They just know your application is slow, clumsy, and riddled with defects.
This is really exciting to me. I've been meaning to try and get my head around how to start using ES modules with modern JavaScript stuff but it's tough because pretty much every tutorial assumes you'll be using Webpack. Snowpack looks like it might be the tool I've been missing.
I'm hoping some sanity is brought to front-end development. I had a project which legitimately did require a slice of the site to be SPA. I didn't do the full site, just the piece that needed it. When I looked at using React I was confused that it seemingly didn't want me to actually write HTML. Maybe I misread something, but it seemed like it wanted me to return HTML from JavaScript...this made little sense to me. I ended up using VueJS because it was far easier to learn. It did the job.
Webpack certainly is confusing too. I did a side project with some webpack and es6 stuff. It was kinda fun, but man, front-end development has sucked forever. I remember back in the day having to fight with IE6. Here we are, thirteen fucking years later and shit seems to have gotten only MORE complex.
I look at server-side programming for comparison. PHP for instance certainly is more complex with some of the frameworks you can use now and of course composer. But those are WAY simpler than the shit I had to deal with when coding the front. I just don't understand how things have gotten more complex on the front-end, brutal.
It got me thinking about playing around with WebAssembly for building front-end applications. Maybe that doesn't fit all use-cases and maybe the grass is always greener, but I wonder if programming in sane ecosystem would be the sane thing to do...?
Put me in the camp that if there isn't a use-case slapping me in the face, choking me, and yelling at me to do a SPA then I'll avoid the shit like a plague. I'll just go with server-side render pages and sprinkle in some very basic jQuery as needed. I actually did that for a CRM two years ago and the thing is so damn simple to program in, because JavaScript is only used if it ACTUALLY provides a benefit to the user. There is a site-wide script that is maybe 100 lines of code. Then some page-specific things that load in stuff using RequireJS, but the most complex JS out of those is maybe 300 lines. The vast majority of the site doesn't really use much JavaScript. Just plain old MVC.
You would definitly need http/2 to use this, I've tried using imports in vanillajs with supported browsers its sloooooooow. I do wonder whether you could leverage server push for this and whether that would help.
I do all web development without any bundles, it just adds more complexity and dependencies to the application, too many things that can go wrong, too much bloat, possible security issues, etc.
Use cases of front end are getting more and more complex so the tools are as well. One could argue that we are trying to do so much with a platform that offers so little by default. Maybe that's the inherent culprit. Don't know. I really prefer frontend dev to backend (when I started it was all the same really), but I have to admit frontend complexity can scale pretty fast.
The added value of build tools is that javascript are increasingly the assembly of the web and more of a compilation target than something you deal with natively (using the term loosely here since we are talking extensive interpreter and compiler hacks that are needed to make this interpreted language feel fast-ish).
With web assembly maturing, interacting with this mess is becoming increasingly optional. Also languages like typescript and kotlin that compile to javascript add layers of much needed sanity. IMHO any project not using that is doing it wrong at this point. I'm very aware that this is opinionated and even offensive to some but after 2 decades of "maybe this will fix it" type innovation in the javascript world, I have very little patience left for that. The less I'm exposed to that smelly pile of manure, the better IMHO.
So, my recommendation: avoid this tool and use a sensible compile, verify, test, minify, and package it up style tool chain like all the grown ups do these days. I agree, tools for this are very much a cluster-fuck in terms of complexity, lack of any sane defaults that are actually good enough, usability, and performance but they're better than nothing.
In an ideal world, you'd not have to download hundreds of MB of layers of tools around tools that try to fix and work around each other. But there's no good technical reason to skip using them entirely. There's no sane excuse to skip sanity checks, type checks, static code analysis and running tests (and designing such that you can actually do this in a sane way, which seems to be hard with JS). Skipping that is immature and irresponsible. I don't tolerate it in my own projects and have no patience for self styled full stack js ninjas claiming their code is fine. It's not anywhere near fine.
[+] [-] pcr910303|6 years ago|reply
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|6 years ago|reply
Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem:
http://tinselcity.net/whys/packers
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-javascr...
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.)
[+] [-] Zelphyr|6 years ago|reply
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.
[+] [-] GiorgioG|6 years ago|reply
Death to complexity on the frontend for complexity's sake.
[+] [-] jamil7|6 years ago|reply
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.
[+] [-] mnm1|6 years ago|reply
[+] [-] hanoz|6 years ago|reply
[+] [-] csomar|6 years ago|reply
- 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.
[+] [-] _pmf_|6 years ago|reply
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-4...
[+] [-] Cthulhu_|6 years ago|reply
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.
[+] [-] grok2|6 years ago|reply
[+] [-] csande17|6 years ago|reply
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?)
[+] [-] amelius|6 years ago|reply
Yes but designing the right abstraction is an artform, and I suppose that these tools haven't yet found it.
[+] [-] NohatCoder|6 years ago|reply
[+] [-] tlrobinson|6 years ago|reply
[+] [-] esjeon|6 years ago|reply
[+] [-] unknown|6 years ago|reply
[deleted]
[+] [-] simplecto|6 years ago|reply
But now this tooling is out of hand. I threw up my hands and found sanity again in simplicity (my username namesake).
It is like war-games. The only winning move is not to play.Now I deploy apps with no more than 100 lines of JS.
Again, not prescriptive, just my own journey.
[+] [-] cr0sh|6 years ago|reply
But I kept getting mired and "stuck" in how I should architect things, or what framework to use, or this or that. I eventually decided that I wanted it to be a browser-based app of some sort (thus the road of ES6) - but then I started to wonder what tooling to use there. Lots of questions, etc - and I never got that far with it.
I eventually wised up and realized that it didn't matter what I chose - what I needed was the application to work. Who cares about frameworks, requirejs, css frameworks, etc - I just wanted something working. So I stepped back...and decided to chuck all of that away.
I ended up with a basic webpage, with a script tag and the code inside that - nothing fancy, purely procedural, old-school javascript functions, tied to events. Bare bones, basic.
...and I made real progress for the first time.
Basically, by regressing to the relative simplicity of Javascript back from the 1990s, I was able to get my tool finally going, without having to worry about the last two decades of cruft around that language. Now, I could have also done it using Python or anything else, in the same manner - but again, I wanted it to be browser based.
As you note, my own journey, and not something I'd tell anyone else to do (and certainly not something meant for a production environment!) - but for myself, and my need, this fit the bill. I'm still working on it; I figure when I complete it proper-like, I can go back and refactor it to something more respectable. Or maybe not.
After all, if it works, why try to break it? In the end, I want the results from the tool - who cares what it looks like under the hood, so long as it works.
[+] [-] bgdkbtv|6 years ago|reply
Laravel NGINX VanillaJS/WebComponents (toying with Svelte right now) MariaDB
Fast prototyping, simple deployment, almost no time spent with tooling.
A recent example with too much tooling I had was with Root's bedrock+trellis+sage. They do make working with WordPress management for a developer (a lot less clicking that with normal WP setup). But the frontend setup, webpack, backend, browserify and all of that is so complicated and slow. I was able to set it up on one machine, but failed to git clone the same project on two others. Scripts would be missing, things wouldn't load etc. Nightmare.
[+] [-] vmsp|6 years ago|reply
[+] [-] ComputerGuru|6 years ago|reply
[+] [-] uncle_j|6 years ago|reply
With regards to tooling I agree it is too complicated. I really wish that everyone would coalesce around a standard set of tools. But it would be the equivalent of cat herding.
[+] [-] robertoandred|6 years ago|reply
[+] [-] brylie|6 years ago|reply
http://dokku.viewdocs.io/dokku/
Dokku also uses(Heroku) buildpacks, which are becoming standardized:
https://buildpacks.io/
[+] [-] rkangel|6 years ago|reply
LiveView is an alternate architecture to intercooler.js but with the same goal. There is a standard JS bundle that goes to the client that opens a websocket to the server. You annotate HTML tags (like intercooler) and then handle the events on the server. This is all abstracted away though so you end up writing a controller that looks a lot like a normal server side rendered page.
[+] [-] brylie|6 years ago|reply
[+] [-] brylie|6 years ago|reply
https://wagtail.io
I have had a great development experience. The Wagtail core team are very active and helpful.
[+] [-] djsumdog|6 years ago|reply
[+] [-] jniedrauer|6 years ago|reply
[+] [-] mstade|6 years ago|reply
> - Anyone who loves tooling-heavy development! This isn’t sarcastic, I promise! By dropping the bundler, you can’t do the magic that Webpack is famous for. Using import to load CSS, Images, and other non-JS resources is non-standard and unsupported in the browser (for now). You may appreciate a dev environment that is true to what standard JavaScript browsers support. Or, you may find this annoying.
---
I like that they make this a point, and I'm very much in the "let's not overload the standards" camp so I appreciate this as a feature, not a bug. This convinces me to give this tool a go!
[+] [-] keyle|6 years ago|reply
But they're missing the point, this is a really good idea.
[+] [-] austincheney|6 years ago|reply
I used to use 1000 NPM packages as a sarcastic example about bad decisions and death by dependency overkill then I installed Angular which pulls in 1100 packages alone. The end user doesn’t care about your framework choice, favorite language, tech stack, or build process. They just know your application is slow, clumsy, and riddled with defects.
[+] [-] simonw|6 years ago|reply
[+] [-] MK_Dev|6 years ago|reply
[+] [-] sdnguyen90|6 years ago|reply
[+] [-] systematical|6 years ago|reply
Webpack certainly is confusing too. I did a side project with some webpack and es6 stuff. It was kinda fun, but man, front-end development has sucked forever. I remember back in the day having to fight with IE6. Here we are, thirteen fucking years later and shit seems to have gotten only MORE complex.
I look at server-side programming for comparison. PHP for instance certainly is more complex with some of the frameworks you can use now and of course composer. But those are WAY simpler than the shit I had to deal with when coding the front. I just don't understand how things have gotten more complex on the front-end, brutal.
It got me thinking about playing around with WebAssembly for building front-end applications. Maybe that doesn't fit all use-cases and maybe the grass is always greener, but I wonder if programming in sane ecosystem would be the sane thing to do...?
Put me in the camp that if there isn't a use-case slapping me in the face, choking me, and yelling at me to do a SPA then I'll avoid the shit like a plague. I'll just go with server-side render pages and sprinkle in some very basic jQuery as needed. I actually did that for a CRM two years ago and the thing is so damn simple to program in, because JavaScript is only used if it ACTUALLY provides a benefit to the user. There is a site-wide script that is maybe 100 lines of code. Then some page-specific things that load in stuff using RequireJS, but the most complex JS out of those is maybe 300 lines. The vast majority of the site doesn't really use much JavaScript. Just plain old MVC.
As always, please BURN YOUR JAVASCRIPT STICKERS.
[+] [-] robertoandred|6 years ago|reply
[+] [-] Aeolun|6 years ago|reply
I can’t count the number of times the solution to a problem we had was described as ‘just add these lines of magic to your webpack config’.
[+] [-] touchpadder|6 years ago|reply
[+] [-] plopz|6 years ago|reply
[+] [-] jijji|6 years ago|reply
[+] [-] progx|6 years ago|reply
[+] [-] rafaelvasco|6 years ago|reply
[+] [-] hqjs|6 years ago|reply
[+] [-] jillesvangurp|6 years ago|reply
With web assembly maturing, interacting with this mess is becoming increasingly optional. Also languages like typescript and kotlin that compile to javascript add layers of much needed sanity. IMHO any project not using that is doing it wrong at this point. I'm very aware that this is opinionated and even offensive to some but after 2 decades of "maybe this will fix it" type innovation in the javascript world, I have very little patience left for that. The less I'm exposed to that smelly pile of manure, the better IMHO.
So, my recommendation: avoid this tool and use a sensible compile, verify, test, minify, and package it up style tool chain like all the grown ups do these days. I agree, tools for this are very much a cluster-fuck in terms of complexity, lack of any sane defaults that are actually good enough, usability, and performance but they're better than nothing.
In an ideal world, you'd not have to download hundreds of MB of layers of tools around tools that try to fix and work around each other. But there's no good technical reason to skip using them entirely. There's no sane excuse to skip sanity checks, type checks, static code analysis and running tests (and designing such that you can actually do this in a sane way, which seems to be hard with JS). Skipping that is immature and irresponsible. I don't tolerate it in my own projects and have no patience for self styled full stack js ninjas claiming their code is fine. It's not anywhere near fine.
[+] [-] muhammadusman|6 years ago|reply
[+] [-] typon|6 years ago|reply
[+] [-] pier25|6 years ago|reply
What about SASS, minification, etc?
[+] [-] ng12|6 years ago|reply