5 ms·

At the risk of being downvoted into Hades, I feel that if your project is complex enough to warrant using Typescript, its complex enough to warrant using a more

• crooked-v 8y ago
  What other languages would you recommend for frontend web development, given that you'll still need a build pipeline and so on?
  • ajxs 8y ago
    My post was directed at back-end development in Typescript/Javascript. My apologies if that wasn't clearer. I don't really have any experience in front-end development in Typescript, so I can't really comment on that. It could be a real improvement there for all I know.
  • fxfan 8y ago
    While your parent clarifies that he meant for backend- ill suggest trying one off bucklescript, Scala.js or elm. They are all very well done and have wide adoption actually
• voidreaper 8y ago
  Other than Ruby and PHP, I've only really worked with JS/TS on the backend. Which strongly-typed programming language would you recommend on the backend?
  • ajxs 8y ago
    Depending on what it is you're doing, I feel that .net and Java are far superior choices. Obviously these are pretty heavy languages, so obviously decide for yourself whether the size of your app justifies using a language like this. My thoughts run along the lines of: "If people are justifying using Typescript because their projects are large and critical, they're probably large and critical enough to use a language designed for enterprise-scale development." I personally haven't used Go, but I've heard good things about its use in this domain too.
    • cmiles74 8y ago
      I would like to second this. This idea that everything will move more quickly if the same language is used on the client and server sides is compelling. But .Net or Java have been on the server side a long time, there are projects for which they are well suited.
  • smt88 8y ago
    TypeScript is very easy to use with Node. You can also use the debugger in WebStorm with it just fine, and you'll be stepping through your TS code instead of your generated JS code. The problem is really the Node ecosystem, which is a mess and a circus of security issues. Deno[1] may fix most of JS/Node's problems eventually. For now, if you want a type system that's comparable to TS with a great ecosystem, the best you can get is either F# or Kotlin. If you're not a fan of ML, then you might want to start with Kotlin. 1. https://github.com/denoland/deno https://github.com/denoland/deno
