27 ms·

JavaScript is a great browser scripting language because it's the only browser scripting language. That's a whole realm of good times, and people can and shoul

by DrFell 5y ago

JavaScript is a great browser scripting language because it's the only browser scripting language. That's a whole realm of good times, and people can and should go nuts with it there. The problem started a decade or so ago with Node. Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser. ECMAScript is a general purpose standard, but it was invented retroactively. Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. That's just too much of a force fit, and has wasted too much potential for me to say anything positive about it.

austincheney 5y ago
There are a couple of things that JavaScript got so incredibly correct: * Lexical scope natively without syntax or conventions * Functions as first class citizens * Inheritance, classes, OOP are not forced on you and can be ignored/omitted entirely from your code Those few things are what has kept me hooked on the language. > Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser.
- galangalalgol 5y ago
  That last bullet is my main complaint with java and c#.
  - wvenable 5y ago
    C# just removed the requirement to start code with a class or a main method; you can just start typing into the file.
    - metaltyphoon 5y ago
      I like this so much. In fact they are investigating the idea of #!/usr/bin/dotnet on a .cs file!
- titzer 5y ago
  > * Lexical scope natively without syntax or conventions I assume you mean over the alternative, dynamic scoping like in e-Lisp. But you realize that JavaScript's scoping rules are entirely wonky, e.g. that "var" declarations are lifted to the function level?
  - austincheney 5y ago
    To be more specific the term is hoist which means the declarations are pushed to the top of the scope at run time for maximum availability, and var is function scoped instead of block scoped. Block scoping is often more specific because a function body is a block as well.
  - errantspark 5y ago
    Right but we have `let` now which solves that problem.
    - titzer 5y ago
      Not completely, `let` also has a weird temporal dead zone[1], which is basically a dynamic check. [1] https://www.freecodecamp.org/news/what-is-the-temporal-dead-zone/ https://www.freecodecamp.org/news/what-is-the-temporal-dead-...
      - IshKebab 5y ago
        That's a good thing, and I'm not sure what you mean about it being a dynamic check.
        titzer 5y ago
        It's a dynamic error if you access a let-bound variable before it is actually initialized. In most other languages that have lexically-scoped declarations, it simply would not be visible. So I think JS's choice is actually a regression.
  - hwillis 5y ago
- hollerith 5y ago
  >a couple of things that JavaScript got so incredibly correct: . . . Lexical scope natively without syntax or conventions What language of the last 28 years doesn't "natively" lexically scope its variables?
  - z3t4 5y ago
    JavaScript is different in that it use the function as the lexical scope rather then the angel brackets. This forces you to think about the code as functions, rather then blocks. And in turn helps you think of the code in three dimensions where time is one dimension, making it easier to understand code that runs asynchronously.
    - z3t4 5y ago
      Because people coming from other languages find this confusing the let (and const) keyword was specified (ES6/2015) for block/angel-bracket lexical scope. Whereas var is function scoped.
  - icedchai 5y ago
    Not Javascript. If I forget a var or let, it's global.
    - austincheney 5y ago
      Strict mode throws an error on implied globals. Use of modules forces strict mode.
      - icedchai 5y ago
        And that's all "extra" syntax.
        JoyrexJ9 5y ago
        strict mode is the default in everything now and had been for many many years.
- dclowd9901 5y ago
  And here I thought scope was kind of disaster in JS: - `const fooFunc = () => {}` is treated differently than `function fooFunc() {}` in declaration and subsequent access. - A function's invocation context changes depending on how it was declared (fat arrow vs. function declaration) Don't get me wrong: I love JS, but this is not one of the things I felt made it intuitive.
  - austincheney 5y ago
    The this context changes, but I recommend developers not use this. That isn’t a scope issue though.
  - mweberxyz 5y ago
    There would be no point in having two ways to do the exact same thing if function-style declaration and arrow-style declaration implementations were identical. Why would they add a new feature to the language if it was purely syntactic sugar?
- senthil_rajasek 5y ago
  >> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. >What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser. I have taken the privilege of rewriting the quoted part of the parent comment, Node runs javascript on the server side in an engine built for the browser. It does not run ECMAScript with an engine specially made for server side apps.
- wernercd 5y ago
  And those things are outweighed by things JavaScript got so incredibly wrong... like === vs == and some of the weirdness when you GASP use == as any other language would do. JS is like PHP... only a popular language because it's been around a long time and it's easy to get started. Otherwise, there are SOOO many better programming language out that the ONLY reason JS still has traction is it became the "default" web language.
- IshKebab 5y ago
  This comment is so weird. JavaScript got scoping completely wrong, and none of those were particularly novel when it was designed and they are almost universal now so I don't know why they would keep you hooked on JavaScript! Maybe try some other languages...
