[112]

I've loved Vue for a long time, worked two years with it almost daily, but right now I avoid it as much as I can, as I can't stand working with JavaScript without TypeScript. The TypeScript support in the current version of Vue is crap, and the simplest things, such as creating a (typed) component library, are hard and require numerous hacks.

If I were to use something that lacks TypeScript support, it would be Svelte, because it brings unique advantages. By adding hooks, React became the winner for me.

Angular has never been an option for me.

[manigandham]

Vue 3 will change all that. It's written in typescript with first-class support and the composition API is like React hooks but better for most cases.

Vue's templating is standard HTML which means it can be delivered by any server-side language/framework. This is where Vue shines in adding interactivity to many typical apps without going fully SPA.

[williamdclt]

It is standard HTML in the sense that it's valid HTML, which React JSX isn't, of course. But without the JS runtime it won't do anything, so in the end what's the advantage over React? You can add interactivity without going full SPA with React too after all

[manigandham]

It's a subtle but huge difference. In React, using JSX means you can create components and mount them on top of the existing elements on the page.

With Vue's HTML templates, the page itself can be the component and everything can become interactive. For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.

This lets you render the page using existing web frameworks, it's faster because the server puts it together, it's progressive enhancement and works without JS and on slow devices, and Vue can seamlessly add on top with nothing more than a single JS tag and no compilation step.

[eblanshey]

> For example, you can easily output a HTML table from server-side code, then Vue can convert that into a interactive component while using the existing structure and data.

If you're using vue, you inherently use state or props, and those are handled using {{ myState }} syntax. If you load everything from the backend, it's going to have the actual data in the table. How would you convert the already-rendered HTML to something interactive if the template isn't set up that way?

[kumarvvr]

Fantastic point.

Vue has a bit more flexibility in that regard.

[honopu]

I think you're talking about universal or isomorphic rendering, but each of these allow for it.

[manigandham]

No, I'm talking about using hundreds of existing server-side web frameworks that output HTML, not Node/React SSR which is far more limiting.

[azangru]

> In React, using JSX means you can create components and mount them on top of the existing elements on the page.

I am not sure this analysis is entirely correct.

In case of server-side-rendered React pages, React takes the html that arrives from the server and makes it interactive ("hydrates" it, according to the common React community parlance), provided that that DOM generated from that HTML corresponds to the virtual DOM that React generates. It doesn't throw the original DOM away.

[manigandham]

This is only if you use SSR and is the opposite of being able to render with any existing web framework.

[keithnz]

you can use the composition api already in Vue2, which is what I have been doing, and I'm using typescript for everything. There is a chance the api may change, but it seems pretty stable. I combo this with using tailwindcss and I think that makes for a pretty productive combo.

[StreamBright]

>> This is where Vue shines in adding interactivity to many typical apps without going fully SPA.

That is good to know. I wasn't aware. Most of the apps we are working on cannot be SPAs easily, so it matters if the JS framework supports operating without it.

[DanielBMarkham]

Apologies, I a bit confused. SPA stands for Single-Page Application, does it not? So if you have a single page that works as an application, it is a SPA, no?

I understand the desire to use webkit, Typescript, and so forth to develop modern apps, I'm just confused at why Vue in a stand alone page delivered by ftp or usb drive isn't a "full" SPA

[oefrha]

You can mix and match traditional server-rendered content and JS framework (in this case Vue)-rendered components on the same page (not considering SSR here). Going full SPA means using the latter exclusively.

[frosted-flakes]

You can easily do that with React too. In fact, that's how Facebook first used it, using it for just the chatbox (or something) with the rest of the page as it was.

[manigandham]

React with JSX means you can easily mount a component into an element, but you can't easily add interactivity to all of the existing HTML on the page as delivered by the server.

[DanielBMarkham]

Got it. Thanks. We have several content-delivery pipelines at work. It had been so long since I used server-side dynamic content creation that it had slipped my mind.

[sebazzz]

Vue 3 is getting delayed, isn't it? Not weird for a community project, but still something to note.

[manigandham]

I don't know, there's no hard deadline but you can check the official roadmap: https://github.com/vuejs/vue/projects/6

[baybal2]

A reverse situation here. I deal with strict no typescript policy, so besides a problem of finding typescript devs, we have a problem of having to "de-typescript" a lot of 3rd party code.

Typescript has a lot of adoption within with ex-Java devs, and with that comes a lot of "Java-think." It's hard for these people to adapt to not doing things "the Java way" and vice versa.

