7 ms·

I really enjoyed react when it first came out and there was little fussing with browserify (3-4 years ago). But now this tooling is out of hand. I threw up my

I really enjoyed react when it first came out and there was little fussing with browserify (3-4 years ago). But now this tooling is out of hand. I threw up my hands and found sanity again in simplicity (my username namesake). * Django * jquery * intercoolerjs (https://intercoolerjs.org) * plain old docker 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.

uncle_j 7y ago
That intercoolerjs looks pretty decent. 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 7y ago
Huh? React tooling options have never been simpler. Literally one command and you're ready to go.
- djsumdog 7y ago
  Does it download 200MB of tools? (Seriously asking; I've contributed to some React apps but have made one from scratch never).
  - zdragnar 7y ago
    Create-react-app is pretty heavy, because it includes support for things you may not need or want (css modules, typescript, etc). Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
- Nextgrid 7y ago
  And it pulls hundreds of megabytes of shit behind the scenes with god knows what vulnerabilities & backdoors, the resulting browser bundle is hundreds of kilobytes of crap the browser has to download & parse (instant on a fast machine & internet, less so on a cheap Android device on crappy underground subway Wi-Fi), etc. This complexity is out of hand. The worst is we now use yet more solutions (for example server-side rendering, which now needs its own Node server and it's yet another thing to deploy in addition to your main backend) just to try and dig ourselves out of the hole we dug in the first place. Imagine if we suddenly decided concrete isn't cool anymore and everyone should use duct tape. Given its obvious shortcomings we now waste time trying to make tape work, going as far as making concrete-reinforced duct tape and calling it the best new thing of the day... instead of just using the "uncool" concrete in the first place. This guy has a point, for 90% of projects, you don't need React (those who tell you otherwise are trying to justify their career and position because from my experience most React/Vue front-end positions at companies are pointless and just add unneeded complexity). War story time: a client was building a complex financial product (includes real-time automated trading, etc). The backend was finished but we couldn't test it because despit several months months the React front-end still wasn't ready and days were wasted on basic things like a signup form, displaying the 2FA QR code, user onboarding wizard, etc. Let that sink in for a minute: we could successfully decide when to make transactions worth millions of dollars automatically, but dug a hole so deep on the front-end that we couldn't do basic things that even the first iteration of HTML forms could do just fine 20 years ago. The powers that be didn't want to lose face so they still kept at using that trainwreck of a front-end instead of ripping the whole thing out and rebuilding it using HTML forms in a matter of hours. I didn't stick around to see if they ever finished the project.
  - debaserab2 7y ago
    Just because a new solution is trending doesn't mean you have to figure out how to use it in your tech stack. Evaluate your needs and where it may or may not fit and decide accordingly. > This complexity is out of hand. The worst is we now use yet more solutions (server-side rendering, which now needs its own Node server and it's yet another thing to deploy) just to try and dig ourselves out of the hole we dug in the first place. No, someone had a project that required SSR and for reasons important to their project wanted to build out that functionality in node. You don't have to use it just because it's out there if you find you don't have compelling reasons to apply it to your project. Just because it doesn't fit your project doesn't mean it's useless for everyone else. Your 90% of projects aren't other people's 90% of projects.
- bovermyer 7y ago
  I prefer to just write raw JavaScript, and as little as possible.
bgdkbtv 7y ago
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.
djsumdog 7y ago
Intercooler looks neat. I couldn't find anything on their site about supported browsers though.
- vearwhershuh 7y ago
  It depends on jQuery and if you use history support it will need localStorage, so pretty broad browser support.
cr0sh 7y ago
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.
- alexdeloy 7y ago
  So good to find someone else who went back to the 90ies stack! After playing around with some react/vue/express/angular/younameit apps for various clients I am more than happy to escape the dependency hell and write efficient code in pure JS that load basically instantly and doesn't need a build environment in the first place. The last straw for me was spending over a day trying to find the right versions for node and all the packages involved to at least get a "legacy app" I inherited running. I find that I don't even need jQuery anymore, support for things like closest() or a simple document.querySelector is so good that I save those few kb as well.
vmsp 7y ago
If you're a fan of this type of libs, you should also check out https://stimulusjs.org/ https://stimulusjs.org/ and https://umbrellajs.com/ https://umbrellajs.com/.
- jturpin 7y ago
  These both look cool. I've learned some Vue in the past but I strongly prefer these kinds of small, self contained libraries for my Flask + PicnicCSS + very simple JS apps.
  - brylie 7y ago
    I mentioned this library in a previous comment, but LiteDOM might be interesting to you as it is somewhat similar to Vue: https://litedom.js.org/ https://litedom.js.org/
- ComputerGuru 7y ago
  This is my first time seeing any of these awesome libraries linked here, but for my money I just spent half an hour reading all the intercooler docs and it looks like a winner. I don’t see the benefit of Umbrella over jQuery when you take into account the browser support and libraries available for the latter, and it seems that intercooler is stimulus + turbo links but on steroids.
- brylie 7y ago
  LiteDOM also seems very promising: https://litedom.js.org/ https://litedom.js.org/
ComputerGuru 7y ago
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!
brylie 7y ago
I'm enjoying developing Django apps with Wagtail CMS: https://wagtail.io https://wagtail.io I have had a great development experience. The Wagtail core team are very active and helpful.
brylie 7y ago
Intercooler js looks really cool! Do you have any suggestions for adding transition animations? E.g. to add smooth in/out for AJAX returned content.
- hikefast32 7y ago
  You can use CSS for transition animations. Look for “CSS-Based Indicators” in the docs.
brylie 7y ago
Dokku gets an honorable mention, as it makes deployment as simple as `git push dokku master`: http://dokku.viewdocs.io/dokku/ http://dokku.viewdocs.io/dokku/ Dokku also uses(Heroku) buildpacks, which are becoming standardized: https://buildpacks.io/ https://buildpacks.io/
jniedrauer 7y ago
Ironic that intercoolerjs.org is missing functionality unless you allow scripts from code.jquery.com
- simplecto 7y ago
  Not sure about that. I simply include jquery then intercooler (both loaded from my server) and then it is off to the races...
rkangel 7y ago
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.

uncle_j 7y ago

That intercoolerjs looks pretty decent. 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 7y ago

Huh? React tooling options have never been simpler. Literally one command and you're ready to go.

djsumdog 7y ago
Does it download 200MB of tools? (Seriously asking; I've contributed to some React apps but have made one from scratch never).
- zdragnar 7y ago
  Create-react-app is pretty heavy, because it includes support for things you may not need or want (css modules, typescript, etc). Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
Nextgrid 7y ago
And it pulls hundreds of megabytes of shit behind the scenes with god knows what vulnerabilities & backdoors, the resulting browser bundle is hundreds of kilobytes of crap the browser has to download & parse (instant on a fast machine & internet, less so on a cheap Android device on crappy underground subway Wi-Fi), etc. This complexity is out of hand. The worst is we now use yet more solutions (for example server-side rendering, which now needs its own Node server and it's yet another thing to deploy in addition to your main backend) just to try and dig ourselves out of the hole we dug in the first place. Imagine if we suddenly decided concrete isn't cool anymore and everyone should use duct tape. Given its obvious shortcomings we now waste time trying to make tape work, going as far as making concrete-reinforced duct tape and calling it the best new thing of the day... instead of just using the "uncool" concrete in the first place. This guy has a point, for 90% of projects, you don't need React (those who tell you otherwise are trying to justify their career and position because from my experience most React/Vue front-end positions at companies are pointless and just add unneeded complexity). War story time: a client was building a complex financial product (includes real-time automated trading, etc). The backend was finished but we couldn't test it because despit several months months the React front-end still wasn't ready and days were wasted on basic things like a signup form, displaying the 2FA QR code, user onboarding wizard, etc. Let that sink in for a minute: we could successfully decide when to make transactions worth millions of dollars automatically, but dug a hole so deep on the front-end that we couldn't do basic things that even the first iteration of HTML forms could do just fine 20 years ago. The powers that be didn't want to lose face so they still kept at using that trainwreck of a front-end instead of ripping the whole thing out and rebuilding it using HTML forms in a matter of hours. I didn't stick around to see if they ever finished the project.
- debaserab2 7y ago
  Just because a new solution is trending doesn't mean you have to figure out how to use it in your tech stack. Evaluate your needs and where it may or may not fit and decide accordingly. > This complexity is out of hand. The worst is we now use yet more solutions (server-side rendering, which now needs its own Node server and it's yet another thing to deploy) just to try and dig ourselves out of the hole we dug in the first place. No, someone had a project that required SSR and for reasons important to their project wanted to build out that functionality in node. You don't have to use it just because it's out there if you find you don't have compelling reasons to apply it to your project. Just because it doesn't fit your project doesn't mean it's useless for everyone else. Your 90% of projects aren't other people's 90% of projects.
bovermyer 7y ago
I prefer to just write raw JavaScript, and as little as possible.

bgdkbtv 7y ago

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.

djsumdog 7y ago

Intercooler looks neat. I couldn't find anything on their site about supported browsers though.

vearwhershuh 7y ago
It depends on jQuery and if you use history support it will need localStorage, so pretty broad browser support.

cr0sh 7y ago

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.

alexdeloy 7y ago
So good to find someone else who went back to the 90ies stack! After playing around with some react/vue/express/angular/younameit apps for various clients I am more than happy to escape the dependency hell and write efficient code in pure JS that load basically instantly and doesn't need a build environment in the first place. The last straw for me was spending over a day trying to find the right versions for node and all the packages involved to at least get a "legacy app" I inherited running. I find that I don't even need jQuery anymore, support for things like closest() or a simple document.querySelector is so good that I save those few kb as well.

vmsp 7y ago

If you're a fan of this type of libs, you should also check out https://stimulusjs.org/ https://stimulusjs.org/ and https://umbrellajs.com/ https://umbrellajs.com/.

jturpin 7y ago
These both look cool. I've learned some Vue in the past but I strongly prefer these kinds of small, self contained libraries for my Flask + PicnicCSS + very simple JS apps.
- brylie 7y ago
  I mentioned this library in a previous comment, but LiteDOM might be interesting to you as it is somewhat similar to Vue: https://litedom.js.org/ https://litedom.js.org/
ComputerGuru 7y ago
This is my first time seeing any of these awesome libraries linked here, but for my money I just spent half an hour reading all the intercooler docs and it looks like a winner. I don’t see the benefit of Umbrella over jQuery when you take into account the browser support and libraries available for the latter, and it seems that intercooler is stimulus + turbo links but on steroids.
brylie 7y ago
LiteDOM also seems very promising: https://litedom.js.org/ https://litedom.js.org/

ComputerGuru 7y ago

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!

brylie 7y ago

I'm enjoying developing Django apps with Wagtail CMS: https://wagtail.io https://wagtail.io I have had a great development experience. The Wagtail core team are very active and helpful.

brylie 7y ago

Intercooler js looks really cool! Do you have any suggestions for adding transition animations? E.g. to add smooth in/out for AJAX returned content.

hikefast32 7y ago
You can use CSS for transition animations. Look for “CSS-Based Indicators” in the docs.

brylie 7y ago

Dokku gets an honorable mention, as it makes deployment as simple as `git push dokku master`: http://dokku.viewdocs.io/dokku/ http://dokku.viewdocs.io/dokku/ Dokku also uses(Heroku) buildpacks, which are becoming standardized: https://buildpacks.io/ https://buildpacks.io/

jniedrauer 7y ago

Ironic that intercoolerjs.org is missing functionality unless you allow scripts from code.jquery.com

simplecto 7y ago
Not sure about that. I simply include jquery then intercooler (both loaded from my server) and then it is off to the races...

rkangel 7y ago

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.