nerdponx 5y ago
From my perspective (mostly a Python user), Javascript is a fine language for general-purpose scripting and server dev, and Node is more than fast enough to handle typical workflows. Why do you think it's not a good language for this? Also, I see a lot of value in using a one single language that can truly do everything: frontend, server, and scripting. I guess you could use Python or Ruby like that with Wasm, but I haven't seen evidence of people doing that.
- lanstin 5y ago
  Like JavaScript, one can argue that the only thing wrong with node is the ecosystem/developer community. Things like npm as just not curated enough given the large number of JavaScript developers and the attendant variability in quality of output. Node itself is an almost perfect call-back driven even loop for Unix network io, which till go and go routines/channels was the conceptually simplest way to use the CPUs you are paying for, saturate the network, and have subtle threading issues. (Python gevent was also good at that, but had more implicit magic which is bad for reasoning about code). But I am hopeful that when I finish reading the article I will not have to reuse my jquery / d3 based framework for doing quick data viz things (which I only started doing with great reluctance because people don’t go wow over tabular data even if the data is wow-ing. The first request to make it pretty, i switched to mono space fonts. But jquery is showing its age.
zackify 5y ago
What I’m hearing is: Because the language wasn’t planned to support all of this from the start, we just shouldn’t use it. There’s lots of great reasons to use a full JS / TS stack. There’s lots of reasons not to. Doesn’t mean it’s inherently bad. This is the same logic used against PHP every day yet it’s used all over.
overgard 5y ago
10 years ago I would have agreed with you, but in recent years Javascript (and moreso Typescript) are just exceedingly pleasant to use. I'm using Typescript in backend services despite knowing Python and C# well just because I like it.
- vletal 5y ago
  I can imagine that the original argument does not apply to the languages which compile to JS. But IMO the fact that there is so many derived languages covering the mess which JS is only supports the argument against it.
  - nicoburns 5y ago
    TypeScript is just JavaScript with type annotations. The runtime semantics are identical. JavaScript itself has improved to the point where it's great to work with, and arguably the nicest of the common dynamically types "scripting" langauges (python, ruby, PHP, perl).
    - gmac 5y ago
      Completely agree. I used to work mainly in Ruby, and I guess I miss its rich standard library, but overall TypeScript is such a joy to work with that now I use it for almost everything.
believeinskills 5y ago
Well I know plenty of people that are similar to me in that in our early years, we asked for resources and help, and the response that was constantly given was "use what you know," which was bad advice for people who made websites who were looking to program. It's no wonder Javascript is the only thing used. I actually love React and ES because it's the first time I feel like a real programmer and not someone just writing Javascript. I don't really care about people's opinions about JS, I simply use what works. If you hated Javascript, maybe the anit-javascript community should have wrote blogs, made videos, and created content in the same way that the Javascript community did.
bastawhiz 5y ago
> Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser. Do you have any evidence for this? Because there's plenty of reasons why you'd share the same code in the browser and the server. Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules? I have a site builder codebase that renders previews instantly as you make changes, then uses the same code on the server to render the HTML and CSS for visitors. That would be otherwise be outright impossible to do without writing the same code again in another language.
- gls2ro 5y ago
  Here is my perspective: There are plenty of reasons to use the same language on FE and BE but for me the main problem is the JS standard library. Let me give you one example: Lets say you want to validate if a string is a valid URL. What is a good way to do this in JS? Just for reference in Ruby for example I can do: URI.parse(input).kind_of?(URI::HTTP) No gems or any other engines needed.
  - hoten 5y ago
    The URL constructor.
    - gls2ro 5y ago
      Oh wow, how I missed that. I stand corrected! Seems like JS standard library is better than I thought.
- zozbot234 5y ago
  > Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules? PHP is adding support for FFI to any C ABI-compatible language, and you can run the exact same code in the browser via emscripten or a WASM polyfill. As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript.
hn_throwaway_99 5y ago
Couldn't disagree more. I was a Java programmer for my entire career until about 2015 or so when I switched to Node, and shortly thereafter to TypeScript. I've commented this many times before, but having a system where everything is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains, especially for a small team where it's trivial for people to cross front end to back end seamlessly. For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly. Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring. JavaScript most definitely has its warts and head scratchers after being around for 25 years, but I feel like most of these oddities (truthy/falsey, typeof null === 'object', undefined vs. null, etc.) can be learned in an hour and written on a half page.
- creshal 5y ago
  > For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS Is there any Typescript backend framework as mature as Django? > Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly. So on the on hand, the languages are "quite similar", yet it cannot possibly be expected that frontend people learn more than a single language? Something doesn't add up here.
  - spiderice 5y ago
    You are interpreting GP’s comment very uncharitably, to the point that it actually becomes a completely incorrect interpretation. GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.” There ARE big advantages to having the exact same language (as opposed to similar languages) on both client and server, especially in an SPA where you want to render something initially on the server, but then update it using the same logic later on the client.
koonsolo 5y ago
> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. Why would your custom ECMAScript server be any faster or more stable than any of the existing browser engines? If you look at the resources behind those engines, I don't know who would match that effort doing the same on the server.
- paulryanrogers 5y ago
  My guess is the browser JS engines are optimized for quick compilation and execution. While a backend engine could optimize for longer, persist runtime.
yashap 5y ago
TypeScript is a pretty good language for writing web servers, as long as you don’t need to do computationally heavy parallel computing. And you can still do that, but it’s very awkward. I’ve done plenty of backend work in all of TS, Scala, Go, Python and PHP. Scala is my personal favourite, but it’s not as practical for teams as TS or Go, which are both very productive languages, with good enough type safety and performance, that new devs can learn quickly. And I’d easily choose TS over PHP or Python for a large system. Plus, it IS pretty nice being able to use a single language everywhere. My current company is TS RESTful services with TS/React on the web, and TS/React Native on mobile, pretty hard to beat how easy it is to do full stack dev work for most ppl in this setup.
- SavantIdiot 5y ago
  > computationally heavy parallel computing. JS has no parallel computing support, so it is not an option. And when I say parallel computing, I don't mean distributed computing, I mean utilizing hundreds (thousands) of cores on a single die, like NVIDIA architectures. (It's a black art, even addition algorithms can confuse the newcomer.) The best course is to do what every other language does when it comes to simple-parallel operations, like Gauss-Jordan elimination: use a dedicated, optimized library, like NumPY. I really hope some day there will be a numpy for JS. NumJS is dead, and Google's TensorFlowJS is excellent for utilizing GPUs, but a dog when trying to do simple operations (the load/store async nature doesn't quite fit with most use cases.) I suspect WebAsm will facilitate the parallel nature of tensor operations without having to move
  - lhnz 5y ago
    It sounds like you want something a bit like WebGPU: https://gpuweb.github.io/gpuweb/ https://gpuweb.github.io/gpuweb/
    - SavantIdiot 5y ago
      Close, but I don't want to have to switch memory models, e.g. upload/download. What I want is the incredibly diverse numerical computing support and logical syntax of NumPY but in the same process & memory space. The W3C endeavor is something a little different. Thanks tho!!
