Live data from Hacker News

Things I Regret About Node.js [video]

youtube.com

201–210 of 502 posts

Re: Things I Regret About Node.js [video]

#201

Earlier quoted context omitted.

All these tools start off as simple alternatives to the existing bloated tools. Then as they gain more and more features to support real-world situations they end up becoming as bloated as the tools they set out to replace.

Right. I'd just hope that at some point that cycle ends and people try to fix existing tools instead of replacing everything wholesale with something new that will eventually fail again.

Sorry, there is always a new developer thinking "I can do this much better if I just start from scratch, getting rid of all the bloat".

Re: Things I Regret About Node.js [video]

#202

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…

It's always like this. I'm lucky enough to have been around the industry for a while. I could probably count a dozen or more things that started out "Like X, only without all the BS!" --- only to end up with just as much BS or more than X ever had.

Yes, this is not only about tech-sector. You see it everywhere there is humans. There is always new people thinking that why do they do everything so stupid? I can do it much better if I do it this way. Sometimes they are right and everyone is happy, sometimes they do it exactly the same way it was done ages ago and found out to be inefficient or fail in some way and they get to hear "There was a reason we did it the other way".

I try to explain why we do things the way we do and if they still want to try to change things, I make sure it's easy to go back again in case it fails the usual way.

Re: Things I Regret About Node.js [video]

#203
post #113

Earlier quoted context omitted.

I think the package system consists of many parts. Some parts of npm are much better than with most package systems, some really suck. Maybe if npm weren't included so deeply into Node, it would make something like Yarn emerge sooner and replace npm without much hassle.

yarn just seems like a set of incremental improvements over npm? Which is great, we're all for improvements. However, the vehement complaints I've seen about npm [0] make it seem that nothing short of a complete re-architecture could be tolerated. yarn does not seem to be that. I don't agree with those complaints, but I do agree with you that "some parts" are really good. node really figured out the right search stra…

Well, since npm was the de facto default, it had enough time to catch up, I guess.

Re: Things I Regret About Node.js [video]

#204
post #190

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…

I'd say your intel is far out of date. Async-everything + async/await makes Node more elegant than the same programs in Ruby/Python.

Even little things like "make these two database requests in parallel and wait on them both" or "process these urls but only have 8 requests in flight at a time."

Re: Things I Regret About Node.js [video]

#205

Earlier quoted context omitted.

> you don't share that much code between front and back in reality Good luck rendering React server-side in Go or Ruby.

I've never looked into server-side react, can you explain a bit about the requirements? Does the server keep a lot of session data around to maintain a shadow DOM for each connected client? How far is it in practice on the continuum between a fancy templating language and a full app framework? Does anyone put server-side React on server-side Redux? Whatever the case, if people write clients in react to talk to Ruby b…

While I haven't done SSR myself, my understanding of the general process is that it's about rendering that first initial page that's sent to the browser. This is most beneficial for speed of initial load and SEO purposes.

An SSR React app that uses Redux would probably create a unique Redux store instance for each new client, dispatch just enough actions to fill in whatever data is needed for the initial render, and then serialize the Redux store state to the host HTML page so that it can be used to re-hydrate the Redux store on the client.

For more info, see the "React Server Rendering" [0] section of my React/Redux links list, and the "Server Rendering" recipe [1] in the Redux docs.

[0] https://github.com/markerikson/react-redux-links/blob/master...

[1] https://redux.js.org/recipes/server-rendering

Re: Things I Regret About Node.js [video]

#206
post #193

Earlier quoted context omitted.

It's always like this. I'm lucky enough to have been around the industry for a while. I could probably count a dozen or more things that started out "Like X, only without all the BS!" --- only to end up with just as much BS or more than X ever had.

It's an anthropological effect, not a technological one. A new generation of craftsmen faces a choice between submitting to the rules of the old guard and making up their own rules. Reduced complexity is often a rallying cry, but I think the root of the phenomenon is in trying to find one's own social and professional standing in the situation where all the prominent positions are already taken and what little is lef…

Agreed.

Tech is ripe for applied group psychology and anthropology. The social, psychological, and anthropological factors are obvious to casual observers -- but completely invisible to the people they affect the most.

There's a reason for it, and perhaps overall it's a good thing....but that still doesn't mean that it can't be accepted and acknowledged as a facet of the community.

Re: Things I Regret About Node.js [video]

#207

Maybe it is just me but Javascript is not my favourite dynamic language. Given project like ReasonML and other languages that have type inference prototyping is not harder than without types. Is it a valid argument that it slows you down? Not sure.

I was not happy having to do TypeScript on a project thinking in your point about slowing you down which initially is completely true if you are forced to tslint it to hell. However, I've done a 180 in that TypeScript is very nice when you relax the tslinter and you sprinkle it on as you go which gives you that extra feeling of being auto-guarded when its just more practical but without getting in your way which is e…

Could you summarize what settings you used for the TS compiler and tslint for that "sprinkle it on but keep it out of the way" approach?

Re: Things I Regret About Node.js [video]

#208

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 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, the reduction in complexity achieved by building your own can be life saving.

When I look at your list, most of the things fall into the categories of "Pretty easy to implement" or "Don't want at all". However, there is an advantage for not reinventing the wheel if there is no reason to do so. If there is a nice library that gives me what I want and doesn't impose itself too much on the design, I will use it. But the main advantage for not baking it into a big framework is that I can pick and choose what I want.

As an older programmer, I come from an era where libraries and frameworks cost a lot of money. We built stuff by hand because there were not a lot of other choices. These days, though, virtually every library and framework is free software (not only free of charge, but you get source code too!) It's like living in Candy Land, and I'm not about to complain about it :-) However, I think that programmers today reach too quickly for the pre-built and do not understand the long term advantages of bespoke development. Like most things, there is a balance to be maintained.

Re: Things I Regret About Node.js [video]

#209

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…

It's always like this. I'm lucky enough to have been around the industry for a while. I could probably count a dozen or more things that started out "Like X, only without all the BS!" --- only to end up with just as much BS or more than X ever had.

No, not always. Some communities tend to do their research and web developers have a decades-old track record for not doing that.

Re: Things I Regret About Node.js [video]

#210

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…

That's a good example of the Innovator's Dilemma: the enterprise incumbent is unseated by some "crappy" lightweight solution that is easier to get up to speed and solves enough of the problem. The complexity, accidental and essential, comes later.

See: mongodb
Post reply on HN