241–250 of 502 posts
[1]: https://en.wikipedia.org/wiki/List_of_server-side_JavaScript...
I've said it before and I say it again; NodeJS is an infrastructure component, not a general purpose application runtime environment. I totally recognise the IO problem in our connected world and NodeJS really does solve the problem around the "many simultaneously persistent connections", something that would be really hard to do without something like NodeJS. In essence (and in my humble opinion) NodeJS is basically…
The first thing I did for a latest project in node was a sync =>{done()} queue for ws requests. There is a room for fine-graining, but it is a routinely job of determining parallel cases that don’t hit db “ci” in acid much. Not a big deal. The choice for node was obvious in that it has most straightforward installation and maintaining on windows boxes (I’m language and OS agnostic [except js allergy], but peers aren’t). I think that async is yet another hipster bullet, since our to-profit businesses rarely need much traffic and those that need are barely fit for 10kloc of js.
It’s awkward personally not so because it’s async, but because it’s too low level and npm doesn’t feel like a well-documented and thorough module set. It lacks unixlike formality and strictness in phrasing, oriented on beginners, but not on -pedantic needs. It’s hackerish and cool until you meet borders that are required beyond the “move fast” thing — it slows you down. And I didn’t meet a good abstraction over ws and db layer yet. It feels like a bicycle and a shovel when you have to dig a career (pun intended).
Earlier quoted context omitted.
Yeah, I remembered the package.json bit, but that part still had nothing related to the issues/ mistakes mentioned.
Understood, sorry I wasn't trying to dispute any of your points about said issues/mistakes. Just trying to clarify that he does actually talk about NPM and his regret about it.
Earlier quoted context omitted.
Which is unfortunate. Top-level await is a very bad footgun and should almost never be used.
Can you elaborate? It seems useful for simple scripts and REPLs, at least.
I just don't see how this workaround is the correct solution. Just saying that's it's generally a bad idea is not enough for me. At some point there will come a time when you want to treat a file as a function, and when that day comes you will want async/await at the top level.
I think it's quite interesting to see that originally node.js was presented as a bloat-free alternative to "enterprise languages" like Java, C# or even Python or Ruby. A lot of complexity was subsequently added in an ad-hoc way which has resulted in (for example) a package management system that's wildly out of control. It's very popular of course, so I'm definitely not arguing that metric. However, the stuff that wa…
I think this is a story that gets repeated lots of times in our world of open source software dev. 1. X is SO bloated and poorly engineered full of bad legacy decisions. 2. We can totally do better let's invent a new thing, Y! 3. Wow, Y is so clean and fast and understandable. 4. But it doesn't do this thing a bunch of people reasonably really need... let's add it. (repeat 3 and 4 a few hundred times) 5. Y is so bloa…
I think Javascript suffers from this quite a bit. ES6 "classes" should never have made it in, for example. Not only did they add an extra level of abstraction for beginners to learn, but the only reason for doing so was "my code doesn't look like it does in other languages"...
Let's not forget node.js wasn't created in a vacuum but was based on CommonJS (module format and std lib) also implemented by TeaJs/v8cgi, Helma, and many others [1]. In fact, server-side JavaScript was a thing as early as 1999 or before (Netscape Server). That it's based on a highly portable language also used on the browser is what made it attractive over alternatives for me back in 2012 or so. [1]: https://en.wiki…
Earlier quoted context omitted.
I think this is a story that gets repeated lots of times in our world of open source software dev. 1. X is SO bloated and poorly engineered full of bad legacy decisions. 2. We can totally do better let's invent a new thing, Y! 3. Wow, Y is so clean and fast and understandable. 4. But it doesn't do this thing a bunch of people reasonably really need... let's add it. (repeat 3 and 4 a few hundred times) 5. Y is so bloa…
Yes, because the loop never solves the original problem. It's about organization and bloat, not pure speed and leanness. Rebuild from scratch but also recreate all the existing functionality in a much better standard library and finally the chain can be broken. But nobody wants to do that.
Earlier quoted context omitted.
I think the problem with "bloat-free" is it's a fine ideal until you try to solve any kind of reasonably complex problem, and honestly it starts to creep in even when you're solving something that isn't particularly complex. Here's a concrete example. Your classic node.js or express.js sample app is something fairly simple like a hello world, or an IM server. A more complex sample probably looks something like that v…
IMHO, the point of using a no-frills library/framework is because you want you write the rest of it yourself. The advantage of this is that it meets your requirements exactly and is therefore smaller/less complex. When doing a project that takes only a few weeks, I would probably choose a framework that has everything in the box. But if you are building something that is going to be developed over a period of years,…
Earlier quoted context omitted.
Watching the Javascript poorly reinvent the wheel has been very disappointing. Very simple mistakes like immutable, never changing build releases that Java developers understood 15 years ago are become recent front page news in this community. Ironically, even though all the code is open-source pre-existing knowledge does not get leveraged in the open source world. There's a kind of market failure at work here it see…
I like the energy around the javascript everywhere movement. So what if they reinvent the wheel, sometimes you find a better wheel and break the rules along the way. There is something exciting about developers using a language in ways it was never designed. Then having the language change to support the changing ecosystem...
Earlier quoted context omitted.
> golang tried no centralized package management by using git repo. It didn't end well. What? There's no fundamental problem with it. It will continue. What do you mean?
The go team recognise there's a fundamental problem with it, otherwise they wouldn't have created dep and vgo [1] [1] https://github.com/golang/go/issues/24301