grishka 5y ago
ActionScript is also an ECMAScript language, and it's kinda ridiculous to see that JS still hasn't quite caught up. Out of things that modern JS lacks, AS had Java-like interfaces and you could specify types on variables. (Yes, I know about TypeScript.)
- benrbray 5y ago
  As someone who first learned to code with AS2/3, I agree it was quite disorienting when I first tried to make a few games with HTML5/JS. I do think you're not giving TypeScript enough credit -- I felt right at home the first time I used TS, and the type system is much more sophisticated than anything ActionScript ever had. As long as you're of the "favor composition over inheritance" mindset, which I'd argue is better, even for games, TypeScript is a fantastic spiritual successor to ActionScript! Unfortunately there's no TypeScript-based game engine that makes it so easy to combine code with animations / sound. Nothing has really filled the void that Flash left behind.
SavantIdiot 5y ago
NodeJS is important for more reasons than "it's just JavaScript". It is asynchronous from the bottom-up, and it is literally a challenge to force asynchronous patterns into a synchronous ones, which is almost always a hack because async requires a lot of thought. This is a boon to IIoT control, where the pejorative "web server" is literally the endpoint for 10's of thousands of IoT edge nodes. NodeJS fits in with this architecture perfectly compared to the shoehorning required to make it work with PHP, (C/C++), Python or Java. (N.B.: I am not a java programmer, but we did review using Java, too, but it was voted down for other reasons.) If there is another asynchronous language that is as well defined as NodeJS and has as much library support, I would very much like to study it.
- ripe 5y ago
  This. I grew up with Lisp and Smalltalk, yeah I am that old, but today I love Node to build web apps. It’s a fantastic environment for asynchronous programming. It also has a built-in REPL for a management interface via TCP or Unix sockets. It doesn’t really need any additional packages (I hate the dependency hell that npm saddles you with, and people don’t seem to know that Node already has http, https, and websocket upgrades built in, so you often don’t need any “frameworks” or libraries). Give me Node, and I can build an entire web app from scratch. Most of the time you don’t even need to use JS in the browser. Just html and CSS are enough. Web apps the way God intended. I don’t use Typescript either. Its type checking isn’t worth the hassle of poor tooling and inscrutable stack traces.
  - SavantIdiot 5y ago
    IMHO, TypeScript is only useful if you are using a build tool because it requires so much configuration. I switched to WebPack for very large Electron projects and I'm hooked on it. The syntactic sugar protects me from myself, and the importing is cleaner. I also finally made the switch to VSCode, which while bloated and awkward to configure, is pretty dang amazing when working correctly w.r.t. linting and code inspection. Lot's of projects are popping up using ElectronJS, which is Node+Chromium. I have written many, and they are literally write-once-run-everywhere. Node serialport and node libusb have some speed issues on macOS, but require literally no alteration, utterly seamless. The idea as "Node is just web" is dead in the water. Hugely popular ElectronJS(Node) apps are: * Saleae - An inexpensive logic analyzer - https://www.saleae.com/ https://www.saleae.com/ * Balena - a flash programmer for SDmicro and USB drives - https://www.balena.io/etcher/ https://www.balena.io/etcher/ * BetaFlight Configurator - the seminal drone (quad/hex/octo) configuration tool - https://github.com/betaflight/betaflight-configurator https://github.com/betaflight/betaflight-configurator [FYI: Python is far, far behind in packaging cross-platform apps and requires gigabytes of support libraries. People complain about Electron size, but they are only comparing it to native apps.]
franklampard 5y ago
I am professional who used python, Java in my Career, and TypeScript is simply the best. “Too many people only learn JavaScript, become psychological dependent o it “ is simply a false narrative from people who are stuck with obsolete web dev tech stack and refuse to learn better tools
vmception 5y ago
This is wrong lol. V8 changed the whole paradigm. Thinking of Javascript as still just a browser language is the flaw.
Pfhreak 5y ago
> The problem started a decade or so ago with Node. What problem, specifically? People enjoy writing Javascript. It has a ton of fantastic resources online, it is easy to debug and deploy, it's quick to pick up and forgiving of mistakes. > Too many people only learn JavaScript, become psychologically dependent on it You sound like Immortan Joe warning people not to become dependent on water in Mad Max. Let people enjoy the language they enjoy developing in. > they all collectively took it too far outside of a browser. What does this even mean? What's "too far" even mean? People want to write code, let them?
colordrops 5y ago
Unbelievable that this is voted to the top on Hacker News. The comment literally gives not one concrete example or reason by JavaScript is "bad". I'd expect more from you all here.
- whostolemyhat 5y ago
  This happens every time a Javascript topic comes up - hundreds of comments just regurgitating the same "Javascript is bad" memes. It's bad enough that's there's no real point in reading the comments on JS submissions since there's rarely discussion about the article.
cultofmetatron 5y ago
Couldn't agree more. I started in this field as a javascript programmer. I've since expanded my toolkit to include typescript, elixir, plpgsql and now gaining proficiency in rust. I'm continually frustrated by my colleagues refusal to step outside the javascript ecosystem. Don't get me wrong, JS certainly has its place but its not ALWAYS the best tool for the job. I see a lot of people reach for node as their go to backend tech choice simply because its the ONLY tool in their toolbox. Unless you're building a small focused microservice where the functionality involves calling out to a library with working tested code that does what you want, I think node is honestly a poor choice. To qualify my statement, I spent the first 7 years of my professional career building software with nodejs. The sweet spot is much smaller than the scope of projects people throw at it. * quick MVP? rails has more libraries that are drop in. * Performance? go and elixir have node beat for multicore perf * websockets? compared to phoenix channels, everything in node for serving websocket apis are a toy. Lambda functions though? yea nodejs kicks but there!
Kiro 5y ago
The only reason I'm using node.js is because I can do this: let num = 0; route('/url').post(data => num++); What other languages can I do this in that are better? I simply want to have a variable I can access and mutate from inside closures and let it live in memory without the need for databases or file systems.
- merb 5y ago
  every language?
  - ptx 5y ago
    To be fair, threads complicate things.
    - merb 5y ago
      yeah but most languages have stuff like Atomic integers or other things.
      - Kiro 5y ago
        I want a language where it's as natural as my example above, and normally an object or array so the integer was just to simplify the example. Do you have any suggestions? I want to declare a variable and then be able to access/modify the same variable through a closure in a callback for incoming requests, so I guess that requires it to be single-threaded. (I'm using this for game state where it's very convenient to just declare a persistent data structure in code directly without without having to use any additional abstraction.)
        merb 5y ago
        well without atomic access your state would be wrong. there are languages that allow stuff like that, but if you do it you can still have the wrong number. i.e. in c# something like you wrote is possible but when getting multiple requests, the number might be wrong at the end. you always have some tradeoffs because in your case when you would run it with a multi threaded js engine your variable would be as broken as the c# one. that's why java does not allow it by default to modify a variable inside a thread that is declared outside.
