3

The world would be better if the TypeScript guys knew what they could create with less complexity in any other language. Of course, if they are interested in learning. There are SPA applications out there that have more lines than Doom 3.

Comments
  • 2
    Alright then suggest an alternative
  • 0
    Yes where does it fall short as a language?
  • 4
    The designer of typescript is one of the most experienced language developers you can find, starting out with turbo pascal in the 80s, then C# and then typescript, Anders Hjelsberg.

    And its not the language fault that some pages are massive, thats on the page designers.

    Some web pags today are actually more complex than doom but much of it cones from the use of libraries and the reason there is priorities.

    Doom was coded by some of the very best developers of the time to stretch the possibilities of the computers at hand, doing things that had not been done.

    Many SPA’s are designed with another goal and compact fast code was never the most important goal but rather fast development and many features.

    Sure you could probably build the same page in 1/5 the code but you would need to hire a lot more experienced developers costing many times more for no real benefit to the company.
  • 1
    One of the things I really don't understand is how much "offending" speaking a certain language can be. In my post, I never criticized the language, but the "typescript guys". Any language that is overrated, or seen as a silver bullet ends up getting bloated. There are too many libraries with completely different cultures, adding absurd complexities to do simple things.

    Here at my company, we work with projects in several languages. And I have noticed very clearly that the applications that generate the most rework, and demand time to understand from project to project, are the SPA. Which for me is worth just a "rant" as a developer that I am, but I'm very happy with the amount of customers that have appeared asking for help and development strength because the solution has grown to the point of making the team that created it not manage to maintain more...
  • 0
    And another curious point: These SPA applications that generate so much work demand per hour, are functionally smaller than the other cases in .NET, Java, PHP and Ruby on Rails with classic rendering. That is, the metric is not mine alone, the demand for consulting and hiring per hour has grown here.

    I'm not saying that this is exclusive to TypeScript, but it's quite noticeable that there is a certain "passion" to solve everything with solutions that are "fashionable" or someone made a post saying that it is "revolutionary".
  • 0
    This happens in all languages, it seems that there is a peak of "passion" and then it stabilizes in rationality (who remembers Java + Struts? It was a mess in the early 2000s). And I notice that this is what happens with TypeScript projects today.

    Another interesting point is the amount of libraries that "break" after a short period of time. A program that compiled last year, today you'll probably have to mess with the package.json if you want to recompile it again, while for comparison, this is much rarer in a NuGet, Maven/Graddle, Conan, Composer repository. Every year I have to update some crappy library that has stopped working, which has nothing to do with the fixed functionality itself.

    So thanks for the comments. But let's stop protecting language, and wear T-shirts, and improve the quality of what is produced.
  • 0
    It sounds like your dislike is towards SPA.

    Functionally they are smaller than a server served page.

    But what about the small details?
    Like each request doesn't require an entire page refresh.

    Each component can respond to each other without passing hidden state etc.

    I actually feel like that helps a lot with keeping the code clean and isolated since my fixing of a spa component won't affect my backend code
Add Comment