4 ms·

Is It JavaScript?

55 points by todsacerdoti 1y ago

devjam 1y ago
There appears to be a link to an RFC1918 address on that page: http://192.168.4.56:5001 http://192.168.4.56:5001
- chrismorgan 1y ago
  And the three preceding links are to http: instead of https:. They should all probably be domain-relative URLs (/2019/jsx-like-…, &c.).
- jimniels 1y ago
  author here, thx for pointing these out! I was simultaneously working on some CSS for my blog on localhost and when I looked up some references to older articles to put in my post, I looked them up in the version of my site that was running locally and forgot to change the links lol. Whoops. Fixed now — thanks again!
Blackarea 1y ago
> the same, ubiquitous, standardized scripting language we all know and love: JavaScript. Sometimes the jokes just write themselves :)
- bryanrasmussen 1y ago
  I think that's supposed to be Lisp.
creesch 1y ago
I'd say that even though available APIs change based on context the premise of the "It's just JavaScript" line is more often that the syntax is still that of JavaScript. Meaning that in many ways it is much easier for someone used to browser/front-end JavaScript to start poking at a Node.js script compared to a python script with similar functionality. In that sense it is "just" JavaScript. It's still useful to point out the differences like the article does. Because it isn't as if the transition between the various JavaScript environments is seamless.
- sverhagen 1y ago
  I can agree that familiarity of the basic syntax is a decent strategy to get people over their fear of trying something new (really by making them think it isn't new at all). But it's also the lowest common denominator, and if understanding of the basic syntax is the only thing you have on offer, oh boy, are you going to meet that wall... real quick.
  - creesch 1y ago
    There is more to it. Even on different platforms there are a lot of shared APIs and principles. But yes, you still need a further understanding of the context you are now using the language in. Not to mention that you likely still need to do some further learning. But, overall I'd say it still makes it significantly easier for someone to make a switch. Even more so given the current eco system where a front-end dev likely already has node.js installed, is somewhat familiar with npm, etc. Even if we just stick to the syntax, just not having to worry about one such aspect when switching context overall shouldn't be understated as a benefit imho.
- davidmurdoch 1y ago
  Can we at least all agree that the people who ask questions about JavaScript but say "Typescript" are just wrong?
  - creesch 1y ago
    I'll give you annoying. Given that one is a superset of the other I can't say they are entirely wrong.
koito17 1y ago
The server code example has something amusing to it. const fs = require('fs'); const content = fs.readFileSync('./data.txt', 'utf8'); This code will in fact NOT run on Deno, unless one explicitly configures Deno to load JavaScript code as CommonJS. With Bun, however, this code runs without any configuration necessary. I suppose the author is intentionally not mentioning these details, since it's greatly summarized at the end of the article. JavaScript code indeed requires a great amount of context on the ambient development environment. There is a related article I recall reading last year, asserting that "JavaScript does not exist". Cannot find the article, unfortunately, so I will paraphase. The article explained how a modern development stack involves a composition of several code transformation tools. We are effectively writing in a fictitious language and pass it through a series of transformations until we finally get syntactically valid JavaScript. Off the top of my head: most people in frontend are likely using React and TypeScript. TSX files at least go through the TypeScript compiler and a plugin to transform JSX to JS. The outputted JS may have funny things like "CSS imports" or bundler-specific "magic comments" like the article's Preact example. That has to be specially handled by a bundler (like Vite) so that the JS file becomes syntactically valid JavaScript.
- dbushell 1y ago
  It’ll run via an ESM import of an NPM dependency, Deno just doesn’t allow commonjs at the top level
  - simjnd 1y ago
    The point still stands
  - koito17 1y ago
    Reading the documentation, it seems that `require` at the top-level should be possible under one of three scenarios: (1) the file extension is "cjs", (2) there is a package.json file with "type" set to "commonjs", or (3) a require function is created with createRequire https://docs.deno.com/runtime/fundamentals/node/#commonjs-support https://docs.deno.com/runtime/fundamentals/node/#commonjs-su... Seems like the code from the article will run as-is with either of the first two options. In any case, this is what I meant by Deno not being able run the code "unless one explicitly configures" it.
Vanit 1y ago
My favourite one was debugging a crash in an Electron app deployed to iOS. It turned out throwing an exception from a point event callback (deep in our app's code) was bubbling up into the device's kernel code.
- rafram 1y ago
  > an Electron app deployed to iOS Not possible, as far as I know.
  - t-writescode 1y ago
    maybe it was React Native? That does support iOS and it's close enough to "yet another Electron app" that there could be overlap in thought.
    - HumanOstrich 1y ago
      It's not close at all.
Etheryte 1y ago
You can joke about it, but there is absolutely a lot of value in the fact that you can just fire up a debugger against Electron or React or your devtools or Node itself. The "just" is doing a lot of heavy lifting here of course, but I've done all of the aforementioned at different points of my career, to reasonably good success. I don't think everything should be written in Javascript, but at times it's been very convenient that that's what's under the hood.
- davedx 1y ago
  Yes! At one early startup I worked at, one of our initial customers (we didn't have many at that point) had reported an annoying bug stopping their workflow. So one of our engineers logged into production on their tenant; replicated the bug; set some breakpoints in the Chrome debugger; worked out the cause of the bug; and then fixed it and deployed the fix within a few hours. Customer was happy. I don't think there are many languages where you can do something like that? There are some where it's maybe even better, like Smalltalk...
  - cyberax 1y ago
    You can do that with a freaking C++ and gdb. As long as you have debug symbols. Never mind pretty much all other languages.
    - davedx 1y ago
      Locally, sure. Can you do it to a C++ binary deployed at a customer?
      - spiffyk 1y ago
        Of course you can. You can attach gdbserver to a running process on the remote machine and connect to it via your local gdb. Edit: Plus, if there was a crash, you can generally get a coredump, so you can inspect the exact state the program was in, again, with GDB.
      - 5d41402abc4b 1y ago
benrutter 1y ago
I think the "javascript everywhere" phenomenon this article talks about comes from us misjudging the difficulty of learning a new language. Python's a good example of this (or at least its one I use every day). In order to be able to keep using Python at larger scales, it's become a very big, complex language. Sometimes I wonder if a lot of use cases for typed Python would be better matched by starting out in a typed language like Go in the first place. In some ways, learning a new language can be easier than learning lots and lots of features of an increasingly complex language.
- t-writescode 1y ago
  Maybe. But the cognitive load of learning a new language (and programming correctly in that language) is real. And even more real is the emotional stress and mental turmoil a person faces when they're required to learn something new rather than pick up something familiar. When someone has deadlines, a home life, strong demands from their boss, familiarity with build pipelines, a team full of people that they can call on, etc, it's often easier to keep the stress and confusion count lower by sticking to the familiar. Especially when, in cases like Python with types or Java with Lombok and "just one more thing" will "fix" the rough edges or difficult scenarios that the those specific developers have. Sure it's "one more step", but it's probably a small one and one they can reason about without having to upend their entire mental model (even if in practice they might not need to).
spiffyk 1y ago
You could also write the same piece about pretty much any language, by the way. "Is it C?" – there is a big difference between C on Linux, C on Windows, C on an embedded chip doing real-time shenanigans... "Is it Java?" – Desktop? Server? Android? Java ME? A CREDIT CARD?!? The list goes on...
hsn915 1y ago
The "It's just JavaScript, so the frontend guys can work on the backend" line has never made any sense to me. I think it's aimed at HR/recruiting. Companies tend to think in terms of specific skills when hiring. Something like: We use PostgreSQL, so we will write "3 years PostgreSQL experience" in the job description for a senior backend engineer position. Unless engineering is explicitly involved in the hiring process, HR will drop your resume automatically if you say "5 years of MySQL and SQLite experience" with no mention of Postgres.
- quectophoton 1y ago
  > Unless engineering is explicitly involved in the hiring process, HR will drop your resume automatically if you say "5 years of MySQL and SQLite experience" with no mention of Postgres. I found this the hard way during these last 2 years. They might give you the benefit of the doubt if you have led teams before, but if that's not the case, your application is going to the bottom of the list because you don't match exact keyword and have a big number next to it.
  - hsn915 1y ago
    This has been the case since the early 2000s, and much earlier too, probably. I had thought the industry has matured by now, but nope, still running the same old scripts!
quectophoton 1y ago
Classic communication mistake is assuming what people mean when they say $LANGUAGE. Some people mean the language itself, others mean language + standard library, others mean language + standard library + tooling, others mean language + standard library + tooling + ecosystem. The same people could be meaning different things at different times depending on what's in their mind at the moment.
- davidmurdoch 1y ago
  Only one if those people is correct.
sambeau 1y ago
Typescript is not just javascript; Javascript is just Typescript. /pedantry
alexp44 1y ago
[flagged]
alexp44 1y ago
[flagged]
killerstorm 1y ago
React introduces absolutely insane level of complexity: * you no longer know when code is executed - it's magic * state can be managed in ~5 different ways, with a lot of ceremony and idiosyncrasies It is, absolutely, an eDSL (`useState` & `useEffect` introduce new semantics using JS syntax), and a proper DSL would be a lot easier to learn.
- valenterry 1y ago
  > you no longer know when code is executed - it's magic Kind of. That is what makes react a framework and not a library in my opinion. That being said, it's still learnable and managable (in pure react). > state can be managed in ~5 different ways, with a lot of ceremony and idiosyncrasies Not a valid argument. Just use react state and be done with it. If you go for anything on top, well yeah. But to be honest, other frameworks have the same problem, even in the backend. > It is, absolutely, an eDSL (`useState` & `useEffect` introduce new semantics using JS syntax), and a proper DSL would be a lot easier to learn. That is absolutely true and a valid point. It's mostly a shortcoming of javascript/typescript where it would be too annoying to pass down dependencies/props in a long chain of elements. So in an insufficient programming language you have the choice between typesafety+verbosity (react without hooks) or conciseness+unsafety (hooks are not typesafe, they are not regular functions and hence can't be refactored like them etc.). Basically, they break composibility. Honestly, the frontend world circles around that problem and every blue moon something things they found the enlightenment and then they give up the previous benefits for new benefits. And the circle repeats. I wonder if maybe effect.website might be able to change that in the future. It has the potential.
  - SoKamil 1y ago
    > It's mostly a shortcoming of javascript/typescript where it would be too annoying to pass down dependencies/props in a long chain of elements Do you know a language that has solution to this on a language level? The only similar thing I can think of are dynamic vars in Lisp. At a quick glance they remind me of React Context.
    - 1y ago
manbitesdog 1y ago
That's the issue with any abstraction I'd say. I know English, but I can't properly give legal advice based on regulations written in English. There is one more layer of human conventions besides the "English language" convention that I'd need to learn. I'd say the point to be made is that debugging a library is way simpler than debugging a framework like React (even though they insist on calling it a library) because your code is no longer the entrypoint but some intermediate step in the logic.
CharlieDigital 1y ago
People who think JavaScript is easy have made a big mistake. There are multiple build chains to pick from. Multiple package managers each with nuances. Every need (e.g. ORM, logging) has multiple options to choose from each with some shortcoming you won't discover until you are deep into it. It has vulnerability types that do not exist on other platforms. The language is easy and flexible, but the platform as a whole and ecosystem is a mess if you want to ship enterprise grade software. The moment you realize the need to define meta types on the BE (Zod, class-validator, etc) is the moment you should just start transitioning to a runtime typed language because you've realized "Actually, runtime types are kinda nice". Many teams realize this too late and are stuck in JS hell which infects everything the team does and creates drag at scale. It creates drag in the CI because you need more checks and the tooling itself is slow. It creates drag in the DX because I have to restart the TS language server multiple times a day. It creates drag in the platform config because it's spaghetti to get things working and it's slow to build at scale. For FE, it's hard to avoid. For BE...why do it to yourself if you know you're not building a toy? Yes, I build JS backend, but it's fine for my side projects. Great even! For real, high value work? It is a mistake every time because it requires much more babysitting than almost anything else.
techlatest_net 1y ago
[dead]

Is It JavaScript?

55 points by todsacerdoti 1y ago

devjam 1y ago

There appears to be a link to an RFC1918 address on that page: http://192.168.4.56:5001 http://192.168.4.56:5001

chrismorgan 1y ago
And the three preceding links are to http: instead of https:. They should all probably be domain-relative URLs (/2019/jsx-like-…, &c.).
jimniels 1y ago
author here, thx for pointing these out! I was simultaneously working on some CSS for my blog on localhost and when I looked up some references to older articles to put in my post, I looked them up in the version of my site that was running locally and forgot to change the links lol. Whoops. Fixed now — thanks again!

Blackarea 1y ago

> the same, ubiquitous, standardized scripting language we all know and love: JavaScript. Sometimes the jokes just write themselves :)

bryanrasmussen 1y ago
I think that's supposed to be Lisp.

creesch 1y ago

I'd say that even though available APIs change based on context the premise of the "It's just JavaScript" line is more often that the syntax is still that of JavaScript. Meaning that in many ways it is much easier for someone used to browser/front-end JavaScript to start poking at a Node.js script compared to a python script with similar functionality. In that sense it is "just" JavaScript. It's still useful to point out the differences like the article does. Because it isn't as if the transition between the various JavaScript environments is seamless.

sverhagen 1y ago
I can agree that familiarity of the basic syntax is a decent strategy to get people over their fear of trying something new (really by making them think it isn't new at all). But it's also the lowest common denominator, and if understanding of the basic syntax is the only thing you have on offer, oh boy, are you going to meet that wall... real quick.
- creesch 1y ago
  There is more to it. Even on different platforms there are a lot of shared APIs and principles. But yes, you still need a further understanding of the context you are now using the language in. Not to mention that you likely still need to do some further learning. But, overall I'd say it still makes it significantly easier for someone to make a switch. Even more so given the current eco system where a front-end dev likely already has node.js installed, is somewhat familiar with npm, etc. Even if we just stick to the syntax, just not having to worry about one such aspect when switching context overall shouldn't be understated as a benefit imho.
davidmurdoch 1y ago
Can we at least all agree that the people who ask questions about JavaScript but say "Typescript" are just wrong?
- creesch 1y ago
  I'll give you annoying. Given that one is a superset of the other I can't say they are entirely wrong.

koito17 1y ago

The server code example has something amusing to it. const fs = require('fs'); const content = fs.readFileSync('./data.txt', 'utf8'); This code will in fact NOT run on Deno, unless one explicitly configures Deno to load JavaScript code as CommonJS. With Bun, however, this code runs without any configuration necessary. I suppose the author is intentionally not mentioning these details, since it's greatly summarized at the end of the article. JavaScript code indeed requires a great amount of context on the ambient development environment. There is a related article I recall reading last year, asserting that "JavaScript does not exist". Cannot find the article, unfortunately, so I will paraphase. The article explained how a modern development stack involves a composition of several code transformation tools. We are effectively writing in a fictitious language and pass it through a series of transformations until we finally get syntactically valid JavaScript. Off the top of my head: most people in frontend are likely using React and TypeScript. TSX files at least go through the TypeScript compiler and a plugin to transform JSX to JS. The outputted JS may have funny things like "CSS imports" or bundler-specific "magic comments" like the article's Preact example. That has to be specially handled by a bundler (like Vite) so that the JS file becomes syntactically valid JavaScript.

dbushell 1y ago
It’ll run via an ESM import of an NPM dependency, Deno just doesn’t allow commonjs at the top level
- simjnd 1y ago
  The point still stands
- koito17 1y ago
  Reading the documentation, it seems that `require` at the top-level should be possible under one of three scenarios: (1) the file extension is "cjs", (2) there is a package.json file with "type" set to "commonjs", or (3) a require function is created with createRequire https://docs.deno.com/runtime/fundamentals/node/#commonjs-support https://docs.deno.com/runtime/fundamentals/node/#commonjs-su... Seems like the code from the article will run as-is with either of the first two options. In any case, this is what I meant by Deno not being able run the code "unless one explicitly configures" it.

Vanit 1y ago

My favourite one was debugging a crash in an Electron app deployed to iOS. It turned out throwing an exception from a point event callback (deep in our app's code) was bubbling up into the device's kernel code.

rafram 1y ago
> an Electron app deployed to iOS Not possible, as far as I know.
- t-writescode 1y ago
  maybe it was React Native? That does support iOS and it's close enough to "yet another Electron app" that there could be overlap in thought.
  - HumanOstrich 1y ago
    It's not close at all.

Etheryte 1y ago

You can joke about it, but there is absolutely a lot of value in the fact that you can just fire up a debugger against Electron or React or your devtools or Node itself. The "just" is doing a lot of heavy lifting here of course, but I've done all of the aforementioned at different points of my career, to reasonably good success. I don't think everything should be written in Javascript, but at times it's been very convenient that that's what's under the hood.

davedx 1y ago
Yes! At one early startup I worked at, one of our initial customers (we didn't have many at that point) had reported an annoying bug stopping their workflow. So one of our engineers logged into production on their tenant; replicated the bug; set some breakpoints in the Chrome debugger; worked out the cause of the bug; and then fixed it and deployed the fix within a few hours. Customer was happy. I don't think there are many languages where you can do something like that? There are some where it's maybe even better, like Smalltalk...
- cyberax 1y ago
  You can do that with a freaking C++ and gdb. As long as you have debug symbols. Never mind pretty much all other languages.
  - davedx 1y ago
    Locally, sure. Can you do it to a C++ binary deployed at a customer?
    - spiffyk 1y ago
      Of course you can. You can attach gdbserver to a running process on the remote machine and connect to it via your local gdb. Edit: Plus, if there was a crash, you can generally get a coredump, so you can inspect the exact state the program was in, again, with GDB.
    - 5d41402abc4b 1y ago

benrutter 1y ago

I think the "javascript everywhere" phenomenon this article talks about comes from us misjudging the difficulty of learning a new language. Python's a good example of this (or at least its one I use every day). In order to be able to keep using Python at larger scales, it's become a very big, complex language. Sometimes I wonder if a lot of use cases for typed Python would be better matched by starting out in a typed language like Go in the first place. In some ways, learning a new language can be easier than learning lots and lots of features of an increasingly complex language.

t-writescode 1y ago
Maybe. But the cognitive load of learning a new language (and programming correctly in that language) is real. And even more real is the emotional stress and mental turmoil a person faces when they're required to learn something new rather than pick up something familiar. When someone has deadlines, a home life, strong demands from their boss, familiarity with build pipelines, a team full of people that they can call on, etc, it's often easier to keep the stress and confusion count lower by sticking to the familiar. Especially when, in cases like Python with types or Java with Lombok and "just one more thing" will "fix" the rough edges or difficult scenarios that the those specific developers have. Sure it's "one more step", but it's probably a small one and one they can reason about without having to upend their entire mental model (even if in practice they might not need to).

spiffyk 1y ago

You could also write the same piece about pretty much any language, by the way. "Is it C?" – there is a big difference between C on Linux, C on Windows, C on an embedded chip doing real-time shenanigans... "Is it Java?" – Desktop? Server? Android? Java ME? A CREDIT CARD?!? The list goes on...

hsn915 1y ago

The "It's just JavaScript, so the frontend guys can work on the backend" line has never made any sense to me. I think it's aimed at HR/recruiting. Companies tend to think in terms of specific skills when hiring. Something like: We use PostgreSQL, so we will write "3 years PostgreSQL experience" in the job description for a senior backend engineer position. Unless engineering is explicitly involved in the hiring process, HR will drop your resume automatically if you say "5 years of MySQL and SQLite experience" with no mention of Postgres.

quectophoton 1y ago
> Unless engineering is explicitly involved in the hiring process, HR will drop your resume automatically if you say "5 years of MySQL and SQLite experience" with no mention of Postgres. I found this the hard way during these last 2 years. They might give you the benefit of the doubt if you have led teams before, but if that's not the case, your application is going to the bottom of the list because you don't match exact keyword and have a big number next to it.
- hsn915 1y ago
  This has been the case since the early 2000s, and much earlier too, probably. I had thought the industry has matured by now, but nope, still running the same old scripts!

quectophoton 1y ago

Classic communication mistake is assuming what people mean when they say $LANGUAGE. Some people mean the language itself, others mean language + standard library, others mean language + standard library + tooling, others mean language + standard library + tooling + ecosystem. The same people could be meaning different things at different times depending on what's in their mind at the moment.

davidmurdoch 1y ago
Only one if those people is correct.

sambeau 1y ago

Typescript is not just javascript; Javascript is just Typescript. /pedantry

alexp44 1y ago

[flagged]

alexp44 1y ago

[flagged]

killerstorm 1y ago

React introduces absolutely insane level of complexity: * you no longer know when code is executed - it's magic * state can be managed in ~5 different ways, with a lot of ceremony and idiosyncrasies It is, absolutely, an eDSL (`useState` & `useEffect` introduce new semantics using JS syntax), and a proper DSL would be a lot easier to learn.

valenterry 1y ago
> you no longer know when code is executed - it's magic Kind of. That is what makes react a framework and not a library in my opinion. That being said, it's still learnable and managable (in pure react). > state can be managed in ~5 different ways, with a lot of ceremony and idiosyncrasies Not a valid argument. Just use react state and be done with it. If you go for anything on top, well yeah. But to be honest, other frameworks have the same problem, even in the backend. > It is, absolutely, an eDSL (`useState` & `useEffect` introduce new semantics using JS syntax), and a proper DSL would be a lot easier to learn. That is absolutely true and a valid point. It's mostly a shortcoming of javascript/typescript where it would be too annoying to pass down dependencies/props in a long chain of elements. So in an insufficient programming language you have the choice between typesafety+verbosity (react without hooks) or conciseness+unsafety (hooks are not typesafe, they are not regular functions and hence can't be refactored like them etc.). Basically, they break composibility. Honestly, the frontend world circles around that problem and every blue moon something things they found the enlightenment and then they give up the previous benefits for new benefits. And the circle repeats. I wonder if maybe effect.website might be able to change that in the future. It has the potential.
- SoKamil 1y ago
  > It's mostly a shortcoming of javascript/typescript where it would be too annoying to pass down dependencies/props in a long chain of elements Do you know a language that has solution to this on a language level? The only similar thing I can think of are dynamic vars in Lisp. At a quick glance they remind me of React Context.
  - 1y ago

manbitesdog 1y ago

That's the issue with any abstraction I'd say. I know English, but I can't properly give legal advice based on regulations written in English. There is one more layer of human conventions besides the "English language" convention that I'd need to learn. I'd say the point to be made is that debugging a library is way simpler than debugging a framework like React (even though they insist on calling it a library) because your code is no longer the entrypoint but some intermediate step in the logic.

CharlieDigital 1y ago

People who think JavaScript is easy have made a big mistake. There are multiple build chains to pick from. Multiple package managers each with nuances. Every need (e.g. ORM, logging) has multiple options to choose from each with some shortcoming you won't discover until you are deep into it. It has vulnerability types that do not exist on other platforms. The language is easy and flexible, but the platform as a whole and ecosystem is a mess if you want to ship enterprise grade software. The moment you realize the need to define meta types on the BE (Zod, class-validator, etc) is the moment you should just start transitioning to a runtime typed language because you've realized "Actually, runtime types are kinda nice". Many teams realize this too late and are stuck in JS hell which infects everything the team does and creates drag at scale. It creates drag in the CI because you need more checks and the tooling itself is slow. It creates drag in the DX because I have to restart the TS language server multiple times a day. It creates drag in the platform config because it's spaghetti to get things working and it's slow to build at scale. For FE, it's hard to avoid. For BE...why do it to yourself if you know you're not building a toy? Yes, I build JS backend, but it's fine for my side projects. Great even! For real, high value work? It is a mistake every time because it requires much more babysitting than almost anything else.

techlatest_net 1y ago

[dead]