Is TypeScript a fad or is my manager delusional?

If TypeScript still is a fad at this point, his definition of fad is far lengthier than mine is.
I'm fairly sure TypeScript will remain in popular use longer than whatever project you're working on 😅

As long as JavaScript is being used, TypeScript will be used. It makes writing JavaScript tolerable.
- Imo they'll add typing to vanilla js, which will kill ts.
  
  And the ts devs support this
  
  And also JS.
  Well "kill" is perhaps a strong word but it definitely won't be JS anymore at that point. The changes required to bake in strong type support would be radical.
  
  That would be a great solution, because while I love Typescript, I hate compiled web code. One of the coolest things about the internet is that as it's supposed to work, you can download the source code for any website you go to. It's open source by design. I hate closed source websites and I hate compiled website code that helps close the source it's quite a contradiction because typescript is awesome and I recognise that compilation is the only way to get it to run on our web infrastructure. So it would be great if we could just type JavaScript and solve the contradiction that way.
  
  the can’t add proper typing without adding a compiler. Whatever they add will be closer to puthon’s type hints. I’ve had to write primary in python lately and type hints help very very slightly, and tools like pyright catch so many false errors due to lack of hints in libraries that we’re forced to add ignore statements on too many lines. I genuinely don’t understand how there can be so many languages and all of them be painful to use

TypeScript might not be here to stay, but typed JavaScript definitely is. I’ve switched to writing 100% TypeScript, and haven’t looked back. The fact that just adding types to one of my (admittedly more complex) libraries surfaced 3 unknown bugs was eye opening to me.

CoffeeScript was a fad, but TypeScript seems to gaining more and more popularity these days, with new runtimes like deno supporting them natively. TypeScript finally gave Microsoft relevancy again in webdev world, so I bet they'll go a great length to make sure it stays that way. If Microsoft were still making their own browser engine, I bet they'll make it natively supports TypeScript too.
- CoffeeScript was a fad because it didn’t solve anyone’s problems. It was basically “look how cool code you can write”.
  TypeScript is gaining popularity because static typing solves real problems. It’s also a superset of JavaScript instead of being a completely new language from scratch, which makes it easier for JavaScript devs to learn.
  
  it felt to me like coffeescript solved problems that people had, then js got equivalent features. arguably that could happen to ts as well
- CoffeeScript wasn't a fad, it just became obsolete because JS adopted the syntax sugar CoffeeScript was selling. In a way, it did its job.
  
  Yup! All of the following features were in CoffeeScript first: Modules, classes, arrow functions, async functions, parameter defaults, ...spread, destructuring, template strings.
  So I'd say it was extremely successful in making JavaScript better.
  
  So it was Kotlin before Kotlin

Static typing, for the win, and I'll die on this hill.
Fight me.