bennysomething 5y ago
I don't know what's wrong with me. I hate JavaScript. I tried learning react and redux and just gave up. All this to put a button and a field on a page. React was basically invented by John carmack to do doom 3 and copied to render web pages. Is this really required!? It's not a 3d games engine. I've worked on web apps that require a lot of page updates per minute and I still hate react. I stay the hell away from front end web Dev as it just feels like hell. Sorry drunken rant. Edit: I also worked on a node app that should have been written in a staticall typed language. Bugs that could have been caught at compile time literally caused me utter misery in on call overtime. All because some guy in our team demanded we wrote it in node. This was way before type script. I actually feel physical pain thinking about.
- adamscybot 5y ago
  Perhaps give it another try, but with TypeScript. Im a front end dev and yes, I feel the JS pain. I look back at how I used to do things and think "wtf". TS completely changed this and brought it back to sanity.
  - hajile 5y ago
    I’m pretty sure the real issue is backend vs UI rather than JS/HTML. If you’ve worked with a few alternatives, the web suddenly doesn’t look too bad. Sure, a couple solutions are probably nicer, but they are mostly platform locked and way slower to develop on. UI programming is literally the fine art of handling what your most exasperating client is capable of inflicting on your UI. I suspect this is the core complaint.
- bobthepanda 5y ago
  at least part of the problem is that Javascript and webdev have really low barriers to entry, which is positive in the sense that anyone can do it, but the problem is that anyone can reach that unhappy valley of knowledgeable enough to do a lot of damage without realizing it. If you put bad developers on other languages they usually end up running into some wall first but Javascript is pretty forgiving.
- schwartzworld 5y ago
bdcravens 5y ago
> it's the only browser scripting language IE did support VBScript, and only finally "killed" it in 2019 https://blogs.windows.com/msedgedev/2019/08/02/update-disabling-vbscript-internet-explorer-windows-7-8/ https://blogs.windows.com/msedgedev/2019/08/02/update-disabl...
axegon_ 5y ago
What makes matters worse is that javascript is being pushed as the golden standard language and replacing pseudocode. In recent years I've stumbled across multiple articles on serious topics and concepts such as complex algorithms for compression or image processing and two scrolls down and I see an implementation in javascript. insert ragequit gif here
- elliotec 5y ago
  So what? It's an incredibly productive language that CAN DO "complex algorithms for compression or image processing." It's accessible, popular, easy enough to use, and ubiquitous. All the ingredients for success. Does it belong on mission-critical spaceships? Whether you like it or not, the answer is yes, of course it does. https://os-system.com/blog/javascript-in-space-spacex-devs-have-shared-crewdragons-tech-stack/ https://os-system.com/blog/javascript-in-space-spacex-devs-h...
  - axegon_ 5y ago
    The fact that you can put a 900 bhp engine in a 40 year old rusty Citroen, doesn't make it a good idea(JavaScript being the Citroen). There's a good reason why operating systems are written in low level languages and not toy languages that are meant to make sites jiggle. JavaScript is just a convenient excuse to write slow, horrible, unreadable and unmanageable code without having people pointing it out because no one expects JavaScript to be anything other than an endless mess of spaghetti. Even in the case of space x is just a tool for shiny buttons and that's it. That still doesn't make it a good idea. Some time ago I saw in a video that the Audi entertainment system is written in typescript and as much as Audis are great cars, the entertainment system feels painfully clunky compared to a cheap 120 euro Android phone. JavaScript and node are horrible technologies that should be abolished and replaced by something that doesn't require a 14-core Xeon and 32gb of RAM to run semi-decently.
  - fitpolar 5y ago
    So what, is that not everyone loves it. Devs shouldn’t be forced to use a language that they hate using. Thankfully WASM is a remedy for this, and over the next decade devs will be able to build full stack across web and mobile in Swift or any other language they prefer.
travisgriggs 5y ago
Don't do much JS, but this is actually what makes me the most sad. My formative programming years were during an era where there were many competing technologies on most given platforms. Now days, if I do mobile iOS, I have to do Swift, Kotlin for Android, and as you say JS for browsers. I wish we lived in a world where the platform didn't design the stack so much.
z3t4 5y ago
JavaScript does not have a monopoly in web browsers. Microsoft supported vbScript and Google made a better and faster JavaScript (Dart) which also ran natively in the browser. But neither didn't take off. You can still "compile" for the browser though, the funny thing is that a lot if not most of the code running on the most popular web sites has gone through at least one compile step. So people don't actually program in JavaScript, it has become more of a compilation target.
- pseudalopex 5y ago
  Most browsers didn't support VBScript or Dart. TypeScript and JSX are the most popular languages that compile to JavaScript as far as I know. They're very close to JavaScript because people learned straying too far created problems.

by DrFell 5y ago

austincheney 5y ago

There are a couple of things that JavaScript got so incredibly correct: * Lexical scope natively without syntax or conventions * Functions as first class citizens * Inheritance, classes, OOP are not forced on you and can be ignored/omitted entirely from your code Those few things are what has kept me hooked on the language. > Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser.

