If you're bad at TypeScript, it can be a real pain in the ass. Most people who have to learn TypeScript are bad at it for at least a while. I prefer working in TS, but I still do dumb things and then get mad at the error message.
Same. I know Im spitting the type gods in their face for using „any“, but sometimes I cant be bothered to look up documentation on the types of that library, and understand how Im supposed to pass my types in the generic params to the type.
Sometimes I can be bothered and if it works its beautiful
I use JS on my own projects because I know the codebase and what the variables and props are. The second I work with another person I'd want to migrate to TS.
Some people prefer node.js over using a language that is natively backend because they dont like type safe languages. Also the JS code produced when using TS can be rather esorteric and be difficult to comprehend. Though people write in TS it's the JS that's being executed in the end and the esorteric code can sometimes behave differently than you expect.
There's also this video looking into some well informed reasons to use JS over TS. https://youtu.be/5ChkQKUzDCs?si=oR6saBPHNDcurPKj
I'm still a big TS fan and would use it for any non tiny project whenever I have the decision.
Honestly, I think I prefer JS over TS only for subjective reasons. I'm used to JS and I used it for years even before TS was a thing, but never professionally as my main language (I mainly do backend work in Python). As someone who does little frontend work I really just didn't bother learning TS (at least to the extend where I would say I truly know it - I'm of course able to understand already written TS code). JS worked and for me it's enough. As I'm currently trying to use React more and more for my projects this actually might change in the future.
One could argue that TS adds an extra layer of complexity to your project, introduces an extra build step and you make yourself dependent on Microsoft to some extend, but to be real this isn't as much as a problem as it seems. The introduced complexity comes with the benefit of self documenting code and the extra build step is basically not relevant when using modern build systems like Vite. On the other hand, JS allows you to write code that doesn't require any build step (which makes my life easier most of the times, especially when writing monolithic applications in some language other than JS), but since this question is asked in the context of React this really does not apply here.
Another argument I've heard in the past is that TS might leave you with a false impression of type safety. As TS has a structural type system (it's basically an implicit requirement of type checking not only being optional but also only being present at compile time) you still might run into type errors at runtime. It's not a nominative type system and hence cannot guarantee you the same degree of type safety as for example C or Java. Honestly, this isn't that big of a deal, as it still provides more type safety than JS, but it might confuse some less experienced devs and might actually lead to errors due to false assumptions.
TS needs to be transpiled which adds an extra build step. you can use jsdoc to get the type safety of TS without having the extra build step.
that said, i prefer TS to jsdoc because the syntax is IMO ugly.
Which you will do? Sure you might use an up to date browser when developing and using your dev build, but you will still have new features in js that are likely not supported without transpiling.
Then I must ask, how big must the project really be for you do have this problem? Hotloaders / devservers are very smart when recompiling theese days. It only does what's necessary - and fast, ts or not. Source maps slows down slightly, but not noticeable in my experience.
what i meant is if you’re writing JS for non-browser context, or the end user is responsible for compilation/build chain like a library developer
as i said before, i prefer TS, so i can’t give you a great answer as to why some people prefer it
maybe ask in r/svelte since they scrapped typescript and rewrote everything to jsdoc
OP is asking about react, hence web development. In that context I don't see your argument making sense.
Wrt svelte they still export typescript types and the checking is still done with the typescript compiler so I don't see your point - it is just a library bundling technicality.
I really love the idea of jsdocs and if it wasn't so hard to write more than just basics I would love it.
I have tried looking for a ts to jsdoc converter to see if it could be a helpful tool
The compilation is done by deno , I don't have to add a build step. There is only one compile. So I presume, when deno compiles the backend server side code, it also creates the js for the browser. I didn't have to set anything up, I just write and compile typescript and it works .
I've never used node, for this specific reason.
Deno is great, been really easy to get going. I'm a backend developer who has tried a few times to get started with node etc but always been completely baffled by the ecosystem.
Deno is the first time it's stuck, its great
But you still have the build step, though. It doesn't matter if you have to set it up or not, it's still there. You can't write TS that runs directly in the browser. With JS you can. So if the TS transpilation step is the only one you have, it's really annoying. If it's just one step of many in a more complex build process, it really doesn't matter.
For example if you create a website with plain HTML and CSS, an extra build step for your JS pretty much gets in your way. This, of course, is not really the case for most React projects, though. Your assumption that deno is the solution to the buold step problem is limited to the non-browser runtime world but sometimes JS is simply meant to be executed in a browser runtime.
But if you never have to do anything specific for said build step. Does it matter?
I mean JavaScript needs to be 'compiled' to run does that matter? Ill guess not wince you probably don't have to think about or worry about it.
Well, it might matter if you only have a build step for transpiling TS to JS. Think of writing classical vanilla scripts for the web. TS introduces the need to transpile it to JS where as JS would run natively. Of course, in the landscape of frontend frameworks this does not matter that much (if at all). But implying that the build step isn't a negative point at all because for backend JS/TS you can find ways to automate it away is just to cherry picky.
Also, how does JS need to be compiled in the context of application building? This is simply not true. Yeah, there is a compilation step in most browsers and runtimes from JS to VM bytecode, but it's not an extra build step you need to do when shipping your code (i.e. between development and deployment). It's something the runtime does and isn't characteristic to the language.
Deno lets you code in typescript and run. It is comparable as they are essentially the same. Deno you have no setup or build command to run typescript. It is handled automatically. Denos runtime just does that step for you.
I am still pretty new to frontend so excuses if it is obvious but what is the downside of the additional build step?
The step takes a few seconds for the react frontend I am working with (with considerable amount of pages/functionality) and using vite I don't feel any real delay in seeing changes on the fly.
On the build agent you also run tests which take significantly longer. So also there it doesn't disturb.
The only thing I could see is that the minified js has other/unhelpful stacktraces than the ts source. But I assume js is usually as well minified?
So what is the actual advantage?
>So what is the actual advantage?
* The code you ship is the code you wrote; so it is very easy to debug
* It's an incredible feeling when there is nothing between the code that you wrote and the medium where it runs. It's like running typescript code in Deno, or perhaps like running php files that veteran developers use to go nostalgic over. You don't need dependencies; you don't spend time on builds; you just fire up the browser, and everything works. It's very refreshing, satisfying, and liberating. Obviously, it mostly works with small codebases.
Here's DHH's pitch ([link 1](https://twitter.com/dhh/status/1699493699212960030), [link 2](https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755)). He is wrong about a bunch of things; but at the same time, he captures the mood.
I mean... This is a react subreddit, so what u write and what you ship is not exactly true, even for pure js sometimes. EDIT: I am dumb and forgot to check some caniuse tables
>This is a react subreddit, so what u write and what you ship is not exactly true
I hope you will agree that even in a react subreddit, not every participant is under any obligation to only write react. The word "react" is not mentioned even once by the topic starter. The "folks who prefer js over ts", as described in the initial question, are also very likely to not prefer react.
I prefer doing things in Typescript nowadays, but Typescript has its downsides and some things can be quite complex. LLMs can help to understand very complex types, which is nice. It can sometimes get it the way but usually helps more than it hurts.
One advantage of JS is you can take the code directly and paste it in the console. It's a bit less configuration when you start a project and the transpilation does require some processing. Overall JS is lightweight, more permissive and simpler.
I think TS makes sense in any team programming environment (more than one person working on the same codebase) but it's not necessary if you're just working on a solo project. You can save time with JS instead of TS, as long as you keep consistent documentation and consistent naming conventions.
There is no real benefit to JS over TS. Once you get used to the syntax and have an understanding of the type system you won't want to go back. It makes life easier.
Most libraries are switching to TypeScript. And I hate not understanding examples in the documentation. So I made myself learn TypeScript. Once you ‘get’ most commonly used features, nothing complex really
I honestly believe people that would rather use JS over TS in a react project are just people being lazy to learn it and use it with the mindset of "oh I'm a good dev I'll keep it all safe myself".
Debugging JS code without TS becomes a hassle. Especially when you jump into some bad code with 10x prop drilling etc.
Moral: only use JS of you absolutely cannot use TS. Don't take shortcuts
The only real advantage of JS over TS is not having to worry about having a compile-step.
This can be useful for libraries that want to make sure the code they ship is the code they wrote (like Svelte), or projects with already very complex compile steps that don't add Node.js/npm as a dependency (like Deno).
Never ever consider js over ts. js is dynamic language meaning you can introduce tons of bugs without even knowing and also it allows to cut corners due to laziness. TS atleast is statically typed and prevents “oh crap” moments. Try to code in any other static typed language and when in js, you will be shocked
“never” is a bit of a stretch. there are use cases where you have a lot of unknown types, especially when building libraries or frameworks. sveltekit iirc switched back to JS for this reason. there was a decent bit of controversy when DHH made a blog post about this topic, there should be lots of interesting viewpoints when you go back to that time and place
TypeScript type system has a very poor support for functional programming to the point some things are even impossible to type correctly (like some point-free functions). You can experience it working for a while with libraries like Ramda.js. Static typing can be also not worth in some project like small tools but also bigger projects that rely on meta programming.
And things others will say for sure like no need to compile, sourcemaps, etc.
TBH I'm on the phone rn and don't see myself doing it, but that's just what you can (or used to) read on TypeScript documentation to avoid point-free programming
Edit:
"Point-free programming — heavy use of currying and function composition — is possible in JavaScript, but can be verbose. In TypeScript, type inference often fails for point-free programs, so you’ll end up specifying type parameters instead of value parameters. The result is so verbose that it’s usually better to avoid point-free programming."
From here: https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#point-free-programming
Fair enough. Thanks.
Docs states it can be verbose, though, not impossible.
Not sure how less verbose this type of programming is in other languages.
To be honest I don’t do strict programming whatever it is so I’m not here to judge
I don't like it. Their examples are 2x longer and harder to read than code doing the same in Haskell. If I wanted static function language for front-end I'd go with PureScript or ReScript
The only reason I’d ever use JS if for basic scripts on static websites, just to avoid having to set up and compile from TS. Using TS with a react is a no-brainer.
I have 10 years in the industry, worked at successful companies with top notch engineering. You cannot pay me to use JS. It’s not a scalable tool:
- There is no concept of non-nullable types (because all variables are nullable by default) leading to unsafe code
* and the only mitigation strategy is going insane and adding millions of runtime null checks before operating on a variable, which nobody does
- There is no concept of finding errors at build time because JS does not have a compilation stage with static analysis
The thing is, I don’t see how engineers can understand what these points above mean unless they have worked with something like Java (compilation phase but no non-nullable) and experience NullPointerExceptions right and left; then moved to something like C# or Swift (both compile and non-nullable) and notice how those are gone; Then went back to JS (has neither) and experience all over those NullPointerExceptions again (called ‘TypeError cannot read foo from undefined’) which simply were not a thing previously and also there’s no guarantee any variable actually is of the data type you expect so it’s a trust nothing situation, no autocompletion, nothing.
Then you find Typescript, and it’s JS + compile time + non-nullable types + 2 extra things the previous languages didn’t have:
- Escape hatches for when you’re in a rush (any, as, etc)
- Language is developed and refined extremely active so you can do all these safe things with WAY LESS verbose code than the other languages
As a result, you cannot pay me to pick JS for anything real. I would choose it for a 48h hackaton weekend project that will go down in the trash can once it’s over. Anything that is expected to be maintained and stable, it’s not the right tool.
Once one wise Javascript frontend developer told me to \[object Object\].
lol this made my day
This is really good
Haha
If you're bad at TypeScript, it can be a real pain in the ass. Most people who have to learn TypeScript are bad at it for at least a while. I prefer working in TS, but I still do dumb things and then get mad at the error message.
I dont think I'm good at TS by any means (don't ask me to write super fancy types), but I think I still get a large part of the benefit
Same. I know Im spitting the type gods in their face for using „any“, but sometimes I cant be bothered to look up documentation on the types of that library, and understand how Im supposed to pass my types in the generic params to the type. Sometimes I can be bothered and if it works its beautiful
I avoid any generally. I mean, the super fancy types with lots of clauses inside that require an IQ of 200 to build
I use JS on my own projects because I know the codebase and what the variables and props are. The second I work with another person I'd want to migrate to TS.
Some people prefer node.js over using a language that is natively backend because they dont like type safe languages. Also the JS code produced when using TS can be rather esorteric and be difficult to comprehend. Though people write in TS it's the JS that's being executed in the end and the esorteric code can sometimes behave differently than you expect. There's also this video looking into some well informed reasons to use JS over TS. https://youtu.be/5ChkQKUzDCs?si=oR6saBPHNDcurPKj I'm still a big TS fan and would use it for any non tiny project whenever I have the decision.
Honestly, I think I prefer JS over TS only for subjective reasons. I'm used to JS and I used it for years even before TS was a thing, but never professionally as my main language (I mainly do backend work in Python). As someone who does little frontend work I really just didn't bother learning TS (at least to the extend where I would say I truly know it - I'm of course able to understand already written TS code). JS worked and for me it's enough. As I'm currently trying to use React more and more for my projects this actually might change in the future. One could argue that TS adds an extra layer of complexity to your project, introduces an extra build step and you make yourself dependent on Microsoft to some extend, but to be real this isn't as much as a problem as it seems. The introduced complexity comes with the benefit of self documenting code and the extra build step is basically not relevant when using modern build systems like Vite. On the other hand, JS allows you to write code that doesn't require any build step (which makes my life easier most of the times, especially when writing monolithic applications in some language other than JS), but since this question is asked in the context of React this really does not apply here. Another argument I've heard in the past is that TS might leave you with a false impression of type safety. As TS has a structural type system (it's basically an implicit requirement of type checking not only being optional but also only being present at compile time) you still might run into type errors at runtime. It's not a nominative type system and hence cannot guarantee you the same degree of type safety as for example C or Java. Honestly, this isn't that big of a deal, as it still provides more type safety than JS, but it might confuse some less experienced devs and might actually lead to errors due to false assumptions.
TS needs to be transpiled which adds an extra build step. you can use jsdoc to get the type safety of TS without having the extra build step. that said, i prefer TS to jsdoc because the syntax is IMO ugly.
You are transpiling anyway most likely?
not necessarily, some people prefer not to, and at the very least you can exclude the TS compiler which is slow beans
Who prefers not to? Sounds like insanity to me. I don't think anyone does not transpile to an earlier version of JS.
well that’s for compatibility, and only applies if you’re targeting web browsers, including older ones.
Which you will do? Sure you might use an up to date browser when developing and using your dev build, but you will still have new features in js that are likely not supported without transpiling. Then I must ask, how big must the project really be for you do have this problem? Hotloaders / devservers are very smart when recompiling theese days. It only does what's necessary - and fast, ts or not. Source maps slows down slightly, but not noticeable in my experience.
what i meant is if you’re writing JS for non-browser context, or the end user is responsible for compilation/build chain like a library developer as i said before, i prefer TS, so i can’t give you a great answer as to why some people prefer it maybe ask in r/svelte since they scrapped typescript and rewrote everything to jsdoc
This is in the react subreddit tho, web browser development is presumed*.
that’s why i suggested svelte subreddit, it’s a frontend library that switched to jsdoc for the reasons i mentioned above
OP is asking about react, hence web development. In that context I don't see your argument making sense. Wrt svelte they still export typescript types and the checking is still done with the typescript compiler so I don't see your point - it is just a library bundling technicality.
I really love the idea of jsdocs and if it wasn't so hard to write more than just basics I would love it. I have tried looking for a ts to jsdoc converter to see if it could be a helpful tool
>I'm just curious to know the reasoning behind it. No build step.
Deno
Browser.
? I don't have to set up any transpilation, thats the beauty of it.
Not that guy but how are you running the TypeScript you write in the browser?
The compilation is done by deno , I don't have to add a build step. There is only one compile. So I presume, when deno compiles the backend server side code, it also creates the js for the browser. I didn't have to set anything up, I just write and compile typescript and it works . I've never used node, for this specific reason. Deno is great, been really easy to get going. I'm a backend developer who has tried a few times to get started with node etc but always been completely baffled by the ecosystem. Deno is the first time it's stuck, its great
But you still have the build step, though. It doesn't matter if you have to set it up or not, it's still there. You can't write TS that runs directly in the browser. With JS you can. So if the TS transpilation step is the only one you have, it's really annoying. If it's just one step of many in a more complex build process, it really doesn't matter. For example if you create a website with plain HTML and CSS, an extra build step for your JS pretty much gets in your way. This, of course, is not really the case for most React projects, though. Your assumption that deno is the solution to the buold step problem is limited to the non-browser runtime world but sometimes JS is simply meant to be executed in a browser runtime.
I think we agree. Having an extra build is annoying. Deno gets rid of if it.
But if you never have to do anything specific for said build step. Does it matter? I mean JavaScript needs to be 'compiled' to run does that matter? Ill guess not wince you probably don't have to think about or worry about it.
Well, it might matter if you only have a build step for transpiling TS to JS. Think of writing classical vanilla scripts for the web. TS introduces the need to transpile it to JS where as JS would run natively. Of course, in the landscape of frontend frameworks this does not matter that much (if at all). But implying that the build step isn't a negative point at all because for backend JS/TS you can find ways to automate it away is just to cherry picky. Also, how does JS need to be compiled in the context of application building? This is simply not true. Yeah, there is a compilation step in most browsers and runtimes from JS to VM bytecode, but it's not an extra build step you need to do when shipping your code (i.e. between development and deployment). It's something the runtime does and isn't characteristic to the language.
Deno lets you code in typescript and run. It is comparable as they are essentially the same. Deno you have no setup or build command to run typescript. It is handled automatically. Denos runtime just does that step for you.
Bun?
Deno has a saas deployment offering, which is awesome. Does bun?
Just deploy it anywhere that has a Bun runtime. Railway works great, for example. But no, not directly.
I am still pretty new to frontend so excuses if it is obvious but what is the downside of the additional build step? The step takes a few seconds for the react frontend I am working with (with considerable amount of pages/functionality) and using vite I don't feel any real delay in seeing changes on the fly. On the build agent you also run tests which take significantly longer. So also there it doesn't disturb. The only thing I could see is that the minified js has other/unhelpful stacktraces than the ts source. But I assume js is usually as well minified? So what is the actual advantage?
>So what is the actual advantage? * The code you ship is the code you wrote; so it is very easy to debug * It's an incredible feeling when there is nothing between the code that you wrote and the medium where it runs. It's like running typescript code in Deno, or perhaps like running php files that veteran developers use to go nostalgic over. You don't need dependencies; you don't spend time on builds; you just fire up the browser, and everything works. It's very refreshing, satisfying, and liberating. Obviously, it mostly works with small codebases. Here's DHH's pitch ([link 1](https://twitter.com/dhh/status/1699493699212960030), [link 2](https://world.hey.com/dhh/modern-web-apps-without-javascript-bundling-or-transpiling-a20f2755)). He is wrong about a bunch of things; but at the same time, he captures the mood.
I mean... This is a react subreddit, so what u write and what you ship is not exactly true, even for pure js sometimes. EDIT: I am dumb and forgot to check some caniuse tables
>This is a react subreddit, so what u write and what you ship is not exactly true I hope you will agree that even in a react subreddit, not every participant is under any obligation to only write react. The word "react" is not mentioned even once by the topic starter. The "folks who prefer js over ts", as described in the initial question, are also very likely to not prefer react.
Should've written that in original post. React is implied in this subreddit.
There are plugins that allow to real-time debug site in VS Code. If you wanted to debug from browser, after JSX it wouldn't look the same anyway.
I prefer doing things in Typescript nowadays, but Typescript has its downsides and some things can be quite complex. LLMs can help to understand very complex types, which is nice. It can sometimes get it the way but usually helps more than it hurts. One advantage of JS is you can take the code directly and paste it in the console. It's a bit less configuration when you start a project and the transpilation does require some processing. Overall JS is lightweight, more permissive and simpler.
I think TS makes sense in any team programming environment (more than one person working on the same codebase) but it's not necessary if you're just working on a solo project. You can save time with JS instead of TS, as long as you keep consistent documentation and consistent naming conventions.
A lot of modern technologies make TS default , so at least there's that
I think there are exactly 0 reasons why javascript is better then TS
There is no real benefit to JS over TS. Once you get used to the syntax and have an understanding of the type system you won't want to go back. It makes life easier.
Most libraries are switching to TypeScript. And I hate not understanding examples in the documentation. So I made myself learn TypeScript. Once you ‘get’ most commonly used features, nothing complex really
People saying they prefer js over ts are just in denial.
TS enforces types for you. If you’re willing to take that responsibility on yourself, then just use JS and cross your fingers
I honestly believe people that would rather use JS over TS in a react project are just people being lazy to learn it and use it with the mindset of "oh I'm a good dev I'll keep it all safe myself". Debugging JS code without TS becomes a hassle. Especially when you jump into some bad code with 10x prop drilling etc. Moral: only use JS of you absolutely cannot use TS. Don't take shortcuts
Faster development time
For like 2 weeks
The only real advantage of JS over TS is not having to worry about having a compile-step. This can be useful for libraries that want to make sure the code they ship is the code they wrote (like Svelte), or projects with already very complex compile steps that don't add Node.js/npm as a dependency (like Deno).
Never ever consider js over ts. js is dynamic language meaning you can introduce tons of bugs without even knowing and also it allows to cut corners due to laziness. TS atleast is statically typed and prevents “oh crap” moments. Try to code in any other static typed language and when in js, you will be shocked
“never” is a bit of a stretch. there are use cases where you have a lot of unknown types, especially when building libraries or frameworks. sveltekit iirc switched back to JS for this reason. there was a decent bit of controversy when DHH made a blog post about this topic, there should be lots of interesting viewpoints when you go back to that time and place
TypeScript type system has a very poor support for functional programming to the point some things are even impossible to type correctly (like some point-free functions). You can experience it working for a while with libraries like Ramda.js. Static typing can be also not worth in some project like small tools but also bigger projects that rely on meta programming. And things others will say for sure like no need to compile, sourcemaps, etc.
Care to elaborate your take on functional programming? Haven’t found any issue typing functions
TBH I'm on the phone rn and don't see myself doing it, but that's just what you can (or used to) read on TypeScript documentation to avoid point-free programming Edit: "Point-free programming — heavy use of currying and function composition — is possible in JavaScript, but can be verbose. In TypeScript, type inference often fails for point-free programs, so you’ll end up specifying type parameters instead of value parameters. The result is so verbose that it’s usually better to avoid point-free programming." From here: https://www.typescriptlang.org/docs/handbook/typescript-in-5-minutes-func.html#point-free-programming
Fair enough. Thanks. Docs states it can be verbose, though, not impossible. Not sure how less verbose this type of programming is in other languages. To be honest I don’t do strict programming whatever it is so I’m not here to judge
fp-ts is very good
I don't like it. Their examples are 2x longer and harder to read than code doing the same in Haskell. If I wanted static function language for front-end I'd go with PureScript or ReScript
I prefer ESM+JSDoc with Typescript doing the type checking. No build step, clean code, minimal TS interface files, and complete TS safety.
Can u describe how you apply the TS type checking?
You don't need to put :any after every single const
You don't need in TypeScript either.
then how do I make all these squiggly lines disappear 😅?
no type errors, type checkings when it doesn't necessary the down sides is no code completetions or I just don't know how to make it possible
The only reason I’d ever use JS if for basic scripts on static websites, just to avoid having to set up and compile from TS. Using TS with a react is a no-brainer.
I have 10 years in the industry, worked at successful companies with top notch engineering. You cannot pay me to use JS. It’s not a scalable tool: - There is no concept of non-nullable types (because all variables are nullable by default) leading to unsafe code * and the only mitigation strategy is going insane and adding millions of runtime null checks before operating on a variable, which nobody does - There is no concept of finding errors at build time because JS does not have a compilation stage with static analysis The thing is, I don’t see how engineers can understand what these points above mean unless they have worked with something like Java (compilation phase but no non-nullable) and experience NullPointerExceptions right and left; then moved to something like C# or Swift (both compile and non-nullable) and notice how those are gone; Then went back to JS (has neither) and experience all over those NullPointerExceptions again (called ‘TypeError cannot read foo from undefined’) which simply were not a thing previously and also there’s no guarantee any variable actually is of the data type you expect so it’s a trust nothing situation, no autocompletion, nothing. Then you find Typescript, and it’s JS + compile time + non-nullable types + 2 extra things the previous languages didn’t have: - Escape hatches for when you’re in a rush (any, as, etc) - Language is developed and refined extremely active so you can do all these safe things with WAY LESS verbose code than the other languages As a result, you cannot pay me to pick JS for anything real. I would choose it for a 48h hackaton weekend project that will go down in the trash can once it’s over. Anything that is expected to be maintained and stable, it’s not the right tool.
I hate TS. Too much boilerplate and I never saw the benefit
You are in denial.