A fad? No, definitely not. TypeScript brings features (and structure) that will /should probably make their way into JS.
It's sort of like asking, "does SASS replace CSS" or "is liquid the next HTML?" They're just implementations of features FE developers want in the core spec of JS, CSS, and HTML.
- that will /should probably make their way into JS.
  Not really, IMHO. The main advantage of TS is that it will help you catch errors without having to run a particular piece of code - i.e. you won't have to move to the third page of some multi-page form to discover a particular bug. In other words, it helps you catch bugs before your code even reaches your browser, so it doesn't bring you much to have them in the browser.
  (There is a proposal to allow running TS in the browser, which would be nice, but you'd still run a type checker separately to actually catch the bugs.)
  
  I think the important part is that the syntax will become standardised, rather than being defined by microsoft/typescript, potentially allowing for alternative implementations. It could also make the build step optional in some cases, which is something people dislike about typescript currently.
- Hoping this is true. The biggest annoyance with typescript is needing some kind of compiler. Haven't used Bun or Deno very much, both of which natively support TS, but there are still incompatibilities with the way Node does things and how certain modules were built (CommonJS vs ESM). I like writing JavaScript but the tooling is utter crap.

5 years ago everything was moving to TypeScript. Now everything has moved. Developers are still catching up, but it will be one-way traffic from here.
I'm guessing your manager thinks TypeScript is like CoffeeScript. It is not like CoffeeScript.
Also, TypeScript is only the beginning. In the halls of the tech giants most devs view TypeScript as a sticking plaster until things can be moved to webassembly. It will be a long time until that makes any dent in JS, but it will also be one-way traffic when it does.
- Developers are still catching up, but it will be one-way traffic from here.
  Honestly I disagree, maybe I exist in a bit of an echo chamber, but it seems like since around ES2020 or so (some) people have been transitioning from TS to write JS with JSDoc and modern JS style rules.
  I've basically transitioned to Go for work(where I can), but don't really mind writing modern JS

Typescript makes writing Javascript a reasonable thing to do. Your manager is a fad.
- Your manager is a fad.
  If only...

No, because raw-dogging JavaScript isn't something grown-up software shops do.
- [Object object] would like a word
- Can't they just use JSDoc?

Javascript is a fad, we should all move to WASM. 🙃
But no, TypeScript is not a fad. Unless a better "Typescript like" thing comes out - I know how in frontend land people like to make their own substitute framework that does something slightly different than an existing framework - But I don't really see why anyone would want to make a NewTypeScript, and not just expand existing TypeScript

When anyone in a professional setting says they don't like having a mega corp supporting something I lose a bit of respect for their opinion tbh.
Yes we all know mega corps suck.
But if you're using anything in a professional production environment that is meant to last in the long term this is 100% what you want.
- Some of us are old enough to remember the browser wars and EEE, so I definitely understands not wanting to be sucked into some mega corps eco system with future lock-ins. Often you can't do anyhhing else, but that doesn't mean it doesn't suck.
  
  Same. Writing sites that relied on IE was always a stupid decision and kinda invalidated the point of writing a web app.
  I think most people knew that and the managers fucked up big time pushing it. At least in my experience.
  But that's very different to choosing a programming language.
- I mean it is fair to say sometimes it depends on the mega corp, if the whole thing relies on one corp if they're funding dries up then the whole project dies. But I also don't really think typescript would die without Microsoft now

No. Dynamic typing, though, is absolutely a fad.
- Dynamic typing is not a fad.
  Python is older than Java, older than me. It is still going strong.
  
  Python also has a statically typed option these days.
  Edit: Previously said "strongly" instead of "statically"
  
  This just blew my mind. I had always assumed Java was older. I started writing hobby projects in Java in the 90s. I don't think I heard about Python until the early 2000s.
  
  "Strong"... how many actual projects run on python?
  Half of the internet ( backend) runs on java, banking, your government systems, etc.
  It's not a fad, it's just unusable for anything other than research project and small time scripting, which to be fair, it's what it's designed for.
- It might not be a fad, but it's definitely a local maximum and/or a limitation that many devs seem to be stuck with.

Hi, I've been doing TypeScript in my day-job and hobbies for six and a bit years now. I would not write JS in any other way.
TS is also a superset of JS so all JS is valid (unless you turn on strict mode). So there is no productivity loss/learning curve unless you want there to be.
In fact, a lot of people who think they're not using typescript are using it because their editors use typescript definitions for autocomplete and JSDoc type signatures are powered by typescript.
- So there is no productivity loss/learning curve unless you want there to be.
  It's not significant but an extra build step can be annoying

I'll riot if I ever need to write pure js again. 98% of web devs would be better served writing in TS. If you're actually knowledgeable enough to write more efficient js, more power to you but honestly I was probably being generous saying 2% of web devs fall into that category.
- Even then, it just leaves behind an illegible mess that the next dev has to gut and replace with typescript later. If someone wants to use JS on their hobby project, go for it. The extra tools that types enable are super valuable for a team.

I believe both are true... and I also develop a LOT in Angular (with TypeScript).
TypeScript is great but the thing is that if you look at the history of TypeScript and JS/ECMAScript you'll find out that TypeScript sometimes is the testing ground for the future features of ECMAScript - pretty much like what happens with Sass and CSS that how even has nesting and scopes.
The issue with TypeScript/Sass etc. is that it requires a compiler and that's totally obnoxious and completely defeats the point of having interpreted code on browsers. Depending on the project it might be better to go for TypeScript + Angular/React or other compiled solution or simply something vanilla with jQuery or the Vue runtime (no compilation) and other libraries.
If TypeScript ever goes away the underlaying features that make it great will be implemented in ECMAScript in the same way that we got modules, classes etc. and I really hope it happens. Less compilation usually equals code more maintainable in the long run because you won't require hundreds of dependencies (that will eventually break) to get it to compile.
- The issue with TypeScript/Sass etc. is that it requires a compiler and that’s totally obnoxious and completely defeats the point of having interpreted code on browsers.
  Shouldn't WebAssembly be a solution to this? I.e. so you don't have to interpret code but rather run the wasm binary (which is kinda interpretation as well but you get what I mean).
  
  I love seeing webassembly getting traction because it enable cool stuff never thought possible before running in web browsers. But webassembly is a blackbox that can't be tinkered with by end users. I dread the day webassembly become so widely used that average websites run under webassembly because that would be the end of blocking ads or tweaking websites behavior with greasemonkey scripts.
  
  That's not a solution, it is the exact opposite - adding even more compilation and complexity to things. The ideia is to move away from compiled stuff as much as possible. WebAssembly makes sense for very complex and low level stuff that you can't run interpreted with reasonable performance.
  Less compilation usually equals code more maintainable in the long run. Think about it: if you don't need a compiler and the hundreds of dependencies that will eventually break things will last way more time. Websites from the 90's still work fine on modern browsers and you can update them easily while compiled stuff is game over once you lose the ability to install run said compiler and related dependencies.
- TypeScript sometimes is the testing ground for the future features of ECMAScript
  They have an explicit policy to only include features that are stage 3 already (i.e. that are pretty much certain to land in the language as-is). The only times they've diverged from this is long in the past (I think enum is the main remnant of that, for which I'd recommend using unions of literal string types instead), and experimentalDecorators under pressure from Angular - which has always been behind a flag explicitly named experimental.
  So I really wouldn't worry too much about that.
  
  Oh I’m not worried, at all.

