I don't. I'm way more productive with a lighter stack.
I stick to plain Javascript. Sometimes I add a lightweight framework like Vue that I can simply include.
Are there more of us out there?
I don't. I'm way more productive with a lighter stack.
I stick to plain Javascript. Sometimes I add a lightweight framework like Vue that I can simply include.
Are there more of us out there?
I suppose can probably get away with plain, unprocessed JS files for small personal projects, but that seems rather difficult to maintain for anything serious.
Look at a single post on the new React based Reddit. I just did and got 65 http requests loading 1.6MB of data.
It's almost everywhere like that these days. Too much tools. Too little concern for the actual outcome.
If you're good enough to be conservative in what you pull in, you'll still be that, except you get to benefit from all the things a compilation step can offer. It still strikes me as a somewhat arbitrary limitation to impose on yourself.
I use webpack for almost all my projects, and TypeScript for a bunch of them. I'm also very mindful of what packages I use and the result is nice little bundle. I wouldn't be able to get the results I want if I limited myself by not having a compilation step.
(I know full well why they want people to the install the app, but I still find it unfortunate that they a) don't remember that I dismiss it/have an option to never ask me and b) despite the redesign and having a relatively good mobile experience (assuming you didn't first hit an `amp.` link) still push the app.
Edit:I will grant you that our business is processing-heavy, so the ratio of client JS to backend language is very low.
When building a highly interactive e-banking front end application, you may want to use some complex framework. For a mostly static website with some show/hide-toggleable areas, plain JS or jQuery is probably easier and quicker to use.
Not sure why I do it this way. For some irrational reason, I just don't like modern web tools. I don't use LESS/SASS either, prefering LASS (S-expressions -> CSS compiler library) in Common Lisp projects, and raw CSS otherwise. Part of the reason might be that I just miss the days when you could learn from "View Source" in your browser. A different part might be is that I don't understand why modern compilation to JS requires downloading many dozens of megabytes in hundreds of Node dependencies. That's just ridiculous.
It's true that many people who use, say, webpack will also just indiscriminately use heavy packages, complicated SASS/LESS setups, and whatnot.
But that doesn't mean that using webpack means you have to do the other things. It's possible to use webpack and various other 'fancy' stuff without going crazy on the packages, and with sourcemaps you still get to 'view source'.
Personally I find that the benefits of at least some degree of compilation are well worth the potential drawbacks. I am quite conservative in pulling in packages, I regularly use tools that show me visually which things increase the size of my payload, and the result is pretty nice. I can't imagine going back to using multiple script tags to include multiple js files.
EDIT: I'll add that I do understand wanting to avoid all this. It probably does take a bunch of domain-specific knowledge to know what to do and not to do, and I myself have also been trying to avoid much of it by moving to the back-end.
And you don't need a bundler and hot-reloading. Just stick to JS modules, output JS modules and let the browser take care of it.
You can also run 'tsc -w' (watch mode) and it will automatically recompile as soon as files change. And since doing so maintains a local cache of the compiler's state in memory it's extremely fast.
The tiny amount of time I spend waiting for compiles is several orders of magnitude less than when I had to deal with the lack of static typing, particularly when refactoring code.
It reminds me of the smell of supporting IE6.
My apps are all designed to run on the latest browsers. Maybe I am lucky this way, but I don't have to support browsers older than a few months for my key systems.
Not sure about the OP, but for me, I've been around for almost 20 years on web dev front end stuff, and every time I review a compiler, a while later a new one comes along. And eventually every compiler I have tested/or reviewed is now out of style, or the version I tested had so many bugs, or NOW the default configs are perfect! bah. Burnt way too many times on this. I use absolutely minimal external libraries, and those that are, are already minimized.
Eventually, when my systems get more wider spread and more devs involved, I think a build step for staging then to production will be useful though.
(note, we do have a build step, it just doesn't use any front end compilers like webpack/babel)
I definitely agree with being more productive with a lighter stack, but I do find the even though TS is slower to develop due to compiling, the quality of the code is usually better (especially with multiple people on a project).
It isn't just about having a compilation process or something, but it's about the fact that a good type system (even like that of TypeScript) is like getting the compiler to do a lot of error checking for you without having to write the unit tests for it.
But if the project itself is so small that you don't care about writing unit tests, then sure fine use vanilla JS.
You may already be aware of this, but you can set up the same workflow for frontend development (if you have a compilation step). "Watch mode" seems to be the popular nomenclature for this in the JavaScript community.