Ask HN: Why isn't JavaScript long-lasting?

4 pointstroubledandlost4y ago6 comments

Why is it apparently perceived as a "dayfly development language"? JS has an ISO standard like C and SQL. Yet, only C, SQL, Lisp and the SDL API are recommended[1] for the long run (>= 20 years).

So why can't I expect a JavaScript program with HTML5, CSS3 and Vue.js to last me for at least 20 years much like C89 and SDL? What's the issue here? I don't get it, since JS, HTML and CSS are standardized (like Lisp, C and SQL).

Relevant discussion keywords: Web Assembly

Reference:

1. I cannot find the URL anymore, but this blog had Jonathan's article linked: https://jonathanwhiting.com/writing/blog/games_in_c/

Anyhow, the gist was: use C and SDL to make your programs future proof.

2. There was also a website article suggesting that you should stay away from JavaScript if you want to have long-lasting websites. Instead, it suggested that you should stick with HTML and CSS.

I cannot also find the link to this anymore, but it was linked on HN.

3. https://www.johndcook.com/blog/2017/08/19/programming-language-life-expectancy/

4. http://www.bricklin.com/200yearsoftware.htm

5. https://softwareengineering.stackexchange.com/questions/333487/developing-web-applications-for-long-lifespan-20-years

6. https://news.ycombinator.com/item?id=22042186

6 comments

codeptualize4y ago

Few arguments for JS: - It has beaten quite a few contenders on the web: Java applets, Flash, Silverlight

- It's not owned by a single company who can kill it

- It has evolved (a lot) over time while maintaining backward compatibility

- It has caught up with compile to JS languages that gained traction (coffee script)

- It has only gained traction over time (now it's on the server, it's on mobile, it's everywhere)

- It might not be as old as C, but it's quite old

- Typescript, the most popular compile to JS language atm only adds types, the big claim is "All valid JavaScript code is also TypeScript code." so can we really claim it's not JS?

- There is a huge amount of code in JS, many apps and a big percentage of website run on JS. It will take decades to move all of that to something else, meaning support will exist even if something else comes along.

- Everyone has been hating on it for two decades and it's still going strong haha.

Frameworks and libraries will change, (build) tools will change, JS will evolve, compile to JS languages will change, new languages will pop up, but JS will not go anywhere for a long long time.

jfengel4y ago

That's how it was originally designed. The main use case was quickie animations and simple interactions on the web. Web Apps were not a thing. That was all supposed to be done in Java.

It didn't turn out that way, and a ton of stuff has been backfilled into Javascript to make up for that: modules, classes, just-in-time compilers, frameworks, etc. This was all done in a somewhat half-assed fashion, leaving a ton of warts and buried land mines.

Javascript suffers from being too flexible (a thing it inherits from its Lisp-like origins). It's easy to work around problems, so everybody does. Differently. Those solutions come and go, and code written for one becomes Linear B.

By the time you get to Typescript you have a decent language with the possibility of code that can be read, not just written. But the effect is an enormous language and even enormouser language ecosystem. Whole paradigms have come and gone -- jquery, Angular 1, a host of old bundlers -- but of course they never disappear. New code is still written, and only maintainable by the people who wrote it.

svennek4y ago

I think mostly because of two things:

1) Imho an overly complex ecosystem (with thousands of dependencies via npm or such)

2) The "oh my god, that is 5 weeks old, there is something new, better..." mindset for JS-projects.

For long-term software slow velocity is a feature that has to be balanced carefully against stagnation... and not the "reckless" advancement that JS (and kubernetes for that matter) enjoys...

Most C-compiler-suites and most SQL-database move slowly, but move...

troubledandlostOP4y ago

Good point, but when I purposefully limit the amount of dependencies and use dependencies that have no dependencies (like Vue.js), can I make my web app long-lasting that way (like I can with C89 and SDL)?

IOW: is there an issue with (vanilla) JS despite it being a standardized language?

svennek4y ago

Likely, but you probably also depend on a browser... OTOH html5 seems quite backwards compatible and stable

avoidwork4y ago

centralized vs distributed; it's an outdated straw man. microsoft is ironically a proprietor the problems you get from misusing web tech in a centralized app (ie).

j / k navigate · click thread line to collapse

Ask HN: Why isn't JavaScript long-lasting?

4 pointstroubledandlost4y ago6 comments

Why is it apparently perceived as a "dayfly development language"? JS has an ISO standard like C and SQL. Yet, only C, SQL, Lisp and the SDL API are recommended[1] for the long run (>= 20 years).

Relevant discussion keywords: Web Assembly

Reference:

1. I cannot find the URL anymore, but this blog had Jonathan's article linked: https://jonathanwhiting.com/writing/blog/games_in_c/

Anyhow, the gist was: use C and SDL to make your programs future proof.

2. There was also a website article suggesting that you should stay away from JavaScript if you want to have long-lasting websites. Instead, it suggested that you should stick with HTML and CSS.

I cannot also find the link to this anymore, but it was linked on HN.

3. https://www.johndcook.com/blog/2017/08/19/programming-language-life-expectancy/

4. http://www.bricklin.com/200yearsoftware.htm

5. https://softwareengineering.stackexchange.com/questions/333487/developing-web-applications-for-long-lifespan-20-years

6. https://news.ycombinator.com/item?id=22042186

6 comments

codeptualize4y ago

Few arguments for JS: - It has beaten quite a few contenders on the web: Java applets, Flash, Silverlight

- It's not owned by a single company who can kill it

- It has evolved (a lot) over time while maintaining backward compatibility

- It has caught up with compile to JS languages that gained traction (coffee script)

- It has only gained traction over time (now it's on the server, it's on mobile, it's everywhere)

- It might not be as old as C, but it's quite old

- Typescript, the most popular compile to JS language atm only adds types, the big claim is "All valid JavaScript code is also TypeScript code." so can we really claim it's not JS?

- Everyone has been hating on it for two decades and it's still going strong haha.

Frameworks and libraries will change, (build) tools will change, JS will evolve, compile to JS languages will change, new languages will pop up, but JS will not go anywhere for a long long time.

jfengel4y ago

That's how it was originally designed. The main use case was quickie animations and simple interactions on the web. Web Apps were not a thing. That was all supposed to be done in Java.

svennek4y ago

I think mostly because of two things:

1) Imho an overly complex ecosystem (with thousands of dependencies via npm or such)

2) The "oh my god, that is 5 weeks old, there is something new, better..." mindset for JS-projects.

For long-term software slow velocity is a feature that has to be balanced carefully against stagnation... and not the "reckless" advancement that JS (and kubernetes for that matter) enjoys...

Most C-compiler-suites and most SQL-database move slowly, but move...

troubledandlostOP4y ago

IOW: is there an issue with (vanilla) JS despite it being a standardized language?

svennek4y ago

Likely, but you probably also depend on a browser... OTOH html5 seems quite backwards compatible and stable

avoidwork4y ago

centralized vs distributed; it's an outdated straw man. microsoft is ironically a proprietor the problems you get from misusing web tech in a centralized app (ie).

j / k navigate · click thread line to collapse