galangalalgol 5y ago
That last bullet is my main complaint with java and c#.
- wvenable 5y ago
  C# just removed the requirement to start code with a class or a main method; you can just start typing into the file.
  - metaltyphoon 5y ago
    I like this so much. In fact they are investigating the idea of #!/usr/bin/dotnet on a .cs file!
titzer 5y ago
> * Lexical scope natively without syntax or conventions I assume you mean over the alternative, dynamic scoping like in e-Lisp. But you realize that JavaScript's scoping rules are entirely wonky, e.g. that "var" declarations are lifted to the function level?
- austincheney 5y ago
  To be more specific the term is hoist which means the declarations are pushed to the top of the scope at run time for maximum availability, and var is function scoped instead of block scoped. Block scoping is often more specific because a function body is a block as well.
- errantspark 5y ago
  Right but we have `let` now which solves that problem.
  - titzer 5y ago
    Not completely, `let` also has a weird temporal dead zone[1], which is basically a dynamic check. [1] https://www.freecodecamp.org/news/what-is-the-temporal-dead-zone/ https://www.freecodecamp.org/news/what-is-the-temporal-dead-...
    - IshKebab 5y ago
      That's a good thing, and I'm not sure what you mean about it being a dynamic check.
      - titzer 5y ago
        It's a dynamic error if you access a let-bound variable before it is actually initialized. In most other languages that have lexically-scoped declarations, it simply would not be visible. So I think JS's choice is actually a regression.
- hwillis 5y ago
hollerith 5y ago
>a couple of things that JavaScript got so incredibly correct: . . . Lexical scope natively without syntax or conventions What language of the last 28 years doesn't "natively" lexically scope its variables?
- z3t4 5y ago
  JavaScript is different in that it use the function as the lexical scope rather then the angel brackets. This forces you to think about the code as functions, rather then blocks. And in turn helps you think of the code in three dimensions where time is one dimension, making it easier to understand code that runs asynchronously.
  - z3t4 5y ago
    Because people coming from other languages find this confusing the let (and const) keyword was specified (ES6/2015) for block/angel-bracket lexical scope. Whereas var is function scoped.
- icedchai 5y ago
  Not Javascript. If I forget a var or let, it's global.
  - austincheney 5y ago
    Strict mode throws an error on implied globals. Use of modules forces strict mode.
    - icedchai 5y ago
      And that's all "extra" syntax.
      - JoyrexJ9 5y ago
        strict mode is the default in everything now and had been for many many years.
dclowd9901 5y ago
And here I thought scope was kind of disaster in JS: - `const fooFunc = () => {}` is treated differently than `function fooFunc() {}` in declaration and subsequent access. - A function's invocation context changes depending on how it was declared (fat arrow vs. function declaration) Don't get me wrong: I love JS, but this is not one of the things I felt made it intuitive.
- austincheney 5y ago
  The this context changes, but I recommend developers not use this. That isn’t a scope issue though.
- mweberxyz 5y ago
  There would be no point in having two ways to do the exact same thing if function-style declaration and arrow-style declaration implementations were identical. Why would they add a new feature to the language if it was purely syntactic sugar?
senthil_rajasek 5y ago
>> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. >What does that even mean? The APIs are completely unrelated and Node does different things that don’t make sense in the browser. I have taken the privilege of rewriting the quoted part of the parent comment, Node runs javascript on the server side in an engine built for the browser. It does not run ECMAScript with an engine specially made for server side apps.
wernercd 5y ago
And those things are outweighed by things JavaScript got so incredibly wrong... like === vs == and some of the weirdness when you GASP use == as any other language would do. JS is like PHP... only a popular language because it's been around a long time and it's easy to get started. Otherwise, there are SOOO many better programming language out that the ONLY reason JS still has traction is it became the "default" web language.
IshKebab 5y ago
This comment is so weird. JavaScript got scoping completely wrong, and none of those were particularly novel when it was designed and they are almost universal now so I don't know why they would keep you hooked on JavaScript! Maybe try some other languages...

nerdponx 5y ago

From my perspective (mostly a Python user), Javascript is a fine language for general-purpose scripting and server dev, and Node is more than fast enough to handle typical workflows. Why do you think it's not a good language for this? Also, I see a lot of value in using a one single language that can truly do everything: frontend, server, and scripting. I guess you could use Python or Ruby like that with Wasm, but I haven't seen evidence of people doing that.