And another part of the problem is that people have burnt themselves badly with Coffeescript, Clojurescript, and few other *scripts that were coming and going trends, and were an enormous LTS burden because of tooling that breaks as fast as you fix it.

[capableweb]

I'm also avoiding typescript as much as I can, but not because typescript itself, but because of how typescript projects tends to be outlined. Lots of the projects are way over-engineered for where they are on the timeline and typescript makes people reach for classes too early. Seeing the same with vanilla JS projects now too when `class` been introduced.

Instead I'm stricly using ClojureScript as the tooling is really solid in everything Clojure, backwards compatibility is a huge selling point in everything Clojure and projects using Clojure/Script tends to be just of the right size and think more about the data structures themselves instead of what many refer to "proper engineering" (SOLID patterns and other nonsense)

[christophilus]

I’m spinning up a few new projects at the moment, and was sooo close to doing them in ClojureScript. I ended up going with JavaScript, Preact, and Rollup just because of familiarity allowing me to move faster. That, and my build times are sub-second, something that was not true of my previous Webpack and typescript projects. My total application bundle size is still smaller than React alone.

ClojureScript is really good, though, I gotta say. How are your production bundle sizes? Are you using shadowcljs? If not, what tooling are you using? Also, what editor? I’m a VSCode guy, and last time I used Clojure (a year or more ago), Calva wasn’t up to snuff. I wonder if that’s changed.

[capableweb]

> How are your production bundle sizes?

Application I'm working on is not that complex, 20 something different pages with multiple sub-sections themselves, bundle ends up being 1.5MB or something like that, 300kb gzipped. Main weight comes from using multimethods which pulls in a lot of cljs.core, so not using that would make it a lot smaller.

Also gonna start splitting the bundle per page but haven't yet.

> Are you using shadowcljs? If not, what tooling are you using?

No, using figwheel-main, project was started before shadowcljs starting to look as good as it looks today. Starting a project today I would probably look into shadow-cljs first. But we're not using any npm dependencies, but shadow-cljs seems to have better introspection properties than figwheel-main (like seeing partitions of bundle size easier, we're currently doing it by looking at the sourcemaps...)

> Also, what editor?

Using vim + fireplace which been working really well for me.

> Calva wasn’t up to snuff. I wonder if that’s changed

Haven't used Calva myself but tons of people in the community swear by it, so I'm thinking it's been improving since the last time you tried it.

I'm not sure when was the last time you tried Calva but Calva been in at least two Clojurists Together (https://www.clojuriststogether.org/) funding cycles, so if you tried it before mid-2019, give it a try again (and report back :) )

[LandR]

IntelliJ with Cursive is a very good Clojure IDE.

[capableweb]

Tried it out before (and your comment actually triggered me to try it out again just to see) but I'm struggling to find anything it does that vim + fireplace doesn't do while vim is way faster and takes less screen-estate so I can have my browser + editor side-by-side.

[chvid]

I agree with this.

TypeScript makes Java and .NET developers think they understand the language and platform and causes a lot of irrelevant design to be copied over into the JS world where it mutates and becomes absolutely poisonous.

Just look at Angular where the boilerplate and crazy dependency injection completely surpasses anything seen in the Java / .NET world.

[dynamite-ready]

It's especially apparent when Java / C# developers are introduced to a simple idea like a Flux pattern store.

Store structures, despite the initial difficulty in learning the pattern, simplify things enormously, but can somehow become nightmarishly complicated in the hands of a developer who expresses API/client relationships in terms of Factories and Services... When it's not hell to work with, it's actually quite interesting to observe.

[manigandham]

Why? Typescript just compiles down to JS, and type definitions are used IDEs so they still help when writing JS.

How does removing typescript help you?

[baybal2]

> How does removing typescript help you?

https://github.com/microsoft/TypeScript/issues

Please count the number of open bugs

JS tooling is already an enormous jenga tower as it is, with tooling breakages eating a double digit of developer time. Adding typescript on top of that would be the real madness.

Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.

On the down side, even certainly not cheap to hire devs with 6-7-8-10+ years of experience have to battle JS tooling every day.

Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.

Imagine doubling that digit when they have to also spend time on learning typescript, and fixing it.

No, it does not pay off at all

[scrollaway]

You're removing typescript because you think it's creating bugs...

You realize you're probably creating bugs yourself by removing typescript manually, which is a thing.. typescript itself can do, by compiling down to JS?

This is some prime dailywtf material.

