Our great sponsors
-
-
FizzBuzz Enterprise Edition
FizzBuzz Enterprise Edition is a no-nonsense implementation of FizzBuzz made by serious businessmen for serious business purposes.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
proposals
✍️ Tracking the status of Babel's implementation of TC39 proposals (may be out of date) (by babel)
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Usually software architecture is not language-dependant, so your knowledge from Java could be used here. For example, you can do hexagonal architecture in NodeJS. All of what you learned about exceptions can also be applied here. Probably most of what you learned about static typing too, if you work with TypeScript.
I think another part of learning JavaScript is forgetting what you learned in other languages and embracing JavaScript. At work most of the JS/TS code is namespaces and plain functions, with the occasional object when that makes sense. We don't use much the dynamic nature of the language in application code, but for testing we use it a lot.
For the performance part, I agree, it's hard to find resources. Part of it is because JS is "good enough" for most server-side software: the language is fast and asynchronous IO helps a lot. Most high-level advice is about being nice to the JIT: write code as if it was statically typed, let the JIT make easy assumptions and don't break them (objects that don't change, arrays used as arrays). Part of it may also be because the V8 team is constantly hard at work to improve performance. Their blog (https://v8.dev/) is a great read, I learned a lot here. There's another high-level advice that works everywhere: try to make a stateless app, so that scaling horizontally is easy.
My biggest pointer would be to remember that Java & JavaScript aren't named that way by coincidence. They're two different approaches to a similar problem. Java suffers from Enterprise Development (eg: Enterprise FizzBuzz[0]), JavaScript suffers from Ultimate Accessibility (eg: how many questions on Stack Overflow conflated jQuery and JS?).
> How should exceptions be managed? [...] Has there been a debate about best practice? Where can I find it?
I suggest you handle the errors you can and otherwise let it crash.[1][2] Debates in NodeJS-land have steered towards more monadic/Result-like structures and working synchronous-looking try/catch onto async/await. NodeJS and its various components are open source, you'll have a lot of luck looking around on GH for issues & PRs related to a feature -- same for the language, ECMAScript[3] officially.[4]
Since you mentioned Clojure, have you looked at ClojureScript?[5] That may be a good entry to JS authors & articles you'd enjoy.
> I have the impression that NodeJS is a bit more magical than the JVM [...] Is that correct? Where are good resources on this subject?
As other replies have mentioned, you're really talking about V8[6] for the "JSVM" executing that code. A thing I've seen throw some people for a loop is how minimalist the specification actually is.[7] The magic in NodeJS is certainly from V8 and the rate of optimizations there but also libuv,[8] what actually powers the infamous event loop.
Hope that helps!
[0]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
[1]: Borrowing from Erlang, see Making reliable distributed systems in the presence of software errors, Joe Armstrong, page 104 "Error Handling Philosophy" https://erlang.org/download/armstrong_thesis_2003.pdf
[2]: _Most_ kinds of errors will cause the process to crash if you don't handle them, https://nodejs.org/dist/latest-v16.x/docs/api/errors.html . Promise rejections don't (yet) though it emits an error, and callback-based APIs will always consist of an [error, data] tuple for the arguments
[3]: https://github.com/tc39/proposals
[4]: Because Oracle owns the trademark, of course: http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=
[5]: https://clojurescript.org/
[6]: https://v8.dev/docs
[7]: "ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific objects, whose description and behaviour are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program." https://tc39.es/ecma262/#sec-overview
[8]: https://github.com/libuv/libuv
My biggest pointer would be to remember that Java & JavaScript aren't named that way by coincidence. They're two different approaches to a similar problem. Java suffers from Enterprise Development (eg: Enterprise FizzBuzz[0]), JavaScript suffers from Ultimate Accessibility (eg: how many questions on Stack Overflow conflated jQuery and JS?).
> How should exceptions be managed? [...] Has there been a debate about best practice? Where can I find it?
I suggest you handle the errors you can and otherwise let it crash.[1][2] Debates in NodeJS-land have steered towards more monadic/Result-like structures and working synchronous-looking try/catch onto async/await. NodeJS and its various components are open source, you'll have a lot of luck looking around on GH for issues & PRs related to a feature -- same for the language, ECMAScript[3] officially.[4]
Since you mentioned Clojure, have you looked at ClojureScript?[5] That may be a good entry to JS authors & articles you'd enjoy.
> I have the impression that NodeJS is a bit more magical than the JVM [...] Is that correct? Where are good resources on this subject?
As other replies have mentioned, you're really talking about V8[6] for the "JSVM" executing that code. A thing I've seen throw some people for a loop is how minimalist the specification actually is.[7] The magic in NodeJS is certainly from V8 and the rate of optimizations there but also libuv,[8] what actually powers the infamous event loop.
Hope that helps!
[0]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
[1]: Borrowing from Erlang, see Making reliable distributed systems in the presence of software errors, Joe Armstrong, page 104 "Error Handling Philosophy" https://erlang.org/download/armstrong_thesis_2003.pdf
[2]: _Most_ kinds of errors will cause the process to crash if you don't handle them, https://nodejs.org/dist/latest-v16.x/docs/api/errors.html . Promise rejections don't (yet) though it emits an error, and callback-based APIs will always consist of an [error, data] tuple for the arguments
[3]: https://github.com/tc39/proposals
[4]: Because Oracle owns the trademark, of course: http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=
[5]: https://clojurescript.org/
[6]: https://v8.dev/docs
[7]: "ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific objects, whose description and behaviour are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program." https://tc39.es/ecma262/#sec-overview
[8]: https://github.com/libuv/libuv
My biggest pointer would be to remember that Java & JavaScript aren't named that way by coincidence. They're two different approaches to a similar problem. Java suffers from Enterprise Development (eg: Enterprise FizzBuzz[0]), JavaScript suffers from Ultimate Accessibility (eg: how many questions on Stack Overflow conflated jQuery and JS?).
> How should exceptions be managed? [...] Has there been a debate about best practice? Where can I find it?
I suggest you handle the errors you can and otherwise let it crash.[1][2] Debates in NodeJS-land have steered towards more monadic/Result-like structures and working synchronous-looking try/catch onto async/await. NodeJS and its various components are open source, you'll have a lot of luck looking around on GH for issues & PRs related to a feature -- same for the language, ECMAScript[3] officially.[4]
Since you mentioned Clojure, have you looked at ClojureScript?[5] That may be a good entry to JS authors & articles you'd enjoy.
> I have the impression that NodeJS is a bit more magical than the JVM [...] Is that correct? Where are good resources on this subject?
As other replies have mentioned, you're really talking about V8[6] for the "JSVM" executing that code. A thing I've seen throw some people for a loop is how minimalist the specification actually is.[7] The magic in NodeJS is certainly from V8 and the rate of optimizations there but also libuv,[8] what actually powers the infamous event loop.
Hope that helps!
[0]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
[1]: Borrowing from Erlang, see Making reliable distributed systems in the presence of software errors, Joe Armstrong, page 104 "Error Handling Philosophy" https://erlang.org/download/armstrong_thesis_2003.pdf
[2]: _Most_ kinds of errors will cause the process to crash if you don't handle them, https://nodejs.org/dist/latest-v16.x/docs/api/errors.html . Promise rejections don't (yet) though it emits an error, and callback-based APIs will always consist of an [error, data] tuple for the arguments
[3]: https://github.com/tc39/proposals
[4]: Because Oracle owns the trademark, of course: http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=
[5]: https://clojurescript.org/
[6]: https://v8.dev/docs
[7]: "ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific objects, whose description and behaviour are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program." https://tc39.es/ecma262/#sec-overview
[8]: https://github.com/libuv/libuv
My biggest pointer would be to remember that Java & JavaScript aren't named that way by coincidence. They're two different approaches to a similar problem. Java suffers from Enterprise Development (eg: Enterprise FizzBuzz[0]), JavaScript suffers from Ultimate Accessibility (eg: how many questions on Stack Overflow conflated jQuery and JS?).
> How should exceptions be managed? [...] Has there been a debate about best practice? Where can I find it?
I suggest you handle the errors you can and otherwise let it crash.[1][2] Debates in NodeJS-land have steered towards more monadic/Result-like structures and working synchronous-looking try/catch onto async/await. NodeJS and its various components are open source, you'll have a lot of luck looking around on GH for issues & PRs related to a feature -- same for the language, ECMAScript[3] officially.[4]
Since you mentioned Clojure, have you looked at ClojureScript?[5] That may be a good entry to JS authors & articles you'd enjoy.
> I have the impression that NodeJS is a bit more magical than the JVM [...] Is that correct? Where are good resources on this subject?
As other replies have mentioned, you're really talking about V8[6] for the "JSVM" executing that code. A thing I've seen throw some people for a loop is how minimalist the specification actually is.[7] The magic in NodeJS is certainly from V8 and the rate of optimizations there but also libuv,[8] what actually powers the infamous event loop.
Hope that helps!
[0]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...
[1]: Borrowing from Erlang, see Making reliable distributed systems in the presence of software errors, Joe Armstrong, page 104 "Error Handling Philosophy" https://erlang.org/download/armstrong_thesis_2003.pdf
[2]: _Most_ kinds of errors will cause the process to crash if you don't handle them, https://nodejs.org/dist/latest-v16.x/docs/api/errors.html . Promise rejections don't (yet) though it emits an error, and callback-based APIs will always consist of an [error, data] tuple for the arguments
[3]: https://github.com/tc39/proposals
[4]: Because Oracle owns the trademark, of course: http://tarr.uspto.gov/servlet/tarr?regser=serial&entry=
[5]: https://clojurescript.org/
[6]: https://v8.dev/docs
[7]: "ECMAScript as defined here is not intended to be computationally self-sufficient; indeed, there are no provisions in this specification for input of external data or output of computed results. Instead, it is expected that the computational environment of an ECMAScript program will provide not only the objects and other facilities described in this specification but also certain environment-specific objects, whose description and behaviour are beyond the scope of this specification except to indicate that they may provide certain properties that can be accessed and certain functions that can be called from an ECMAScript program." https://tc39.es/ecma262/#sec-overview
[8]: https://github.com/libuv/libuv