Comment by DiabloD3 | Hacker News Reader

Comment by DiabloD3 | Hacker News Reader

I think Typescript isn't worth using, and I find this unfortunate. The Typescript team clearly has put years of work into this, and clearly has tried to shore up the deficiencies in Javascript.

Are you writing a brand-new codebase that needs to work on multiple platforms, and not exclusively in a browser? Don't use Typescript, use a language with native WASM support. This includes avoiding solutions that involve Electron, Deno, and CEF, as they are browsers, too.

Are you writing a brand-new codebase that only works in the browser? Learn how to use HTML and CSS correctly, avoid as much Javascript and Typescript as possible: Less is more.

Are you maintaining an existing codebase with extensive Javascript, and you are not willing to rewrite entirely Typescript? Try using Typescript, but you're better off jumping ship, nothing can save it now.

Any codebase that has untyped code in it, that cannot be compile-time analyzed for safety, that requires a significant client-side investment (ie, a giant blob sent to the browser), is kinda doomed to failure, and you will not realize the magnitude of your mistake until it is too late.

I realize my opinion is unpopular, as the programmers on HN seem to be a lot of front-end devs and a lot of "fullstack" devs, where the "full" is JS+TS in NodeJS, using some predefined popular NodeJS framework. I just want systems that are designed to minimize the BS, I've chased enough BS in my lifetime, TS can never deliver a no-BS system to me.

> Are you writing a brand-new codebase that only works in the browser? Learn how to use HTML and CSS correctly, avoid as much Javascript and Typescript as possible: Less is more.

It's really difficult to construct a comprehensive SPA without a nice framework such as Vue or React; and as it relates to your prior paragraph about WASM, I'd love to take this advice, but reactive UI frameworks suitable for browser are young and immature compared to Vue and React (IMO).

I would LOVE to use a different language and compile to WASM, just don't think I can replace my Vue+TS frontends at this time.

I think its good to bring up SPAs in this context: fundamentally, they shouldn't exist, and you're using the browser wrong. They are the poster child of design smell when it comes to "web apps".

Do you need SEO to work, even though Google Search torpedoed effective SEO a long time ago? Search engines disfavor websites that are extremely opaque and are made of a single page or few pages.

Do you need to be able to open content in new tabs, thus increasing productivity dramatically? Many SPAs will forget the app state and be unable to navigate back to where you were if you open it in a new tab. This also means you can't bookmark them either, and I've also seen browser tab/window restoration screw over SPA state.

Do you want browser performance? Using complex JS/TS to mangle the DOM and causing redraws outside of the initial page load is a good way to scare users off when their browser shits itself for 3+ seconds.

> I think its good to bring up SPAs in this context: fundamentally, they shouldn't exist, and you're using the browser wrong. They are the poster child of design smell when it comes to "web apps".

So a universal, cross platform, cross device, responsive, accessible UI stack that has simple distribution, avoids walled gardens and has excellent performance is a "design smell"?

> Do you need SEO to work, even though Google Search torpedoed effective SEO a long time ago? Search engines disfavor websites that are extremely opaque and are made of a single page or few pages.

Nope. I develop PWAs for healthcare and other industries. I rarely, if ever care about SEO. If I did, I agree that SPA is a poor choice, but for 99% of what I develop, the web app is a replacement for a desktop or mobile application. SEO isn't relevant.

> Do you need to be able to open content in new tabs, thus increasing productivity dramatically? Many SPAs will forget the app state and be unable to navigate back to where you were if you open it in a new tab. This also means you can't bookmark them either, and I've also seen browser tab/window restoration screw over SPA state.

Deep linking has been a solved problem for so long, it honestly makes me wonder why people keep bringing this up. Use a decent router. IMHO this is much easier to do in a web app than a native mobile app.

> Do you want browser performance? Using complex JS/TS to mangle the DOM and causing redraws outside of the initial page load is a good way to scare users off when their browser shits itself for 3+ seconds.

I'm not sure how you're developing web applications, or what stack you're using, but if you're seeing 3+ second DOM mutations I can tell you that you're doing something very wrong.

Web browsers are fantastically performant, I can't think of any other rendering stack that gives you so much capability with such performance.

There's a reason why XUL, Silverlight, Flex, XAML and all the others have disappeared or have such tiny market share compared to HTML + CSS.

The web has fantastic deployment and update capabilities coupled with a powerful rendering layer. It's easy to see why it's a popular choice for application development.

I agree someone is doing something wrong, wrt sluggish browser performance and routing. However, I keep being exposed to this in random SPAs I get exposed to; I can only conclude this continues to be a problem that developers have and the popular frameworks somehow footgun them into this.

They can footgun just as hard with server-side rendering, including breaking when you try to have multiple tabs of the same site.

This is all outdated thinking now that we have PESPA frameworks

I mostly agree with this, and haven't been happy developing JS for some time. I don't enjoy having to deal with bundles, webpack, TypeScript, bloated dependency graphs.

Luckily I can use Go for new projects, and even when picking it up at first I quickly found it more pleasurable to use than NodeJS. I don't JS on the backend if I can avoid it.

On the frontend, I would still argue on balance SPA/bundling is the best option when your company is developing an application. I appreciate that for many things HTML/CSS with minimal JS works well, but for anything dynamic where you have a team of devs, the community and dependencies around React are too useful to replace with much else.

Although I agree with you, I'm curious how this translates to your full time job (assuming you have one)?

I find most companies don't do JS any more (TS experience is a requirement)

Where I work, everything on the frontend is TypeScript, everything Nodejs is TypeScript. I did create a nice little bash utility using Standard style i.e. vanilla js in Node and that's worked out well.

Although I'm senior enough to start a new project without TS within my team, I think it would be a little egotistic. Although I am not convinced by TS benefits, most people at my company are convinced it's necessary and I don't think it's worth going against the grain. There's many more important decisions when starting a new project, and I think the architecture is much more important than whether to type or not. Besides, I now choose to use Go on anything server side, and try to shy away from the frontend because I don't find it as fun to code as I used to (partly because of things like TS, partly because the kind of work doesn't feel as engaging, and feels like busywork).

I worked at a company previously that had a large NodeJS codebase that was largely created before TypeScript was so popular. That's what I mostly have to compare against, and so I do know what it is like to do massive projects with many people without TypeScript. I don't think we ever felt the need for types, and building and pushing code was always simple and safe.

I get what you mean about BS. For me the most painful thing (JS or TS) is if you leave a project for a year you need to use a newer node for security, you need to upgrade modules for security, and some NPM package creators love to have breaking changes or even pull modules completely, forcing a lot of manual work and refactoring to fix.

Whereas in .Net this churn rate is way slower because almost all functionality is provided by the famously backward-compat friendly MS which also sets the culture for Nuget publishers too.

Reply on news.ycombinator.com