[afiori]

Well not exactly, the parent said something quite different, in the comment they were comparing tooling not languages and they say that the tooling makes for a significant part of the bugs they have to solve so they want a build process as slim as possible.

Nothing was said about whether typescript code is more or less buggy, just that the typescript tooling had issue to work with other tooling.

[inertiatic]

>Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.

Who are these mythical people?

Do they just magically decipher what interface an argument conforms to? What methods are accessible on a returned result from any random library they're using?

[orange8]

I'm not a myth. Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter.

I see TypesScript as a VERY opinionated linter that affects how you think and write JS. JS is a dynamically typed language, which means you loose a lot of its power and flexability by shoe-horning it into strongly typed languange patterns. Yes, I get it, many programmers think best and are most productive using strongly typed languages, but for those of us that can think dynamic or both, TS just gets in the way.

>> Do they just magically decipher what interface an argument conforms to?

This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply.

>> What methods are accessible on a returned result from any random library they're using?

Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

[giantDinosaur]

I don't even get this criticism - the problem with Typescript is that it's far too easy to bypass the type system and allow the dynamic parts of JS to do whatever you want. You can lie about your interfaces all day and <any> to your dynamic heart's content.

For what it's worth, my experience with programmers who think like you is that rarely they're actually genuinely talented and right, and mostly they just spew forth bugs which often sit dormant until they rear their ugly heads years later. Most people are better off thinking about their API's before they implement them, much like one would do in a real engineering discipline. Types are often (and yes, not always) a good way to draw the effort out to the front of your process.

[boomlinde]

> Explore languages that follow different paradigms, where interfaces just don't apply.

Interfaces as a general concept applies whether there is a type system to ensure that they are satisfied or not. Do you have function parameter lists? Do you have expected shapes for function inputs and outputs? Do you have distinct types? Then you have interfaces. Your shit breaks when they aren't conformed to. It has nothing to do with strong typing or object orientation. Strong, static typing is just a way to ensure at compile-time that the expected interfaces are satisfied.

> Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

Hearing this assurance from someone who just complained about their jenga tower of tooling causing issues, I'm not convinced.

[inertiatic]

>This is a good example of the object oriented, strongly typed way of thinking. Explore languages that follow different paradigms, where interfaces just don't apply.

I'm not sure whether you intended this to sound so patronizing, but wow. What languages should I explore while talking about Javascript?

You are called to edit a function that takes 2 arguments:

function handle_req(request, options):

What is request in this context and what is options?

What makes me more productive, going up the stack and seeing who might call this function and with what argument, or instantly knowing what the domain of values it operates on is and being able to treat this as a separate unit?

>Do not use random libraries. A good library should have even some basic docs outline its API and how to use it.

A whole lot of the time, especially in Javascript land you will join projects where libraries are being used, and where documentation is lacking. Your advice here is basically to not be part of those projects? Instead of developing and using tooling that will ensure that these situations no longer happen?

Okay.

[manigandham]

Typescript is as strongly typed as you want it to be. You can easily work with dynamic types and it will fill in where it can.

[DonHopkins]

>Some of us started JS programming over a decade ago, with no strong typing and IDE to hold our hand and tell us every time you make a mistake. The key is just discipline, good design patterns and a good linter.

A decade ago isn't very long ago. JavaScript is more than 24 years old, and we had to get along without good design patterns or good linters or good debuggers or good libraries or good documentation or good IDEs or good compilers or even good interpreters back then. It sounds like you were late to the party and missed all the fun! ;)

[DonHopkins]

>no strong typing and IDE to hold our hand and tell us every time you make a mistake

Ha ha! You remind me of Larry Wall:

https://news.ycombinator.com/item?id=22210073

>"I think IDEs make language developers lazy." -Larry Wall

https://www.youtube.com/watch?v=AO43p2Wqc08

To which James Gosling replied:

>"IDEs let me get a lot more done a lot faster. I mean I'm not -- I -- I -- I -- I -- I'm really not into proving my manhood. I'm into getting things done." -James Gosling

Andrew Hejlsberg also made some good points in that same discussion:

>Maybe I'll just add, with language design, you know one of the things that's interesting, you look at all of us old geezers sitting up here, and we're proof positive that languages move slowly.

>A lot of people make the mistake of thinking that languages move at the same speed as hardware or all of the other technologies that we live with.

>But languages are much more like math and much more like the human brain, and they all have evolved slowly. And we're still programming in languages that were invented 50 years ago. All the the principles of functional programming were though of more than 50 years ago.