• dhab 8y ago
  I am not sure about other languages, but I have been programming in Java for many years, and Typescript does what Java does (minus performance on a long running VM on CPU bound computations) at a rate that I assume should be sufficient for most (business) apps, without any bloat. Can you elaborate on promise fatigue. In our setup we use async/await and the latest ES (although most of us prefer not using decorators if we don't have to - only used it with mobx for UI code) bundled through webpack. I am not sure what you mean by poor eco-system either. Both JS and TS (increasingly), I feel like is the second best eco-system (in terms of libraries and tooling) after a mainstream language like Java. There are some warts I think in JS (around numbers, stream handling in pipes), but I think very few languages don't, and it depends on how likely you would be fiddling in those areas. Extra tax on build pipeline cannot be escaped for anything with any complexity. I feel like anyone who can write a complex app in good js, refactoring along the way at good speed, and meeting deadlines along the way and not introducing too many regressions, and come back and maintain it after a 6 month context switch, either has way too much time on his hands and/or works too many hours, or is much more smarter than I am and has it figured out.
  • ajxs 8y ago
    I've had too many terrible experiences having to maintain and work with buggy and poorly designed Node/Typescript packages. I'm especially thinking of the terrible choice of ORMs available for Node, Typescript in particular. TypeORM seems the de-facto standard and my experiences with it have been horrific. It looks like Hibernate but works like a dumpster fire. There isn't anything as robust as ORMs like EF or Hibernate for Node. I feel that the shortcomings of the NPM community have been pointed out one too many times, but on too many occasions I've felt that development of a product was made much harder by the choices of poorly developed frameworks as dependencies.
    • slaymaker1907 8y ago
      The ORM was your first mistake. They almost always get in the way and are way more complex than the relatively simple language (SQL) they are intended to abstract over.
    • 8y ago
• sonnyblarney 8y ago
  " Issues like Promise-fatigue" Actually, async-await is a nice feature of the JS paradigm that simplifies things and that I miss in the threaded world of Java. But yes - use TS where you would have used JS, but TS up against other, more classical languages may not be the right choice for a lot of non-web projects.
  • hombre_fatal 8y ago
    Yeah, it's a strength in my book. Node makes it trivial to sequence asynchronous tasks, stuff you may be juggling in a server route. You can start this promise early, await two parallel DB request + one API request, branch off some more async work depending on a response, await that initial promise that had a head-start because now you actually need it, and then run 10 tasks with no more than 3 in-flight at a given moment. And the code would look exactly how I just described it. And it's ubiquitous. It's a good tool in the belt and imo the most trivial async implementation out there.
• jwilliams 8y ago
  I'm just jumping into TypeScript after a decent break from production coding. Prior to this break it was Rails, well before that Java. In my own Hades moment -- Microsoft know how to build great developer tools. The developer ergonomics of TypeScript and Visual Studio Code are excellent. It's really quite surprising to see how far the JavaScript world has come. Similarly, the DevOps world is becoming much (much) more JavaScript friendly. Serverless, Netlify, and things like AWS Amplify -- all with their foibles, but pushing JavaScript in meaningful ways. I don't think this is the case for many other languages/ecosystems.
  • ajxs 8y ago
    I would actually agree with your statement about Typescript and vscode. Working with TS has actually been quite pleasant as far as getting up and running goes. I only ever had to consult the docs a handful of times, and each time my questions were easily answered.
• sandGorgon 8y ago
  True, because you cannot avoid JavaScript. If you are building a new web startup, most likely you are going to write a LOT of React/frontend code. So it makes absolute sense to write the backend in the same language...if you can. Typescript goes a long way in making this pleasant. Nothing is stopping you from writing the backend in different language...but as an organization, you lose the advantage of shared thinking in one stack.
• bloomca 8y ago
  > Promise-fatigue JavaScript actually handles async IO nicely, and I've never heard this term before (callback hell, yes). So promises and async/await sugar actually make it pretty nice. > poor ecosystem Ecosystem is fine, just don't jump on everything new. The well-known problem is standard library, it is indeed a problem, usually addressed with a mix of additional packages. > For the extra tax you pay in terms of build pipeline This pipeline is norm in the frontend development, so in case you have people proficient in tooling, it is not that high (of course, it is hard if you have Java developers). > Typescript vs Javascript as if these are the only two possible options for web development They are not, but the nice thing about it is that you can have almost the same tooling as on your frontend, if you have some sort of complex application. So that increases speed of development, and TypeScript gives you some sense of scalability. Last part is that TypeScript can be adopted incrementally, while another languages will require complete rewrite (and different deployment, etc).
  • bgorman 8y ago
    Other langauges can be adopted incrementally as well e.g. ReasonML and Clojurescript. I am not sure how you concluded that other languages need a different deployment. On the front end everything gets delivered to the browser...
  • ajxs 8y ago
    I actually just made the term up myself just then to describe my feelings about the fact that all of the methods in our service layer are just `await this(); await that(); await another(); //...` and so on. Please be aware that this post is describing my own experiences in back-end web-app development using Node. I feel I'm courting more controversy here, but if you're using `async/await` ad-nauseum your app might not actually be as async as you think it is. Of course this is a godsend compared to the callback hell that it replaced, but I can't help feeling that this is the right solution to the wrong problem. In my experience, most of the server-side applications I've seen written in Node are only practically asynchronous at the router level. Once you get into the controllers they tend to become entirely procedural and effectively completely synchronous. With the exception of the rare `Promise.all(...).then(...)`.... If you're using `await` on every single function call, it stops being syntactic sugar and just becomes more syntactic salt.
• fxfan 8y ago
  That's why there are compile-to-Js languages that see widespread adoption. Elm, bucklescript, Scala.js to name a few.
  • nickbauman 8y ago
    ... Clojurescript. A React app is 10x more complicated than a Reagent app. http://reagent-project.github.io/ http://reagent-project.github.io/
    • fxfan 8y ago
      In the following code segment, the `[:div` `[:p` et al- are the reagent or clojurescript? ``` (defn simple-component [] [:div [:p "I am a component!"] [:p.someclass "I have " [:strong "bold"] [:span {:style {:color "red"}} " and red "] "text."]]) ```
• steve_adams_86 8y ago
  Part of the appeal of TypeScript is that you could fairly easily migrate a team to it from JavaScript if they're all fairly comfortable and competent with the current JS ecosystem. For most JS devs I've worked with, this wouldn't be true with a language like C# or Kotlin. I'd argue that buying into a more comprehensive language would probably be worth it if everyone was into it, but in my own experience JS devs really, really like JS and have very little interest in learning something better suited to the problem they're solving. This is true outside of software too. People love familiar tools and methods, even if they aren't the best ones. There's also the fact that your team's output will be best based on their enjoyment and engagement. Even if the tooling isn't perfect, they'll probably build better software if they're enjoying it. JS and TS are good enough in most cases to get teams where they need to be.
• estebanquito 8y ago
  Poor ecosystem? Have you used web frameworks like Express/Koa + a good linter + a modern IDE (e.g. VS Code) and of course npm? It's a breeze working with those tools. Productivity skyrockets and if you think a little bit about your design decisions then typescript (plus the proper support for it) gives you a huge hand in writing correct code from the first try. I think that if you want your opinion to be taken seriously you should propose an alternative. I would be interested to see a better ecosystem.