I hope not. I'm pretty sure me and my coworkers would be at each others' throats if it were not for some form of typed JS holding our Frankenstein codebase together.

Imagine changing your file extension from .js to .ts and calling it a fad. JS is TS. The difference is that TS does more (by actually doing stuff before runtime as a static analyzer, similar to eslint). If TS is a fad, then modern web dev is a fad.
Which, to be fair, it is.

Typescript is the only way I can agree to code in Javascript. And the only way you can have a sane project without writing double or triple the amount if unit tests for each function just to check things that a compiler would do. However it is absolutely a lipstick on a pig thing with confusing behavior sometimes, but that’s because the underlying language it is trying to make bearable is bonkers

Technicalities aside, TS is being pushed by MSFT in their SaaS custom components, and that right there will keep it relevant a while. MSFT is known for changing names a lot, but not for killing technologies.
After over 5 years of writing TS, I have had to do plain JS sometimes, and it is scary. It feels like walking blindfold. I'm spoiled.
- MSFT is known for changing names a lot, but not for killing technologies.
  Silverlight would like a word ;)

I don't think it's going away until ECMA supports native types. Until then it's the best game in town.
If a team decides to move away from it, it's only few hours work to entirely remove. So even if it's going away, it's risk free until then.
But I cannot imagine why any team would elect to remove Typescript without moving to something else similar. Unless it's just a personal preference by the developers who aren't willing to learn it. It removes so many issues and bugs. It makes refactoring possible again. I think teams that want to remove all types are nostalgic, like a woodworker who wants to use hand tools instead of power tools. It's perfectly fine, and for some jobs it's better. But it's not the most efficient use of a team to build a house.

A language that helps me write Javascript without writing Javascript? Nah, that ain't no fad, that's a grace from whatever god is up there.
- You should check out Google Web toolkit, totally signs like your kind of thing.
  Typescript is for people who hate JavaScript, for the most part. The bulk of the people who have been writing JavaScript for years and aren't Java converts are still using JavaScript and will continue to do so. The Java developers will continue writing Java, no matter what language they are programming in.
  
  Thank you for the suggestion. I'll check that out. I'm actually only writing TS temporarily for work. I'm going back to C# in a couple of weeks.

Javascript is a fad.
Reject web dev; return to native.
- I strongly disagree with this, web dev is great because you can serve hundreds of different devices with the same code, I can't imagine developing native solutions to each one, yikes

What's the point of calling something a "fad"? If the technology works well and it provides value to you, why should you care what other people think?
(Example: Look at PHP)
- The point of calling something is fad is a way to tell you that you shouldn't invest a lot of time into this because that knowledge will become obsolete soon.
  I mean this is particularly relevant in the JS world because every week there's a new revolutionary framework that renders the previous framework obsolete. (Although, not sure if that's slowing down now...)