>I do think one of the things that is luckily happening is that, like as Larry says, everyone's borrowing from everyone, languages are becoming more multi-paradigm.

>I think it's wrong to talk about "Oh, I only like object oriented programming languages, or I only like imperative programming, or functional programming".

>It's important to look at where is the research, and where is the new thinking, and where are new paradigms that are interesting, and then try to incorporate them, but do so tastefully in a sense, and work them into whatever is there already.

>And I think we're all learning a lot from functional programming languages these days. I certainly feel like I am. Because a lot of interesting research has happened there. But functional programming is imperfect. And no one writes pure functional programs. I mean, because they don't exist.

>It's all about how can you tastefully sneak in mutation in ways that you can better reason about. As opposed to mutation and free threading for everyone. And that's like just a recipe for disaster.

In the HN discussion of that talk, I wrote:

https://news.ycombinator.com/item?id=19568860

>Anders Hejlsberg also made the point that types are documentation. Programming language design is user interface design because programmers are programming language users.

>"East Coast" MacLisp tended to solve problems at a linguistic level that you could hack with text editors like Emacs, while "West Cost" Interlisp-D tended to solve the same problems with tooling like WYSIWYG DWIM IDEs.

>But if you start with a well designed linguistically sound language (Perl, PHP and C++ need not apply), then your IDE doesn't need to waste so much of its energy and complexity and coherence on papering over problems and making up for the deficiencies of the programming language design. (Like debugging mish-mashes of C++ templates and macros in header files!)

[112]

These mythical people are dinosaurs that have lost (or never had) their love for the work they do, and are not interested in improving.

[danShumway]

N=1, but type errors are extremely rare for me in Javascript. I don't think I'm a magical or exceptional programmer. I think it's just if you spend a lot of time in dynamic languages, there's a certain style of programming some people end up adopting that makes those errors much less common.

If you held a gun to my head and forced me to recklessly provide conjecture on what the difference is, I would say that static languages encourage devs to build large interfaces that take tons of options and pass around a bunch of parameters. This is highly, highly subjective, but:

I think there's a grain of truth in what other people are saying about how Typescript projects tend to be kind of verbose. People start reaching for interfaces that are split across multiple files, people start reaching for classes. When you have really rigid types that need to be formally extended all over the place, this also encourages a lot of casting, which tends to be error prone.

I've seen some really complicated logic/type flows in Typescript that would be extremely error prone in Javascript, but there's basically no reason for them to be that complicated in the first place. There are paradigms in Javascript the codebases are not taking advantage of which are forcing them into these over-complicated logic/data flows. Basically, the more crazy boilerplate, casting, and giant interfaces that a codebase has, the more type errors will occur. The more a project is split up into dozens of dependencies and modules and whatever, the harder it is to reason about what a method or class needs passed in. But Typescript projects tend to grow in that direction very quickly, so the need for Typescript tends to become a self-fulfilling prophecy.

As a comparison, most of the personal projects I work on don't have classes at all, they're using a lot of functional interfaces, and they don't include a bunch of random libraries. Most of the dependencies in my projects are libraries that I've personally vetted. Most of my projects are careful about where state is being stored and how its being passed around.

I dunno. All of that is pure conjecture, but people in general are very dismissive of dynamic typing, but it's just not a real problem for me. There's a general consensus that dynamic languages were a mistake, and I don't dismiss the people saying this, but I also pay a lot of attention to where bugs are coming from in my own code, and I can't get past the point that typing really doesn't seem to matter that much in most things I build.

I was on the Typescript train for a while. I still use it in some projects, there are some org structures where it makes a lot of sense. If I'm working with a Java-to-Javascript dev, I want strong interfaces for them. The projects where I don't use it are because I've spent a long time paying attention to where my bugs are coming from. I can't prove to you its not a problem, I can only speak to the experiences I've had.

[manigandham]

Yea bugs exist, yet there are still thousands of teams using it to build very complex projects with less bugs because of Typescript safety and features.

TS tooling either replaces JS tooling or interacts with it seamlessly. It's not like you're skipping JS altogether and there's no type-checking in JS anyway so where's the interference?

Can you give a concrete example where TS is a blocking issue for your development?

[baybal2]

If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough.

People who spent time with JS and webdev in general got to learn that JS is a minefield of a language, and they work with that in mind. Typing discipline is pretty much the first thing people learn when they try doing JS seriously.

