Live data from Hacker News

JavaScript is Eating the World

dev.to

191–200 of 323 posts

Re: JavaScript is Eating the World

#191

Earlier quoted context omitted.

Theoretically, to what extend could the weird type conversions be prevented with the use of a strict linter? My intuition would be all, but I haven't thought much about it.

Once code reaches a certain complexity level (and mind you, the threshold is rather low), you'll need dynamic generation of code and data (or else, write 10x the amount of lines of code). For this to happen in a safe way, you really, really, do need the runtime to be strictly typed.

Are you making this claim about JavaScript or as a general statement? I've probably written less than 1000 lines of JS ever (and that only for hobby projects), but I would strongly disagree with this statement as applied to C++, Java, etc.

Re: JavaScript is Eating the World

#192
We really need to stop putting Javascript on the back end when there are so many other great options that won't be any different to the front end in most (all?) cases. I think working on full fledged Javascript solutions for the front end that address load time and page size is great. It still amazes me why anyone would use Javascript on the back end willingly.

Re: JavaScript is Eating the World

#193
post #30

ARG! The floating point handling in JS bites (bytes?) me almost daily. I code in JS every day but I hate this number "bug" the most. Having to frob back and forth with "int" to make it not totally broken. Am I the only one?

https://github.com/MikeMcl/decimal.js-light

Re: JavaScript is Eating the World

#194

Earlier quoted context omitted.

This sounds a lot like how it's possible to fit a square peg in a round hole if you have the right drills and grinders and so on.

That's exactly what it is. The fundamental issue is that the overwhelming majority of interactive websites today don't actually need to be interactive, and may even be better off as old-fashioned HTML pages served by the server. But people love over-complicating stuff, and when the end result is complex the toolchain has to be complex too, not just for one person but the whole team. Then you end up with developers wh…

Can you list any examples? My hunch is that there are good reasons javascript is included on most sites where it is found.

Some of the incentives fueling this trend could be viewed as undesirable (e.g. monstrous ads on news sites as a desperate bid for profitability), but that doesn't negate the fact that the incentives exist, and aren't simply "people love over-complicating stuff".

Re: JavaScript is Eating the World

#195

Earlier quoted context omitted.

> That's the point. There is no explanation, other than the same reason that bellbottoms are in again this year. Or out, I don't actually know. You mean you can't come up with one. Because for me, which followed the scene for 20+ years, there is a perfect explanation.

I have no horse in this race; Care to share the perfect explanation?

Look upthread:

https://news.ycombinator.com/item?id=15090542

Re: JavaScript is Eating the World

#196

The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.

For the millionth time: It is not accurate to refer to it as single threaded.

The language is non-blocking, so any asynchronous tasks (DB read/writes, disc I/O, cache, http, etc) will immediately jump to processing the next request the moment it is not doing blocking computation.

Non-blocking:

    [aa][bb][cc][/aa][/cc][/bb][dd][ee][ff][gg][/dd][/ff][/gg][/ee]
Blocking-threaded:

    [aa]------------------------[/aa][ff]----------------------[/ff]

    [bb]------------------------[/bb][gg]----------------------[/gg]
    
    [cc]------------------------[/cc][ee]----------------------[/ee]
    
    [dd]------------------------[/dd]
Depending on how many threads you can get going at once, you may be able to achieve comparable performance doing threading, but nonblocking is basically leaving 0 time on the core wasted and limited to the speed of the event loop.

And then on top of that, clustering module is used to do the same thing on every core.

Re: JavaScript is Eating the World

#197
post #36
post #32

Earlier quoted context omitted.

Do you deny that implementations are part of the language? If the Javascript specification left this out, what other implementation gotchyas exist for them to exploit?

Few but you likely consider the implementation part of the language.

C explicitly states what an implementation should and should not do. The same with C++, FORTRAN, and other standards. Javascript is a standard written by committee. So why can't it tell implementations what is good behavior and what isn't? Other languages do.

Re: JavaScript is Eating the World

#198

The more time goes by the more I feel crazy for missing whatever would motivate people to use js for anything more than is strictly necessary. Single threaded server??? I mean come on man, I understand you don't need parallelism for a lot of use cases but even if that fits your situation why javascript? It can't be that hard using a different language. I refuse to believe that.

The argument that people always throw at me is that too hard for people to know two languages, well, for frontend devs to know two languages. Now in a perfect world the frontend people who just can't figure out two or more languages would never touch the backend but the world of software now is "that'll do" not "what is the right tool." It's a shame to me really but I'm not a frontend dev for a reason.

Re: JavaScript is Eating the World

#199
post #17

The other day I managed to freeze my computer -- such that I did not even have access to the SysReq key, by stupidly running while (true) { var d = new Date; e.textContent = d.toLocaleString(); } I immediately realised my stupidity, and closed the tab. Shortly after, my mouse froze up, then my keyboard access, and eventually my entire access. Rather than just freezing Xorg as I had initially suspected, it froze my en…

I would have thought that all competent browsers run tabs in unique processes.

That's what I thought too. I think the process was so locked up in executing the code that it perhaps didn't respond to the kill message?

Re: JavaScript is Eating the World

#200
post #139

The fact that JavaScript and the web platform kind of sucks while at the same time being "unavoidable" is why it's so good. It forced a lot of very smart people and a lot of eyes onto the platform to try and find solutions within the extremely restrictive "box" to these problems. How do you solve the API issues when you don't control the platform? How do you solve for perf when things can't be installed? How do you s…

These are why I dislike the javascript ecosystem. It's like a giant game of codegolf -- solving problems that shouldn't be solved overcoming constraints that shouldn't be imposed using creativity that ought to be spent on the big picture.

"Very smart people" are great at twisting and stretching and finding the most optimal possible solution within the restrictive box that you give them. But they're not always great at stepping back and asking bigger questions:

* Why was the box put there in the first place?

* Doesn't my solution defeat the point of the box?

* What are the alternatives to the box?

* Is it possible that I'm wasting tons of time and energy on a problem that would be trivial outside of the box?

Post reply on HN