- Unfortunately when it comes to my manager, I can't just ignore what he says as his opinions actually has an influence on what technology we use and such.

Your manager is an idiot.
- They already said he is a manager, no need to repeat

In a small company with a non-complex product, there is a chance that TS creates more slowdowns than not.
In a large company with multiple cooks in the kitchen and a complex product, I'm personally of the mindset that there is substantial gain from typescript. I've had coworkers tell me it's bullshit, and then I do the smallest lift possible to convert and the amount of bugs it reveals are insane.
Is it necessary? No, probably not. But unless everyone's a 10/10 dev working on the world's simplest product, why not just do it and enjoy the benefits?
INB4 JavaScript blahblah, yeah I've added type hints to pure JS projects too and discovered bugs. At this point I don't get it. Typical resistance I get is that it's too prescriptive and lacks JS's dynamic nature - well, fuck off, I don't want to read through 200+ lines of code where you're changing types and shit on me willy-nilly.

after reading the title I thought he'd suggest something better than TS would take its place, but going back to JS? nah

Based solely on gut feel, I think Typescript will become less popular as Wasm grows
- When will Wasm grow, according to your gut? I feel like I've been waiting for a decade now.
  
  WASM made huge strides last year. You can run entire operating systems inside a WASM hypervisor now, and lots of packaging and transpiling projects came of age last year.
  Example: https://copy.sh/v86/?profile=windows98
  
  By saying gut feeling I hope I am being clear I have zero tangible evidence? 😅
  Maybe over the next decade its usage will grow? Or maybe it will end up relegated to performance critical applications, or JS/TS just end up with the same/better performance anyway.
  
  The next step is to implement things like this:
  https://github.com/WebAssembly/tool-conventions/blob/main/Coredump.md
  After that, all we need is a rich ecosystem of libraries in other languages. It's still a fair way off, but it's coming.
- I think you've got a point here, in that the sort of Devs who want to be able to refactor their code without breaking everything are also going to be the group who lean more into having code that actually runs quite fast; but given that reasonML is awesome and didn't get much mindshare my position here is that wasm will only start to eat into tyspecript's lunch well after a huge subset of TS can be compiled to wasm (or maybe python ((I blame the xkcd guy for python's unreasonable popularity, I feel it's hugely overrated))).

I don't see it dying from my perspective. Its only been getting better and better. The only thing I could see displacing it in my org is maybe Rust due to WASM proving a transition path.
We use TS on the back end to leverage our teams existing skill set and libraries we've built up.
I know it's a meme to use "the next best thing" in the ecosystem, but we've been really happy with the newish Effect library + Bun runtime. Effect is like a merger of the older fp-ts/io-ts libraries (same author works on both) with Zio from the Scala ecosystem. It vastly simplifies the former and the new stuff with dependency injection and defect management is refreshing. With the Bun runtime, we see a 15x faster startup time (great for dev). Its halved the RAM requirements in prod. We don't even need to transpile... We still do for prod to tree-shake dev-only code to ensure its not available in prod, but deploying to dev is FAST.
- 20 years into the future, once WASM has been widely adopted, a browser within a browser will have been created, with its own equivalent javascript, which will then lead developers to create a WASM equivalent for a web browser running in a WASM browser, running on a bloated OS.
- We use TS on the back end to leverage our teams existing skill set and libraries we've built up.
  I know you said this, but I'm still curious why not just something like Go, which I was able to basically learn in 3 days- just coming from a mostly JS and C++ background
  
  I'm coming from a Haskell/Scala background. This job just pays more. TS has been "good enough" for types. I don't think I could be as effective without them at this point.
  
  As a Go dev, its simplicity is arguably taken too far. For example there are no union types or proper enums

Wow, he's living in 2012 or whatever. A true time traveler.

Id rather quit than go back to pure JavaScript.
- But it's so sexy. Strongly typed language? *Scoff

I'm not a FE guy so don't write it much, but I'd always rather use typescript if I had to use anything like JS. Our FE guys use typescript at my current job and my previous one as well