How to say. There is no way just adding typing to JS will make JS less of a JS. You still have to be a very disciplined dev to work with a typescript for it retaining many other tricky parts from JS.

> Can you give a concrete example where typescript is a blocking issue for your development?

Typical example: the tsc transpiler plainly dies, and you know nothing how to debug it, you know nothing of its internals, and you loose the rest of the day doing fruitless email exchanges with typescript dev team, and trying to trace a breaking commit.

Second example: you got a prod breakage report in some hard to reproduce case. You fire a debugger in chrome through vscode, and then you find out that the debugger completely loses the execution flow in transpiler/tooling garbage, and broken source maps. Having a debugger pick code that went through webpack (be it cursed) is already a 50/50 lottery, and additional layer of tooling makes it even worse.

[sbergot]

Do you still put your seat belt in your car after 5+ years of driving experience? If yes, would you say that you do that because your driving skills are "plainly not good enough"?

Typescript allow you to spend less energy on minor issues like typos and more energy on design. It also provides you with the ability to reason locally about some code. When you inspect a function in js, you cannot know what are the contracts that it has to deal with. To be sure you have to unravel all the calling and called functions.

Typescript also enables better intellisense.

About your issues:

- I never had tsc dying on my hand in 5 years.

- About the transpilation noise: it can be as noisy as you want. Have you checked the default result for the es6 target? It litteraly look like your source code with only your type signatures stripped. The noise comes from the transpilation to lower versions and bundling and those are independent of typescript.

[thawaway1837]

Considering typescript compiles down to JS, and incredibly readable JS at that, the fact that your developers are unable to debug the JS directly may indicate that they are not as amazing at JS as you may believe they are.

[rpastuszak]

> If you get less bugs because of type checks and you are a serious JS/web dev with 5+ years experience, then your skills are plainly not good enough.

What about linters, static analysis, code highlighting, IDEs? Should we skip those too? Should I dig out my "made with notepad" badge?

Types and good static analysis tools allow me to focus on more important things, such as business logic, scale, planning. We don't pay developers for mental gymnastics, but solving real world problems.

[kashug]

When I am writing plain JS I often end up having to write loads of tests to check that I don't to wrong things with types. Did I remember to consider null/undefined? What if I sent in something totally different?

With TS I don't need to spend as much time with these types of tests. I just let the compiler do it for it. If my function says in it's signature the argument can't be null I don't need to do null-checks.

[williamdclt]

This is the weirdest and least convincing thing I've read about Typescript. I won't comment on such experienced devs spending so much time struggling with tooling that shouldn't change all that often, but I have to react that "fixing Typescript" means "fixing your code".

If you're saying that you can't handle the overhead of Typescript config because your devs already spend so much time struggling with the rest of your tooling, by all mean get your shit together with your tooling, this amount of time spent on it isn't any sort of acceptable. You have huge problems.

> most of devs we hire are long past the stage when typing errors are a thing for them

This is just not a thing.

[miffy900]

> https://github.com/microsoft/TypeScript/issues > Please count the number of open bugs

You do realise the large number of open issues almost certainly relates to Typescript's compiler and language implementation? When a project is written in Typescript, it does not mean all those bugs will inevitably plague the project itself. If I wrote "hello world" in Typescript with a Webpack + Babel project starter, it doesn't suddenly mean I now have thousands of open Typescript bugs to deal with.

Also: the number of closed issues outnumbers open ones by almost x5. Moreover, the total number of issues exceeds 20 thousand; the number is only so high because so many people have already adopted Typescript into their dev workflows. It's a sign it's been battle tested extensively.

> Like half of all genuine bug triage time is already spent on webpack, bable, and other things in the tooling stack. 200 hours a month for $30-$40 per hour devs.

Half? This just seems totally implausible; this could only be true if you were constantly modifying your webpack and babel setup and config files and breaking things.

[cageface]

I would never hire a JS dev with this attitude towards typescript nor work for one.

I’ve done JS with and without types. I’d find a new job before going back to working without them. That’s how dramatic the benefits have been in my code.

[smichel17]

I like going type-less for prototyping (pun intended), then converting to or rewriting in typescript for anything I'm going to need to maintain or refactor.

[blackoil]

Ratio of open/closed issue is a very strong indicator of how active a project is. My perspective, with 21k closed and 4k open issues, shows a very active project where I should not be finding major blockers if I adopt it. If it has an issue 1000s of people are actively looking at it and it will be caught at beta stage or will be solved quickly.

[MaxBarraclough]

