171–180 of 210 posts
Wow I can't believe how light years ahead Deno is than Node. You want imports you want fetch you want TS, use Deno.
Seriously. I maintain an open-source Node.js CLI utility and was shocked when import/export syntax is only achievable if you use a transpiler like Babel. Such overkill for something that’s been in the JS spec for nearly a decade.
Earlier quoted context omitted.
Those have been supported for several years now :) You need to tell Node to use the format by either naming your file `.mjs` or setting `"type": "module"` in your `package.json` file. > Also why do so many libraries have this strange 5 line header code for this umd, amd, business. Is that to make their packages work with nodejs? That's just old for "adapt the module system" from the old days and libraries just didn't…
"supported" is somewhat of a misnomer IMHO. It's only supported if the other tools you're using support ESM. Otherwise, it's not. And it's really annoying when libraries choose to go full ESM because it breaks things like tests and deployments in weird ways. It's a pain in the ass.
My biggest issue with node when I was working on it briefly was I couldn't do the 'import' statements like wepback. Are they supported too now? I'm not a web developer so I had a very hard time understanding why there are so many different type of imports in JavaScript like require, import, umd, amd, etc and which one works in browser and which one works in node? Also why do so many libraries have this strange 5 line…
In short, node has imports, browsers have imports, but node-related toolkits do not support it, and people still webpack bundles because development and deployment processes are a thing, and it doesn’t matter much which module system a “binary” bundle uses in the end. Some people tried to force ESM adoption by making popular modules ESM-only for no technical reason, but tools are not there yet, and it only annoyed (p…
Being the standard for the lsat 7 years strikes me as a good reason.
Wow I can't believe how light years ahead Deno is than Node. You want imports you want fetch you want TS, use Deno.
Earlier quoted context omitted.
This is an understatement. With fetch available in node, we have a single, standardised, promise-based HTTP client Interface available on all (more or less common) JavaScript platforms. This is great news for an ecosystem traditionally extremely fragmented and may lead the way to more consolidation in the JS library space.
NodeJS API are traditionally not promised based (although nowadays some do offer a promisified option), so I'm not especially excited to have a promise-based API :) It's a great news for people doing both front end and backend I guess, but for people doing NodeJS développement it's just one more option to do http request (which I guess is going to be very similar to the module node-fetch that have existed for a while…
...and that's part of why this is great news. Node APIs are the avocado colored appliances of the JS ecosystem.
My biggest issue with node when I was working on it briefly was I couldn't do the 'import' statements like wepback. Are they supported too now? I'm not a web developer so I had a very hard time understanding why there are so many different type of imports in JavaScript like require, import, umd, amd, etc and which one works in browser and which one works in node? Also why do so many libraries have this strange 5 line…
There isn't a straight forward solution, but the closest for me is the combination of using a transpiler (Babel), and a bundler (Webpack).
A common criticism on node/javascript projects is the boiler plate setup required. As far as I know, there isn't an IDE that takes care of doing this part for you, where your experience developing outside of the web might (I like to think it akin to starting a project from scratch with C++, gcc, and make).
Some larger projects, do have scripts that do a lot of boiler plate for you, such as Create-React-App. https://github.com/facebook/create-react-app but that is for a specific use case.
Earlier quoted context omitted.
Not every browser API is an instant candidates to be added to Node's core. If there isn't a big performance hit from doing it as a user library or lack of functionality to do it as such in the first place then it's rare it'll be brought into core right away, if it will at all. It's nice to see the really popular ones make it in though, makes for fewer dependencies when doing browser compatible projects and also allow…
This is what frustrates me so much about javascript. Everything is all over the place.
Earlier quoted context omitted.
Is there any chance to break spec and allow manual redirect handling? the fetch API makes a lot of sense in a browser, but imo this is a pretty crucial feature that undici's implementation lacks. [0] Deno decided to break spec [1][2] so the following code works fine: fetch('https://httpbin.org/status/302', {redirect: 'manual'}) .then(res => console.log(res.status, res.headers)) In undici this will succeed but with re…
A better idea would be to replace / improve the fetch spec. Handle redirects, set JSON as the default request content type, encode URI components for users, decode response bodies with JSON headers as JS objects, etc. Right now most developers either write their own library to do these things on top of fetch or another HTTP client or use a third party library from npm. A new standard would allow us to make http reque…