The developer of Svelte moved from Typescript to JSDoc and explained in depth in an interview (you can find it on youtube). ECMA (the dudes making Javascript/ECMAscript) also started noticing that maybe static typing would be useful and there's a proposal to add typing to it. Whether that's moving forward or not, no idea, but if it were to come to vanillaJS, it's imaginable that typescript would be much less useful than it is now.
CC BY-NC-SA 4.0

- Unpopular opinion perhaps, but I rather have a language that allows me to implement hacky solutions than one that requires me to completely scrap and rearchitect everything.
  I for example once had to overwrite a dozen or so of prototype methods in a JS class because the library a we were using just fell apart when doing certain things inside a Shadow DOM - it was a library that was released long before that feature. And completely rewriting huge chunks of code that interacted with that library would have wasted 100s of hours and the end result might have been really akward as well since many other systems are architected around how that one library worked. So instead it was a matter of patching in a few checks and workarounds for shadow dom elements.
  And since its extremely well documented why we decided to to that, what these hacks do I don't see an issue with that. Obviously this shouldn't be the modus operandi everytime but its always good to have the option i.m.o. to dig yourself out of a hole.
  
  I would argue that overriding methods on a prototype is not a hack. It's equivalent to overriding super methods in Java classes, but using javascript's prototype-based inheritance instead of class-based inheritance.
  But I agree with your main point about choosing a language that lets the developer implement their solutions freely.

JavaScript will implement the things that work out in TypeScript. So… yes and no?

Personally I'd rather use JSDoc in my own projects for type annotations and call it a day. I find TS a bit annoying but that might be because I'm not that familiar with it.
- That's just Typescript with extra steps.
  Though I have also done this once or twice for single-file projects where I didn't want to deal with actually running tsc. It has some annoying downsides though, e.g. you don't get to have a tsconfig.json and the syntax sucks.
  Microsoft had a proposal to allow TS annotations in JavaScript which would have been awesome and fixed the syntax issue.
  Looks like it was discussed a year ago and hasn't really made much progress. Seems like lots of people wanting to shoehorn runtime type checking onto it.
  
  Is it? I just have it auto-generate in my IDE with snippets. If I was using TS I would still document using TSDoc anyway. You can use jsconfig.json instead.

Have you tried slapping your manager?

TypeScript is the new DOC format.
Create a language/format. Spend all of your effort making it ubiquitous until it becomes the default "standard" in the workplace. Then charge a metric fuck-tonne for the "official" software that makes use of it.
It's how Office became their cash cow. They create the proprietary doc format, get everyone using it, and once it's embedded in the workplace, charge exorbitantly for the software that uses it.
Once they get everyone using TS as a new industry standard, they'll find a way to make people have to pay for it. Mark my words.
- I honestly think this is fearmongering. Yes, Microsoft is a shitty company that has done shitty things, but:
  the Typescript repo is licensed with Apache 2.0, which means the community can always fork it if they do bad/evil stuff
  there are competing type checkers in the works, which would fully remove any Microsoft influence from a developer using Typescript
  there already are competing compilers which are broadly used
  The only real option they have to do what you're describing is to implement new features that could be used for monetizing it - there would be some inertia regarding community forks. But even then I can't come up with any monetization model that could make sense. Do you have a specific example in mind?
  
  I hope you're right. But my trust level for corporations is somewhere between 0 and 0.1

