[HN Gopher] Don't write web apps in anything other than TypeScript
___________________________________________________________________
Don't write web apps in anything other than TypeScript
Author : gablg1
Score : 8 points
Date : 2023-12-12 22:06 UTC (55 minutes ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| henriquez wrote:
| I think TypeScript on the frontend and JavaScript on the backend
| is workable. Most modern frontend frameworks are TypeScript-
| native, and you really benefit from a lot of the hand-holding
| that the real-time static analysis + your framework extensions in
| VSCode provide.
|
| On the other hand, in most cases backend code is dumb and simple;
| in basically every company I've worked for it's an API that just
| does CRUD stuff through an ORM to the database. There's not a
| whole lot that can go wrong if you keep package dependencies
| light and JavaScript is just a simpler option. You can even use a
| basic text editor if you're a real pro.
|
| I disagree with the article that it's such a vastly different
| build environment or developer required. Different tools for
| different jobs works fine for me.
| gemanor wrote:
| Writing JS/TS for browsers and backend applications is an
| entirely different skill. The only similarities are syntax. From
| the organization's perspective, the developer's primary expertise
| is a platform/framework, not a language syntax.
|
| The point of the article is right for the indie developer who
| wants to stick with one language as a "mother language" and be
| able to produce any kind of software in no time. For scale, it is
| not the case.
|
| I'm a big fan of JS/TS, but there are absolutely significantly
| better choices for many backend applications.
| pavel_lishin wrote:
| I don't disagree with the general premise of this post, but:
|
| > _Two different types of engineer your company has to hire for_
|
| That's going to be the case anyway. React and front-end work in
| general has gotten pretty damned specialized; if you want your
| front-end to look good, to work well, to be responsive, and to
| not be a garbled mess, you're going to need people who specialize
| in front-end work.
|
| > _A third API language to serve as an interface between frontend
| and backend (GraphQL, REST, SOAP, pick your poison)_
|
| You're going to need this regardless. And pretending that
| https://trpc.io/ (whatever it is) is somehow different from
| GraphQL, REST, etc in terms of having to learn a technology is a
| joke that doesn't land.
| m0llusk wrote:
| Having over 30 years of experience in delivering applications
| this is kind of amusing in how it shows how trends come and go.
| In the past dynamic typing was hot stuff that enabled great
| progress. Here we have another big trend.
|
| It can be useful, but it seems like just more preference. The
| reason that strong typing is useful is that development groups
| have weak definitions and understandings of their data flow,
| their documentation is scant if it exists at all, and their test
| are woefully short of robust. So strong typing ends up being
| necessary, especially when developing always at top speed with
| chaotically dynamic teams. But unfortunately, the fact that you
| think you know what type some data is doesn't really tell you all
| you need to know about where it came from, how sure you can be it
| really is that type, and how you can know it is the specific data
| that you want for your business logic. It helps, but to really
| get development under control it will be necessary to define,
| document, and test data flows to a level that makes strong typing
| unnecessary and potentially even irrelevant.
|
| When I hear this kind of statement from a developer I know that
| they are better at clinging to what are essentially religious
| beliefs than they are at coding solutions that will be
| consistently useful for users.
___________________________________________________________________
(page generated 2023-12-12 23:01 UTC)