lanstin 5y ago
Like JavaScript, one can argue that the only thing wrong with node is the ecosystem/developer community. Things like npm as just not curated enough given the large number of JavaScript developers and the attendant variability in quality of output. Node itself is an almost perfect call-back driven even loop for Unix network io, which till go and go routines/channels was the conceptually simplest way to use the CPUs you are paying for, saturate the network, and have subtle threading issues. (Python gevent was also good at that, but had more implicit magic which is bad for reasoning about code). But I am hopeful that when I finish reading the article I will not have to reuse my jquery / d3 based framework for doing quick data viz things (which I only started doing with great reluctance because people don’t go wow over tabular data even if the data is wow-ing. The first request to make it pretty, i switched to mono space fonts. But jquery is showing its age.

zackify 5y ago

What I’m hearing is: Because the language wasn’t planned to support all of this from the start, we just shouldn’t use it. There’s lots of great reasons to use a full JS / TS stack. There’s lots of reasons not to. Doesn’t mean it’s inherently bad. This is the same logic used against PHP every day yet it’s used all over.

overgard 5y ago

10 years ago I would have agreed with you, but in recent years Javascript (and moreso Typescript) are just exceedingly pleasant to use. I'm using Typescript in backend services despite knowing Python and C# well just because I like it.

vletal 5y ago
I can imagine that the original argument does not apply to the languages which compile to JS. But IMO the fact that there is so many derived languages covering the mess which JS is only supports the argument against it.
- nicoburns 5y ago
  TypeScript is just JavaScript with type annotations. The runtime semantics are identical. JavaScript itself has improved to the point where it's great to work with, and arguably the nicest of the common dynamically types "scripting" langauges (python, ruby, PHP, perl).
  - gmac 5y ago
    Completely agree. I used to work mainly in Ruby, and I guess I miss its rich standard library, but overall TypeScript is such a joy to work with that now I use it for almost everything.

believeinskills 5y ago

Well I know plenty of people that are similar to me in that in our early years, we asked for resources and help, and the response that was constantly given was "use what you know," which was bad advice for people who made websites who were looking to program. It's no wonder Javascript is the only thing used. I actually love React and ES because it's the first time I feel like a real programmer and not someone just writing Javascript. I don't really care about people's opinions about JS, I simply use what works. If you hated Javascript, maybe the anit-javascript community should have wrote blogs, made videos, and created content in the same way that the Javascript community did.

bastawhiz 5y ago

> Too many people only learn JavaScript, become psychologically dependent on it, and they all collectively took it too far outside of a browser. Do you have any evidence for this? Because there's plenty of reasons why you'd share the same code in the browser and the server. Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules? I have a site builder codebase that renders previews instantly as you make changes, then uses the same code on the server to render the HTML and CSS for visitors. That would be otherwise be outright impossible to do without writing the same code again in another language.

gls2ro 5y ago
Here is my perspective: There are plenty of reasons to use the same language on FE and BE but for me the main problem is the JS standard library. Let me give you one example: Lets say you want to validate if a string is a valid URL. What is a good way to do this in JS? Just for reference in Ruby for example I can do: URI.parse(input).kind_of?(URI::HTTP) No gems or any other engines needed.
- hoten 5y ago
  The URL constructor.
  - gls2ro 5y ago
    Oh wow, how I missed that. I stand corrected! Seems like JS standard library is better than I thought.
zozbot234 5y ago
> Being able to do SSR and sharing validation logic are two huge and obvious reasons. Ever try to exactly duplicate validation rules between the browser and PHP? What about when they use weird regexp rules? PHP is adding support for FFI to any C ABI-compatible language, and you can run the exact same code in the browser via emscripten or a WASM polyfill. As a bonus, emscripten/WASM compiled code will also be more efficient in the browser than plain JavaScript or Typescript.

hn_throwaway_99 5y ago

Couldn't disagree more. I was a Java programmer for my entire career until about 2015 or so when I switched to Node, and shortly thereafter to TypeScript. I've commented this many times before, but having a system where everything is on the same tech stack (i.e. front end in TypeScript with React, back end with TypeScript on Node) has resulted in gargantuan productivity gains, especially for a small team where it's trivial for people to cross front end to back end seamlessly. For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS, as Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly. Furthermore, TypeScript is a great language and I find myself being so much more productive in it than I was in Java, especially when it comes to refactoring. JavaScript most definitely has its warts and head scratchers after being around for 25 years, but I feel like most of these oddities (truthy/falsey, typeof null === 'object', undefined vs. null, etc.) can be learned in an hour and written on a half page.

creshal 5y ago
> For contrast, I know many teams with a backend in Python and a frontent in React/JS, and I've worked on some teams with that setup. In my opinion it's virtually all downside compared to a backend in TS Is there any Typescript backend framework as mature as Django? > Python and TS are quite similar from a web programming perspective (I'm not referring to Python's advantage in data science tooling), so all it basically is is a barrier to your front end folks being able to make small enhancements on the backend quickly. So on the on hand, the languages are "quite similar", yet it cannot possibly be expected that frontend people learn more than a single language? Something doesn't add up here.
- spiderice 5y ago
  You are interpreting GP’s comment very uncharitably, to the point that it actually becomes a completely incorrect interpretation. GP is pointing out that it is advantageous to have a single language on both front end and backend. And somehow you arrived at “developers cannot be expected to learn more than one language.” There ARE big advantages to having the exact same language (as opposed to similar languages) on both client and server, especially in an SPA where you want to render something initially on the server, but then update it using the same logic later on the client.

koonsolo 5y ago

> Node is not ECMAScript in a server-side ECMAScript engine, it's JavaScript in a browser JavaScript engine. Why would your custom ECMAScript server be any faster or more stable than any of the existing browser engines? If you look at the resources behind those engines, I don't know who would match that effort doing the same on the server.

paulryanrogers 5y ago
My guess is the browser JS engines are optimized for quick compilation and execution. While a backend engine could optimize for longer, persist runtime.

yashap 5y ago

TypeScript is a pretty good language for writing web servers, as long as you don’t need to do computationally heavy parallel computing. And you can still do that, but it’s very awkward. I’ve done plenty of backend work in all of TS, Scala, Go, Python and PHP. Scala is my personal favourite, but it’s not as practical for teams as TS or Go, which are both very productive languages, with good enough type safety and performance, that new devs can learn quickly. And I’d easily choose TS over PHP or Python for a large system. Plus, it IS pretty nice being able to use a single language everywhere. My current company is TS RESTful services with TS/React on the web, and TS/React Native on mobile, pretty hard to beat how easy it is to do full stack dev work for most ppl in this setup.

SavantIdiot 5y ago
> computationally heavy parallel computing. JS has no parallel computing support, so it is not an option. And when I say parallel computing, I don't mean distributed computing, I mean utilizing hundreds (thousands) of cores on a single die, like NVIDIA architectures. (It's a black art, even addition algorithms can confuse the newcomer.) The best course is to do what every other language does when it comes to simple-parallel operations, like Gauss-Jordan elimination: use a dedicated, optimized library, like NumPY. I really hope some day there will be a numpy for JS. NumJS is dead, and Google's TensorFlowJS is excellent for utilizing GPUs, but a dog when trying to do simple operations (the load/store async nature doesn't quite fit with most use cases.) I suspect WebAsm will facilitate the parallel nature of tensor operations without having to move
- lhnz 5y ago
  It sounds like you want something a bit like WebGPU: https://gpuweb.github.io/gpuweb/ https://gpuweb.github.io/gpuweb/
  - SavantIdiot 5y ago
    Close, but I don't want to have to switch memory models, e.g. upload/download. What I want is the incredibly diverse numerical computing support and logical syntax of NumPY but in the same process & memory space. The W3C endeavor is something a little different. Thanks tho!!

