Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Programs are dead, and JavaScript has killed them

pouria.dev

Post reply on HN
Print view View original

201–210 of 216 posts

Re: Programs are dead, and JavaScript has killed them

#201

Post by FractalHQ »

5350-uiop-1130 wrote: post #3

> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…

Why has nobody mentioned that you can (and should) just lock your dependency versions…?

Re: Programs are dead, and JavaScript has killed them

#202

Post by omarfarooq »

FractalHQ wrote: post #201
5350-uiop-1130 wrote: post #3

> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…

Why has nobody mentioned that you can (and should) just lock your dependency versions…?

Because that stop short that complain train.

Re: Programs are dead, and JavaScript has killed them

#204

Post by usrbinbash »

royletron wrote: post #189
usrbinbash wrote: post #62

Earlier quoted context omitted.

I can come back to a go module I write today months later and do a build. `go.mod` specifies exactly what version of what dependency I used, and `go.sum` provides the checksums. Even if the original repo was shut down, there is a good chance the `GOPROXY` I use has it cached, and failing that, if I am really worried about long time availability of dependencies I can always do a `go mod vendor` and check everything in…

I use go a lot and also love it. I did find it odd in the early days to not have a package manager, but they seem to have mostly built on the experience of NPM and got it right.

Yeah, the initial days were indeed odd, and modules absolutely required, otherwise the ecosystem would probably be a tangle of different 3rd party solutions for vendoring and version-pinning right now. Glad they avoided that.

They were building in the right direction with the idea that a world where public code repositories exist, a) doesn't need yet-another-repository for just one language, and b) should acknowledge the real world by specifying these resources directly in the code.

Re: Programs are dead, and JavaScript has killed them

#206

Post by wellanyway »

bluocms wrote: post #19
5350-uiop-1130 wrote: post #3

> During the past 5–6 years of my JavaScript experience, every time I wanted to go back to any of my projects—from tiny to big, server-side or front-end—there was always a challenge, a problem to tackle or an obstacle to overcome before I can update or sometimes even just run my program. why i moved mostly from writing node cmd tools to using bash. don't need to go on a bunch of side missions every time i run npm ins…

Why learn cmd and bash when you can just learn js? Easier to maintain 1 language than 1+. My software in js from 7 years ago still works.

This comment here is exactly the problem with JS people. If you are making a big thing out of learning(!) cmd(!!!) then you shouldn't be working in software development, period. 7 years is a flex only in a JS world. As others mentioned, try 35.

Re: Programs are dead, and JavaScript has killed them

#207

Post by namaria »

AshleysBrain wrote: post #64

I think the overlooked lesson is: the more technology you add in to your stack, the harder it is to maintain. Shallow tech stacks - using fewer tools and frameworks wherever possible - are usually a good idea to minimise your maintenance headaches. If you're making a small quick tool, vanilla JavaScript is not a bad choice. You don't have to use npm, TypeScript, and a bunch of frameworks. If you do anyway then sure,…

Fred Brooks has been warning us that the key problem with software development is 'how to keep complexity at bay'. Half a century later we're still wondering why sloppy complexity management bites us in the ass later on.

Re: Programs are dead, and JavaScript has killed them

#208

Post by Doxin »

AshleysBrain wrote: post #64

I think the overlooked lesson is: the more technology you add in to your stack, the harder it is to maintain. Shallow tech stacks - using fewer tools and frameworks wherever possible - are usually a good idea to minimise your maintenance headaches. If you're making a small quick tool, vanilla JavaScript is not a bad choice. You don't have to use npm, TypeScript, and a bunch of frameworks. If you do anyway then sure,…

There's still a difference between javascript and other languages with respect to dependencies. E.g. if I open a 5yr old python project there's a fair chance all the dependencies still exist and still work with a more recent python interpreter, let alone work at all.

My --limited, to be fair-- experience with npm is that you can barely look away from a project for a week or it'll have a bunch of deeply broken dependencies, requiring you to update them which then breaks other dependencies in turn.

Re: Programs are dead, and JavaScript has killed them

#209

Post by wellanyway »

codyswann wrote: post #151

Man. People complain that JavaScript sucks as a language and then complain when it evolves too quickly to appease these same people. Oh well.

It evolves too quickly for 20 years fixing fundamental issues tgat stem from the hacky origin of the language.

Re: Programs are dead, and JavaScript has killed them

#210

Post by kingboss »

yazaddaruvala wrote: post #174
hnbad wrote: post #21

Earlier quoted context omitted.

I see you haven't watched this talk about the history of JavaScript between 1995 and 2035 since that's exactly what happened in this future: https://www.destroyallsoftware.com/talks/the-birth-and-death...

I have! It's a very good talk. I wouldn't make any design or technology decisions based on it tho. What is clear today is that Javascript is on every computer in the world (including phones). It is now even taking over for native desktop apps and native mobile apps. At this point, including a JS engine into all the kernels for apps and browsers to use just seems prudent.

JS in kernel is a beyond idiotic idea. Why the hell would you put something like that in the kernel? Computing world has lost its mind if this can even come up as a suggestion.

I just feel that 90% of people on this website are junior web devs. That must be the reason for the glorification of a POS language such as JS. Why the hell would you even want to run this garbage language on the server? Now you want it in the kernel? Insanity....

Post reply on HN