Hacker News new | ask | show | jobs
by Ankintol 2022 days ago
I think many JS developers are also somewhat blind to the breadth of types of sites that are written, and so don't understand how valuable a type system can be on the web.

Most websites are what I'd call "broad and shallow". For any individual action the corresponding code path is small. Most code in these sites is easy to write and easy to debug in vanilla JS. Typescript adds boilerplate and compiler times for type safety the development team was doing fine without.

However there are some sites, usually very complex SPAs, that are necessarily "deep". Even small user actions absolutely must cause >10k lines of code to run. Type systems are often very valuable for the development of such sites.

It's my experience that some developers who've only ever worked on "broad and shallow" sites fail to appreciate what a time saver a type system can be for the right "deep" website.

2 comments

In before someone comments: "But chances are you are not the person who needs something as complicated as TS therefore it's useless." and "If your code is more than a thousand lines then you're doing it wrong, all code should be <1000 lines that you throw out immediately and replace with new code".
I'd guess I'd have to question why you need 10K lines of code for a single web page - perhaps you need to break up your SPA?
Because applications on the web are increasingly that -- full applications.

I create scientific models and simulations for use in schools. Whether it's simulating a hurricane, or continental drift, electronics, or molecular interactions, the simulations themselves need to run on the browser, and all the UI that provides the users with all the affordances to interact with the model needs to also be written in JS/TS.

I think your questions are just revealing a failure of imagination/experience for what kinds of applications run on the web these days.

Hmm - I think that's my point - it's no longer the web is it - just a way to deliver traditional applications.

I can see if you want to write an Excel in the web - that you might have a complex code base - but surely that's the exception - not the rule?

So back to the statement of 'modern web = ts'

Isn't that wrong - these applications aren't really web - and are the exception, not the norm?

> it's no longer the web is it - just a way to deliver traditional applications

This statement is meaningless to me. What makes it "no longer the web?"

"The web" now includes fully-fledged applications. It's fine to make a distinction between things that are full applications and things that are close to blogs, if you like, but it doesn't change the fact that many people develop full applications for the web.

And I think this is clearly a lot more common you are recognizing.

The fact you ask this question gets at my point I think.

For several years I've been writing a large computer algebra system(CAS) that runs on a webpage. Every time the user puts some input into a text box the CAS runs. Depending on the input it may run as many as ~40k lines of code. There are no coherent lines upon which to split the CAS as far as anyone developing it can tell.

The CAS must run on the browser both to deliver on real time performance requirements and to keep server costs manageable (certain inputs will get even high end CPUs humming).

If breaking this SPA up is possible, it's not apparent even to engineers with >10 years of experience developing highly complex applications.

Other similarly complex applications run on the web, even if it's unusual.

The trick is to not break it up. Adding more lose ends will just make the ball of twine more complicated. What you can break out though is independent code that is the same for many apps, that code can be made into a module and reused across apps. Pure mathematical functions can be turned into a library.

But what could probably help keep your sanity for a CAS is to add a test case for every change to make sure the same input produce the same output in the future. As well as performance tests to avoid performance regressions.

I totally agree, we do all of these things. It was just a little less clear early on in the project what the best structure for the project was :)
Do you think the Zoom web client should have fewer than 10k lines? Or be broken up? What about Google Docs?
Aren't those the exception and not the rule.

Hence the statement modern web = ts is wrong.

Personally I used the zoom native client and not the web one.

I spend most of my time in offline office and not the web version

I don't run windows 7 - so the zero day issue wouldn't have been a problem.

That's like saying don't use the web version cos your out of date browser can be exploited.