grishka 5y ago

ActionScript is also an ECMAScript language, and it's kinda ridiculous to see that JS still hasn't quite caught up. Out of things that modern JS lacks, AS had Java-like interfaces and you could specify types on variables. (Yes, I know about TypeScript.)

benrbray 5y ago
As someone who first learned to code with AS2/3, I agree it was quite disorienting when I first tried to make a few games with HTML5/JS. I do think you're not giving TypeScript enough credit -- I felt right at home the first time I used TS, and the type system is much more sophisticated than anything ActionScript ever had. As long as you're of the "favor composition over inheritance" mindset, which I'd argue is better, even for games, TypeScript is a fantastic spiritual successor to ActionScript! Unfortunately there's no TypeScript-based game engine that makes it so easy to combine code with animations / sound. Nothing has really filled the void that Flash left behind.

SavantIdiot 5y ago

NodeJS is important for more reasons than "it's just JavaScript". It is asynchronous from the bottom-up, and it is literally a challenge to force asynchronous patterns into a synchronous ones, which is almost always a hack because async requires a lot of thought. This is a boon to IIoT control, where the pejorative "web server" is literally the endpoint for 10's of thousands of IoT edge nodes. NodeJS fits in with this architecture perfectly compared to the shoehorning required to make it work with PHP, (C/C++), Python or Java. (N.B.: I am not a java programmer, but we did review using Java, too, but it was voted down for other reasons.) If there is another asynchronous language that is as well defined as NodeJS and has as much library support, I would very much like to study it.

ripe 5y ago
This. I grew up with Lisp and Smalltalk, yeah I am that old, but today I love Node to build web apps. It’s a fantastic environment for asynchronous programming. It also has a built-in REPL for a management interface via TCP or Unix sockets. It doesn’t really need any additional packages (I hate the dependency hell that npm saddles you with, and people don’t seem to know that Node already has http, https, and websocket upgrades built in, so you often don’t need any “frameworks” or libraries). Give me Node, and I can build an entire web app from scratch. Most of the time you don’t even need to use JS in the browser. Just html and CSS are enough. Web apps the way God intended. I don’t use Typescript either. Its type checking isn’t worth the hassle of poor tooling and inscrutable stack traces.
- SavantIdiot 5y ago
  IMHO, TypeScript is only useful if you are using a build tool because it requires so much configuration. I switched to WebPack for very large Electron projects and I'm hooked on it. The syntactic sugar protects me from myself, and the importing is cleaner. I also finally made the switch to VSCode, which while bloated and awkward to configure, is pretty dang amazing when working correctly w.r.t. linting and code inspection. Lot's of projects are popping up using ElectronJS, which is Node+Chromium. I have written many, and they are literally write-once-run-everywhere. Node serialport and node libusb have some speed issues on macOS, but require literally no alteration, utterly seamless. The idea as "Node is just web" is dead in the water. Hugely popular ElectronJS(Node) apps are: * Saleae - An inexpensive logic analyzer - https://www.saleae.com/ https://www.saleae.com/ * Balena - a flash programmer for SDmicro and USB drives - https://www.balena.io/etcher/ https://www.balena.io/etcher/ * BetaFlight Configurator - the seminal drone (quad/hex/octo) configuration tool - https://github.com/betaflight/betaflight-configurator https://github.com/betaflight/betaflight-configurator [FYI: Python is far, far behind in packaging cross-platform apps and requires gigabytes of support libraries. People complain about Electron size, but they are only comparing it to native apps.]

franklampard 5y ago

I am professional who used python, Java in my Career, and TypeScript is simply the best. “Too many people only learn JavaScript, become psychological dependent o it “ is simply a false narrative from people who are stuck with obsolete web dev tech stack and refuse to learn better tools

vmception 5y ago

This is wrong lol. V8 changed the whole paradigm. Thinking of Javascript as still just a browser language is the flaw.

Pfhreak 5y ago

> The problem started a decade or so ago with Node. What problem, specifically? People enjoy writing Javascript. It has a ton of fantastic resources online, it is easy to debug and deploy, it's quick to pick up and forgiving of mistakes. > Too many people only learn JavaScript, become psychologically dependent on it You sound like Immortan Joe warning people not to become dependent on water in Mad Max. Let people enjoy the language they enjoy developing in. > they all collectively took it too far outside of a browser. What does this even mean? What's "too far" even mean? People want to write code, let them?

colordrops 5y ago

Unbelievable that this is voted to the top on Hacker News. The comment literally gives not one concrete example or reason by JavaScript is "bad". I'd expect more from you all here.

whostolemyhat 5y ago
This happens every time a Javascript topic comes up - hundreds of comments just regurgitating the same "Javascript is bad" memes. It's bad enough that's there's no real point in reading the comments on JS submissions since there's rarely discussion about the article.

cultofmetatron 5y ago

Couldn't agree more. I started in this field as a javascript programmer. I've since expanded my toolkit to include typescript, elixir, plpgsql and now gaining proficiency in rust. I'm continually frustrated by my colleagues refusal to step outside the javascript ecosystem. Don't get me wrong, JS certainly has its place but its not ALWAYS the best tool for the job. I see a lot of people reach for node as their go to backend tech choice simply because its the ONLY tool in their toolbox. Unless you're building a small focused microservice where the functionality involves calling out to a library with working tested code that does what you want, I think node is honestly a poor choice. To qualify my statement, I spent the first 7 years of my professional career building software with nodejs. The sweet spot is much smaller than the scope of projects people throw at it. * quick MVP? rails has more libraries that are drop in. * Performance? go and elixir have node beat for multicore perf * websockets? compared to phoenix channels, everything in node for serving websocket apis are a toy. Lambda functions though? yea nodejs kicks but there!

