• @rstoenescu Thanks for that. Keep us informed. Typescript is the way go for serious js work.

  • Typescript is the way go for serious js work.



  • To manage a large amount of source code base, you need all the help you can get.

    By using typescript you get a language that looks and feels like JS, but with lovely static type checks, templates and nice transpiling abilities.

    I will recommend it any day, even for small projects, it is really worth it !

  • @druppy static vs dynamic typing is really a matter of personal preference. Here is a good list of advantages/drawbacks.

  • I didn’t mean to make this a “static/ dynamic typing” war, but let’s look at those static typing advantages.

    Better design - being forced to think about the types of values in your software up front can push you towards cleaner, more logical solutions. (I say can - it’s still possible to design really bad code…)
    Better compile time checking - static typing can enable more errors to be caught at compile time. This is a huge advantage, and is arguably the best thing about statically typed languages overall.
    Auto-completion - static typing can also give more information to the IDE so that auto-completion of code or documentation lookup is more effective.
    Discourages hacks - you have to keep type discipline in your code, which is likely to be an advantage for long term maintainability.
    Type inference - in some languages (e.g. Scala) this can get you many of the conciseness benefits of dynamic languages will still maintaining type discipline.


  • Thanks @s-molinari that saved a lot of arguments 🙂 As @LaurentPayot say it is sometime a question of taste, but I really find static typing a bit more useful than just the subjective value (I am working on my 3. large JS project now :-))

    Typescript grows on you (on me at least), the more you trust (and understand) it the more it will and can help you, but you can start out not using types at all for a start and go from there.

    I know that the static typing idea (regardless of language) at first can feel like a straitjacket (it will need initial attention, and start pick at you code), but when the compiler starts finding dumb bugs that saves you hours or even days of debugging, it feels more like an old friend, that help you on your way, but … it also tells you the truth strait away (like old friends are supposed to) 🙂

    As for me, as soon as a peace of code grow to more than 300 lines, I start wishing for types regardless of this being bash, python or javascript, this could be personally taste or my lake of huge amount of short term memory, but regardless of the reason static types helps me being productive.

  • Hmm…my post is not what I wanted to post. Buggers. At any rate, I wanted to ask, how about Flow? Seems like it is a step above TS since it can help with type inference at first and adding all the type definitions can be done later or as we need it.


  • I can’t remember last time I had an error caused by a wrong type, in Python or Javascript. I use verbs for my function names, I prefix my boolean variable names by “is”, etc. Sometimes I check the parameter types in the first lines of a complex function to prevent misuse. And that’s all and it saves me a lot of “noise code” that static typing induces.

    PS: if you want to start another war, I proudly indent with TABS 😄

  • To go back to the testing subject, just like @Martin I use Firebase . Because this is a serverless architecture I simply use Mocha with Firebase admin sdk for my Firebase-related unit tests: user CRUD and so. It’s a nice combo with codeceptjs for e2e testing.
    I do not test the view layer (Vue) because I don’t think it’s worth the (huge) effort.

  • @s-molinari I didn’t know Flow, I’m going to give it a try. Thanks for the link @MusicForMellons .

  • @LaurentPayot - yeah. I am not really begging here at all to get any type system going. In fact, I am more like you in my thinking. To me a type system is a crutch for the “not-so-careful” or “not-so-experienced” or those afraid of JS’s dynamic capabilities and them being so odd compared to stricter typed languages. Type checking can, however, contribute to what many say is a better developer experience. I personally haven’t used TS or Flow enough to say “yup. That is correct.” And, good design, programming and testing can offer a nice developer experience too. 😉


  • @LaurentPayot We are all very different in our way of thinking, and I must just again realize, that we all choose tools that emphasize our strong sides, and supports ours weak ones.

    For me, and most of the ones I have worked with, strong types (typescript in this case) have been a great help (I also work in C++) 🙂

    I have seen coffeescript and flow, but I like the fact that TS follows ES standards so closely, as it makes it easy to reason about and easy to introduce to new people.

  • I had a look and the good thing about flow is that it automagically warns you when you mix types without changing your code. That’s the best of both worlds. Unfortunately for me it doesn’t work with Coffeescript 2.0 …

  • Flow sounds really nice too, but I have invested way to much time in Typescript to make the change now 🙂

  • I was under the impression Flow was like TypeScript, just with the added benefit of having a better type inference and also no transpiling (aka “blazing fast”). This article makes a pretty good sell of it all.



  • I am trying to test with webpack-karma, I tried some configurations and now I am stucked here:

    [122] ./node_modules/util/node_modules/inherits/inherits_browser.js 672 bytes {0} [built]
    + 108 hidden modules

    ERROR in ./node_modules/babel-loader/lib!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./src/components/Hello.vue
    Module not found: Error: Can’t resolve ‘quasar’ in ‘/home/mateu/VueProjects/sails1/cima20js/assets/frontend/src/components’
    @ ./node_modules/babel-loader/lib!./node_modules/vue-loader/lib/selector.js?type=script&index=0!./src/components/Hello.vue 3:0-203
    @ ./src/components/Hello.vue
    @ ./src/test/components/hello.Spec.coffee

    ERROR in ./src/test/components/hello.Spec.coffee
    Module not found: Error: Can’t resolve ‘quasar’ in ‘/home/mateu/VueProjects/sails1/cima20js/assets/frontend/src/test/components’
    @ ./src/test/components/hello.Spec.coffee 3:0-27
    24 08 2017 06:01:03.673:INFO [karma]: Karma v1.7.0 server started at
    24 08 2017 06:01:03.674:INFO [launcher]: Launching browsers PhantomJS, Firefox with unlimited concurrency
    24 08 2017 06:01:03.724:INFO [launcher]: Starting browser PhantomJS
    24 08 2017 06:01:03.739:INFO [launcher]: Starting browser Firefox
    24 08 2017 06:01:04.101:INFO [PhantomJS 2.1.1 (Linux 0.0.0)]: Connected on socket vhe0wjpMOy2tMBa0AAAA with id 74984205
    24 08 2017 06:01:05.869:INFO [Firefox 55.0.0 (Ubuntu 0.0.0)]: Connected on socket 5AWcaU3_5W61T549AAAB with id 91018619

    Thank you for your help.
    By the way, thankyou for made quasar possible is what I was waiting for

  • Hello There Quasar Community
    I was working the last days integrating some Testing for Quasar Framwork, I Know there is some difficulties there, This is a little project am sharing with you guys, Your comments, I’ll be very happy to hear them thanks 🙂

  • @kais Thank you for your contribution. I’ve found it very helpful to get unit and e2e started. Is this work you’ve done still considered covered under the MIT licensing that the original Quasar is under?

Log in to reply