> long past the stage when typing errors are a thing for them

Nonsense. Static type systems help you write correct code. They're also extremely helpful for refactoring. They also help readability. Outside the JavaScript world, they also help performance. The list goes on.

No-one is too smart for type systems to be helpful.

> it does not pay off at all

You've entirely ignored that TypeScript helps reduce bugs, and helps catch them earlier.

[matthewmacleod]

Typescript will not help us a dime with type checking for most of devs we hire are long past the stage when typing errors are a thing for them.

It's genuinely terrifying to think that people out there with this attitude are producing software that I might be at risk of using.

[karatestomp]

Seriously. “We manage OK without static types” is one thing but “LOL we’re not n00bs so we don’t need your productivity-killing static types” is... wow. WTF. Keep anything that team writes far away from important data and processes, please.

[SaxonRobber]

Sounds like you need to raise the bar on hiring if learning static typing is an impediment. I recommend less JS monkeys and looking for actual engineers.

[cvlasdkv]

Their 6+ year engineers are getting paid less than many interns do in America according to said poster. The big tech monopoly means that hiring good senior engineers is nearly impossible. :)

[ThePhysicist]

Why do you have to de-typify Typescript dependencies? You can mix typed and untyped code with a gradual typing approach, and tools like webpack make this very easy?

[bregma]

To be fair, cargo-cult programming is a scourge in any domain. Since the cult many folks started with when they took their college (or free online) programming course was Java, all cargo looks like Java.

[Vinnl]

> we have a problem of having to "de-typescript" a lot of 3rd party code.

What do you mean by this? npm packages at least are already "de-typescripted", in the sense that they're just .js files with accompanying .d.ts files describing the former to people using editors with TypeScript support.

(Also, it feels like you've experienced a weird subset of TypeScript code. It also happens to be an enormous help when doing things "the Javascript way", which is what it's actually designed for. But I can imagine that encountering bad apples can sour the experience for you.)

[112]

Every language comes with its own culture, and with its own stereotypes. Java's over-engineering and boredom, JavaScript's throwing shit on the wall and see what sticks, PHP's developers that do stackoverflow-driven development.

There are experts, average people, and bad people in every field. TypeScript brings sanity that is valuable for both experienced developers and less experienced developers.

The peace of mind that you get with types when doing refactoring is invaluable. I would never be able to go back and write vanilla JavaScript, because it's broken.

You can over-engineer and write crap code in any language.

Also a comment on anyone that says experienced devs get no benefit from types: you think you're good, but you're not. As good as you think you are, if you seriously deny the benefits of static typing, you're probably shit as a developer. If you understand static typing and it's benefits then you agree it's a good trade, if you don't understand it and still have a strong opinion against it, then you're just a lazy human.

[se7enzer0]

Vue 3 is not too far off and has first class TypeScript support.

[z0mbie42]

I would love to know why are you saying this.

I use Vue2 + Typescript, and for me it works great!

Even Auto-completion works.

[112]

It's OK for the most common scenarios, I didn't comment on the regular "build a web app" case, but more complicated ones. I think @vue/cli is very nice, but I've had many issues dealing with the magic behind it, so much that it became easier to swap vue-cli-service with rollup and custom setups.

I'm sure Vue3 will fix all this, and it will be awesome. Very much looking forward to it

[mcny]

I've only used angular but I'm curious, why has angular never been an option for you?

I've never used react but I think you can use typescript with react if you wanted to, right? it just isn't the default but if you're in react land, you probably don't care much for defaults?

[112]

React with TypeScript is a joy. I have the utmost respect for Angular, and for the way it pushed forward progress on frontend. Vue itself has taken many great ideas from Angular.

It hasn't been an option for me because I found it quite opinionated for personal projects, and in my work context I didn't enjoy / respect the people that were working on Angular projects. This is not about Angular, it's about where I was working and the people there.

It's easy to judge a tool by it's users, but we mustn't.

[marcus_holmes]

I use Vue without a compile step (I abuse Go's templating engine to achieve this). Mostly to avoid the security nightmare of Webpack's 434583593e4735683 dependencies (and most of the other options are not much better) so Typescript is not an option. I love that I can do this with Vue (I can't with React).

[STRiDEX]

so what you're saying is you avoid vue's poor typescript support by not using typescript

[marcus_holmes]

more like I'm prevented from enjoying Typescript's advantages by the fact that using it would require me to sign up for a vast dependency network

[izelnakri]

ember with typescript should be an option for you