Kiro 5y ago

The only reason I'm using node.js is because I can do this: let num = 0; route('/url').post(data => num++); What other languages can I do this in that are better? I simply want to have a variable I can access and mutate from inside closures and let it live in memory without the need for databases or file systems.

merb 5y ago
every language?
- ptx 5y ago
  To be fair, threads complicate things.
  - merb 5y ago
    yeah but most languages have stuff like Atomic integers or other things.
    - Kiro 5y ago
      I want a language where it's as natural as my example above, and normally an object or array so the integer was just to simplify the example. Do you have any suggestions? I want to declare a variable and then be able to access/modify the same variable through a closure in a callback for incoming requests, so I guess that requires it to be single-threaded. (I'm using this for game state where it's very convenient to just declare a persistent data structure in code directly without without having to use any additional abstraction.)
      - merb 5y ago
        well without atomic access your state would be wrong. there are languages that allow stuff like that, but if you do it you can still have the wrong number. i.e. in c# something like you wrote is possible but when getting multiple requests, the number might be wrong at the end. you always have some tradeoffs because in your case when you would run it with a multi threaded js engine your variable would be as broken as the c# one. that's why java does not allow it by default to modify a variable inside a thread that is declared outside.

bennysomething 5y ago

I don't know what's wrong with me. I hate JavaScript. I tried learning react and redux and just gave up. All this to put a button and a field on a page. React was basically invented by John carmack to do doom 3 and copied to render web pages. Is this really required!? It's not a 3d games engine. I've worked on web apps that require a lot of page updates per minute and I still hate react. I stay the hell away from front end web Dev as it just feels like hell. Sorry drunken rant. Edit: I also worked on a node app that should have been written in a staticall typed language. Bugs that could have been caught at compile time literally caused me utter misery in on call overtime. All because some guy in our team demanded we wrote it in node. This was way before type script. I actually feel physical pain thinking about.

adamscybot 5y ago
Perhaps give it another try, but with TypeScript. Im a front end dev and yes, I feel the JS pain. I look back at how I used to do things and think "wtf". TS completely changed this and brought it back to sanity.
- hajile 5y ago
  I’m pretty sure the real issue is backend vs UI rather than JS/HTML. If you’ve worked with a few alternatives, the web suddenly doesn’t look too bad. Sure, a couple solutions are probably nicer, but they are mostly platform locked and way slower to develop on. UI programming is literally the fine art of handling what your most exasperating client is capable of inflicting on your UI. I suspect this is the core complaint.
bobthepanda 5y ago
at least part of the problem is that Javascript and webdev have really low barriers to entry, which is positive in the sense that anyone can do it, but the problem is that anyone can reach that unhappy valley of knowledgeable enough to do a lot of damage without realizing it. If you put bad developers on other languages they usually end up running into some wall first but Javascript is pretty forgiving.
schwartzworld 5y ago

bdcravens 5y ago

> it's the only browser scripting language IE did support VBScript, and only finally "killed" it in 2019 https://blogs.windows.com/msedgedev/2019/08/02/update-disabling-vbscript-internet-explorer-windows-7-8/ https://blogs.windows.com/msedgedev/2019/08/02/update-disabl...

axegon_ 5y ago

What makes matters worse is that javascript is being pushed as the golden standard language and replacing pseudocode. In recent years I've stumbled across multiple articles on serious topics and concepts such as complex algorithms for compression or image processing and two scrolls down and I see an implementation in javascript. insert ragequit gif here

elliotec 5y ago
So what? It's an incredibly productive language that CAN DO "complex algorithms for compression or image processing." It's accessible, popular, easy enough to use, and ubiquitous. All the ingredients for success. Does it belong on mission-critical spaceships? Whether you like it or not, the answer is yes, of course it does. https://os-system.com/blog/javascript-in-space-spacex-devs-have-shared-crewdragons-tech-stack/ https://os-system.com/blog/javascript-in-space-spacex-devs-h...
- axegon_ 5y ago
  The fact that you can put a 900 bhp engine in a 40 year old rusty Citroen, doesn't make it a good idea(JavaScript being the Citroen). There's a good reason why operating systems are written in low level languages and not toy languages that are meant to make sites jiggle. JavaScript is just a convenient excuse to write slow, horrible, unreadable and unmanageable code without having people pointing it out because no one expects JavaScript to be anything other than an endless mess of spaghetti. Even in the case of space x is just a tool for shiny buttons and that's it. That still doesn't make it a good idea. Some time ago I saw in a video that the Audi entertainment system is written in typescript and as much as Audis are great cars, the entertainment system feels painfully clunky compared to a cheap 120 euro Android phone. JavaScript and node are horrible technologies that should be abolished and replaced by something that doesn't require a 14-core Xeon and 32gb of RAM to run semi-decently.
- fitpolar 5y ago
  So what, is that not everyone loves it. Devs shouldn’t be forced to use a language that they hate using. Thankfully WASM is a remedy for this, and over the next decade devs will be able to build full stack across web and mobile in Swift or any other language they prefer.

travisgriggs 5y ago

Don't do much JS, but this is actually what makes me the most sad. My formative programming years were during an era where there were many competing technologies on most given platforms. Now days, if I do mobile iOS, I have to do Swift, Kotlin for Android, and as you say JS for browsers. I wish we lived in a world where the platform didn't design the stack so much.

z3t4 5y ago

JavaScript does not have a monopoly in web browsers. Microsoft supported vbScript and Google made a better and faster JavaScript (Dart) which also ran natively in the browser. But neither didn't take off. You can still "compile" for the browser though, the funny thing is that a lot if not most of the code running on the most popular web sites has gone through at least one compile step. So people don't actually program in JavaScript, it has become more of a compilation target.

pseudalopex 5y ago
Most browsers didn't support VBScript or Dart. TypeScript and JSX are the most popular languages that compile to JavaScript as far as I know. They're very close to JavaScript because people learned straying too far created problems.