In my opinion the cost of setting up a compiler such as typescript ot babel is significantly lower than the benefit and organization that types, modules, and modern language features provide.

agreed. being able to rename a property with confidence is worth the setup time in and of itself, let alone all of the other benefits it brings along.

Even if you don't use TypeScript, don't you still need a precompilation step for minimizing your source files?

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.

I do maintain pretty big projects this way. Even though the js is not minimized, it is way smaller then what the competition uses. Companies these days throw together insane amounts of bloated code for no reason.

Do you reference all your source files separately with script tags?

Yes. And again, we usually do way less http requests then the competition.

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.

While I do agree that your approach leads to good result, I still don't see why you wouldn't add a compilation step to minimize/tree shake/TypeScript/etc.

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.

The new reddit is also a better experience than the old reddit, so there's that

And to expand upon pjc50's comment, the mobile experience still pushes the app, even though I'm logged in and always dismiss it.

(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.

And by better you mean worse? I second 'pjc50 here - new Reddit is slow on both mobile and PC, inefficient to read (wastes a lot of space), has questionable interactions thanks to JS abuse, and generally turns what was a condensed link aggregator into a poor Facebook clone.

Not in my experience - it's terribly slow on mobile, still fairly slow on desktop, and wastes huge amounts of space.

Ironically it's more robust than most of sites I see on the internet.

Wow, I've never heard anyone express that opinion before. Even my wife (a non-technical user) hates the new design.

Same here. We have 140k monthly active users. Just using unminified JavaScript and script tags to include other JS files. Most just because I wrote it and I'm a backend engineer.

Same here. We have 1.5 million monthly active users. Still using unminified JavaScript.

I developed a 500.000 line js front-end without a build step (only a minifier/bundler for production releases, nothing in dev). We did have an on-demand loader to bring in modules as needed. It’s definitely doable though I do prefer to use typescript myself for large codebases.

Well it really depends on the size of the project. For small project I agree but for larger projects Typescript really helps to produce better and more robust code (and also faster if it's well integrated into the editor like VS Code). I am currently rewriting a Firefox Extension in Typescript that started as a simple script and grew in complexity (quite a bit) to make it easier for others to contribute (it's open source) and understand the code and I wish I had started that way, it would have saved me quite a bit of work by now.

Lordy, what? Webpack + hot reload makes the "compilation" step almost invisible / equivalent. I'm assuming this is just a troll comment.

So this is this week's recommendation? Last I checked it was grunt, or gulp, or something like that. I am forced to dabble with Node from time to time, and the effort to track what's this week's build chain is already too mentally taxing for me.

FWIW I mostly run terminal commands defined in package.json. I agree that keeping track of the fancy build tool du jour is best avoided, if possible.

I've used react-scripts for a few months. I have no idea how old it is, but it's pretty good. Maybe automatic reload isn't always working, but I can just reload the whole page if something is off and it's instantaneous.

These days it's easy to type into google "typescript starter" thanks to the excellent work of other people, which will inevitably include automatic reloading. You get better code pretty much for free.

I'm not trusting those starters will remain up to "modern standards" for longer than couple of months.

To each their own, but I question the scale/stability of your work without participating in the world of JS compilation (and the subsequent benefits).

The only valid question of scale/stability is whether or not it scales/remains stable. I've personally achieved a couple million ARR with unminified, uncompiled javascript on the client.

Edit:I will grant you that our business is processing-heavy, so the ratio of client JS to backend language is very low.

IMHO, it depends on what you're going to build. The bigger your application, the more you profit from features like static typing or automated tests.

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.

Count me in. I don't touch frontend if I can avoid it, and if I can't, I sometimes have to work with compiling to JS and bloated node-based stacks. But when I write any JS for myself, I tend to do it pure, with files delivered to the browser as written (no minification, no obfuscation).

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.

I'd say it's mostly irrational, but I do sort of get the feeling.

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.

I'd love to read a guide into modern web that focused on establishing a leanest possible solid foundation for further work. Like, "this is the minimum setup to get minification of your JS and CSS; add this to get auto-refresh on file change; ...". Everything I've read so far jumps straight into downloading hundreds of megabytes of NPM modules. I just don't feel comfortable with all that code doing God knows what, God knows why.

Yeah, agreed. It's definitely true that going down the Webpack/compilation road sort of automatically sends you down a path of heavy, complicated solutions. Maybe what you describe could be something I could finally decide to blog about :).

For the sake of all that's beautiful in this world, please do.

I like this one when it comes to avoiding Gulp/grunt and the like: https://css-tricks.com/why-npm-scripts/

I’m genuinely curious: Why are you not okay with the compilation step? I work primarily as a developer using compiled languages so I may be missing something.

There are many aspects to it. From setting up a new project to 'edit a line and reload in the browser'. Everything feels so much faster, lighter, fresher.

I'm one of many who don't seem to understand your point of view. how would editing and reloading be faster than hot reloading? I usually edit my styling live in Sublime while viewing the changes in Chrome.

Styling?

I usually write down styles to some kind of Notepad and then rewrite it to sass. At the beginning it was annoying, because I was forgetting that my css will be reloaded, but I got used to it.

yep, as in style sheets. personally I prefer Sass before native CSS, so I usually use the broader term to avoid assumptions about the technology stack used.

tsc --watch is incredibly fast.

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.

But when you use a tool like webpack it's even simpler - you just save your file and it recompiles & reloads.

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.

Fast REPL cycle.

Legit question, what don't you like about it and why?

I am moving into ES6 modules and the very notion of trying to use Babel or other post compiler to support older code styles seems archaic.

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 use the native modules more and more too. They are awesome.

Well when you say “I” do you mean that you work alone? I find when I do, I do not need type systems, safety checks, etc. to understand the code, but if I need to review others code them having type annotations replaces the documentation that they didnt write.

For me, it depends on the project. I try to stick to JS for smaller, simpler projects, but anything large (or with potential to become large) I use TS. I've worked on some very large JS projects over the years and in my opinion it's really difficult to for a JS codebase to scale well.

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).

Typescript is a boon to large projects.

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.

Yep. Same here. I'm not against compilation step. I have projects with compilation. But projects with minimal dependence work as well. E.g. the Firefox extension Tip Tab and Session Boss are moderate complex SPA, and I just used plain JavaScript, JQuery, and a small CSS framework to build them. Work very well.

If you've made the right choice for your workflow and project type then you'll never be alone.

there are dozens of us

Do you use an IDE?

No.

So presumably you write all your non-web stuff in machine code? Compilers are pretty common.

What ? Interpreters are pretty common in the non-web world too…

Server side code is different as the server usually starts an interpreter that compiles the file on-the-fly in case it changed since the last pageview.

> the server usually starts an interpreter that compiles the file on-the-fly

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.

In production? I think I'm misreading your comments.

Not all people do code anything else than JS web stuff these days.

For smaller projects - sure, but for anything bigger than that it will take more time fiddling with JavaScript quirks then just use a preprocessor. Like with css compared to sass, I can’t imagine myself writing plain css anymore for any big project, it’s a nightmare to maintain and edit

Plain CSS has actaully come a long way since SASS was first introduced. The only reason to use SASS nowadays is for their color functions (which is still a big reason unfortunately).