The only valid argument against typescript is that it is too similar to vanilla JavaScript. It does not go far enough. We need type systems like Ocaml's.
I suppose you can also complain about needing a build step, but I find this silly. There are so many tools that make this easy or automatic.
- What's so special about Ocaml's type system?
  
  I won't remember everything, but one very important things comes to mind:
  in Typescript, it is very difficult to assert on a type (let me know if you're not familiar with what I mean by this and I can explain further). In OCaml, this is trivial using pattern matching.
  Why would you need that? The idea of a type system is it doesn't let you apply a function on a structure without the structure being of the right type. But the lack of type assertion in TS makes people follow hacky workarounds, which defeat the purpose of type system.
  There are a couple of other things, like immutable types by default, automatic tail call optimization, functors enabling higher kinded types, etc.
  Also in ocaml, you don't have to annotate any types on any variable or parameter, and you'll still get full type protection.

I don’t think your manager is sane.
Why on earth would we move back to JavaScript at this point.
Disclosure: I am a TypeScript dev and my boss is fully invested in Microsoft at this point. We use C# .Net and we use Azure and Teams.

If JavaScript implements type safety then I believe it will go away. If not then it will continue to be used.

He might've watched this video: https://youtu.be/5ChkQKUzDCs
TL;DR: Big projects, like Svelte, Drizzle and Turbo ditched TypeScript

Wait until they realise its pointless…

For me, personally, yep; 100%. I've tried at least 3 times to convert, it just gets in my way. I'm way way faster with plain old JS. But I'm also a Rubyist so it is all ducks anyway.

I don't really get the appeal of strongly typed languages. Can't you just use try/catch blocks, and/or use functional programming and return early if the data structure of whatever you're working with isn't what you expected?
I guess it can help older code easier to maintain because the expected data structure is right there, but you could also just include it in a comment above the function.
I personally find TS slows down initial production of a project and raises so many unnecessary errors.
Is there some huge benefit that I'm missing? Because I don't really get the appeal. I mean, I do on some level, but I don't really understand why so many people are absolutely obsessed with TS.
- Is there some huge benefit that I’m missing?
  For example I recently fixed a bug where a function would return an integer 99.9999% of the time, but the other 0.0001% returned a float. The actual value came from a HTTP request, so it started out as a string and the code was relying on dynamic typing to convert that string to a type that could be operated on with math.
  In testing, the code only ever encountered integer values. About two years later, I discovered customer credit cards were charged the wrong amount of money if it was a float value. There was no exception, there was nothing visible in the user interface, it just charged the card the wrong amount.
  Thankfully I'm experienced enough to have seen errors like this before - and I had code in place comparing the actual amount charged to the amount on the customer invoice... and that code did throw an exception. But still, it took two years for the first exception to be thrown, and then about a week for me to prioritise the issue, track down the line of code that was broken, and deploy a fix.
  In a strongly typed language, my IDE would have flagged the line of code in red as I was typing it, I would've been like "oh... right" and fixed it in two seconds.
  Yes — there are times when typing is a bit of a headache and requires extra busywork casting values and such. But that is more than made up for by time saved fixing mistakes as you write code instead of fixing mistakes after they happen in production.
  Having said that, I don't use TypeScript, because I think it's only recently become a mature enough to be a good choice... and WASM is so close to being in the same state which will allow me to use even better typed languages. Ones that were designed to be strongly typed from the ground up instead of added to an existing dynamically typed language.
  I don't see much point in switching things now, I'll wait for WASM and use Rust or Swift.
- Can’t you just use try/catch blocks
  No, because what if whatever you're calling is updated and suddenly it throws a new exception where before it didn't? Python or JavaScript or other interpreted languages will never warn you about that.
  if the data structure of whatever you’re working with isn’t what you expected?
  That sounds like a whole lot of boilerplate I have to write to verify every time that something is what I expect. Static typing does that for me much easier and more reliably.
  Some languages like Rust have so good type systems that often when a program compiles, it just works. You don't have to run the code to know that it functions if you only make a small change.
  What kind of systems have you worked in? In small systems, the static analysis doesn't matter as much, but the benefits become bigger and bigger the more code there is to analyze.
- Let me reverse this question and ask what is the benefit of dynamic typing? What is gained from vaguely defined objects?
  The purpose of typed languages is to ensure the bare minimum when it comes to safety. That when you're accessing a field of an object that field is real, and that field is always going to be an int or a string.
  Try/catch only goes so far before it becomes way more cumbersome than necessary, as is checking every field of an object.
  Typescript is an example of a language that does static typing poorly, because by design it has to. It's a quick bandaid fix over an inherently awful language.
- I like typescript because my API can generate types for my FE project.
  So, if i change my API, i pull in fresh types and fix the errors, and i get in-ide hints for the shape of payloads, responses and events. Not everything is simple CRUD.
  Also, if you pull in a library, having types is a godsend
- Interesting argument. I have used both typescript and JavaScript, but I spend 99% of my time writing firmware in C, because of this I LOVE strongly typed languages, and I get kinda annoyed/paranoid when my variable COULD change type quietly so end up doing (perhaps too much) type checks etc.
  I can say with surety I hate programming in both Typescript and JavaScript, but I definitely hate Typescript less because of the typing.
  Having said that, I don't really like the compiled javascript that comes out of the typescript compiler, because it puts some distance between the user and the code and I am all for clarity, especially when people have to go out of their way to not run this code.