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

JavaScript is Eating the World

dev.to

Post reply on HN
Print view View original

251–260 of 323 posts

Re: JavaScript is Eating the World

#251

Post by nightski »

mayank wrote: post #227
bo1024 wrote: post #200

Earlier quoted context omitted.

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 a…

The questions you ask are great, but slightly less important when you add the fact that everyone has the box already, and getting them to use a new box has been tried incessantly over the years, and yet here we are with the same old box. Tl;dr -- pragmatism is why the web ecosystem is eating the world, not optimal design.

There are three players in the game right now all of whom can push updates to the vast majority of their user base very quickly. This isn't a problem like it was back in the day. Now it's pure stubbornness.

Re: JavaScript is Eating the World

#252

Post by collyw »

falcolas wrote: post #43
lunchables wrote: post #14

Earlier quoted context omitted.

I just tell myself it's because the sales pitch is so appealing: learn, and use, one programming language on the front end and back end of your web site. I've never written anything on node.js, but that's the only argument that's ever given me pause.

It honestly doesn't give me pause, since the impedance mismatch between JavaScript and backend programming is so great. To me, the fact that Node has to add a library with custom semantics just to allow a basic 'open' on a file handle is a huge warning flag to me.

Its been a while since I wrote and Java, but when I did you needed a page of code just to open a file.

Re: JavaScript is Eating the World

#253

Post by rootlocus »

coldtea wrote: post #123
rootlocus wrote: post #110

Earlier quoted context omitted.

> If I'm better at one language than another, it is at least somewhat harder. Why struggle when you can flow? If you're better with screwdrivers, why struggle with a hammer? JavaScript has a painfully slow runtime. Writing servers requires attention to performance and reliability, which javascript is very poor at. If you want to make a toy service and don't care about any of this, go ahead and use your favourite lang…

> If you're better with screwdrivers, why struggle with a hammer? Hammers and screwdrivers are not general purpose tools in the way that languages are. For most things, most languages are just as fine. It's not like JS is specialized in some very small niche by design -- like e.g. COBOL is. > JavaScript has a painfully slow runtime. I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of ta…

> I call BS. v8 is one of the fastest dynamic runtimes, at 2x of C or so for lots of tasks, and it totally obliterates Python, PHP, Ruby, and co in speed.

Any proof for this?

EDIT:

According to "The Computer Language Benchmarks Game"

JavaScript fares pretty well against Python [1] or Ruby [2] but not really that great against C [3] or Java [4] in the CPU intensive benchmarks.

1 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

2 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

3 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

4 http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

Re: JavaScript is Eating the World

#254

Post by ovao »

falcolas wrote: post #240
ovao wrote: post #133

Earlier quoted context omitted.

I'm not a particular fan of JavaScript on the server these days, but when you have a large number of developers who know JavaScript from the front-end world and a language ecosystem that's quite large and relatively robust, I would argue that doing those "major workarounds" (which aren't so major, really) to make server-side JavaScript an accessible option at least very closely resembles the "right thing to do". Shou…

Here's my thoughts about that from a sibling thread: https://news.ycombinator.com/item?id=15090278 TL;DR: Writing JavaScript for the browser won't really help you write good JavaScript for the server.

While I think we agree on points, I also feel like your argument is kind of an overgeneralization. There are knowledge points specific to Node, but developing good code for the browser has similar land mines (referring mainly to asynchrony here) as developing for the server. The problems that exist at the language level, and best practices, are generally applicable to both the server and the browser.

As far as libraries are concerned, it was never my experience that the landscape changed drastically from one to the other. Most of the libraries I look at/use for the front-end today advertise themselves as both for Node and for the browser.

Re: JavaScript is Eating the World

#255

Post by shados »

nightski wrote: post #251
mayank wrote: post #227

Earlier quoted context omitted.

The questions you ask are great, but slightly less important when you add the fact that everyone has the box already, and getting them to use a new box has been tried incessantly over the years, and yet here we are with the same old box. Tl;dr -- pragmatism is why the web ecosystem is eating the world, not optimal design.

There are three players in the game right now all of whom can push updates to the vast majority of their user base very quickly. This isn't a problem like it was back in the day. Now it's pure stubbornness.

4 players (edge, firefox, safari and chrome, and no the last 2 are no longer close). One of them, the usual suspect, is still dog slow to update.

But even with that, wasm, service workers and other major changes don't come overnight. The rest of us still have a job to do.

Re: JavaScript is Eating the World

#256

Post by acuozzo »

infinisil wrote: post #75
tomascot wrote: post #68

Earlier quoted context omitted.

I had a client that asked me to rewrite our software in JS. He didnt know anything about programming but said he preferred JS.

I haven't ever written professional software, but I just took a software engineering course and what I learned is that what technology stack to use is none of the clients business.

> what technology stack to use is none of the clients business

Until your client is unable to find competent programmers to hire to do maintenance after you're gone because you chose to use something esoteric.

A big reason why there are so many JavaJobs™ is that there are so many programmers with Java listed on their résumé/CV.

Your client needs to look ahead and plan for the possibility of his/her entire dev team being poached on the same day.

Re: JavaScript is Eating the World

#257

Post by collyw »

always_good wrote: post #233
tomc1985 wrote: post #189

Earlier quoted context omitted.

> It's symptomatic of deep unmet emotional needs in that person's life. Pretty sure pronouncements like that are the real indicator of unmet emotional needs. The way this community needles dissenting opinions needs to change. If you don't like the HN flavor of things, the resulting swarm of nitpicking, self-righteous commenters blots out the sun.

Eh, scroll through the comments in every submission that mentions JavaScript (like this one) and you'll see a bunch of people lambasting anyone that uses JavaScript. "Ugh, why would anyone use it on the server? Idiots!" "Lol web developers only know one language. Sad!" As if anybody that chooses a different set of trade-offs is incompetent, not just comfortable with a different set of trade-offs.

Maybe they say that because they have used better languages, rather than unmet emotional needs.

Re: JavaScript is Eating the World

#258

Post by defined »

amorphid wrote: post #152
dboreham wrote: post #136

Earlier quoted context omitted.

My take on this (I have had the same experience, fwiw) is that it is like the well-known story of bridges falling down due to experienced engineers retiring (Tay Bridge Disaster, Tacoma Narrows Bridge for example). A new generation of folks who actually believe that "Single Threaded is a benefit" arrive on the scene and make a bridge that falls down..

I used to love to idea of a global interpretator and/or a single thread (coding without concurrency). It was great until it wasn't. Learning Elixir helped me get over that.

I'm an Erlang practitioner since 2007 and I approve this message ;)

Learn Elixir or Erlang and show that there's an alternative to Node.js that's both fun and powerful - and battle tested.

Re: JavaScript is Eating the World

#260

Post by defined »

always_good wrote: post #225
eropple wrote: post #164

Earlier quoted context omitted.

Single-threaded isn't a benefit, but in a world where multi-process isn't a problem, a lot of that is blunted. Granted, for problems that are both compute- and IO-heavy, something like the JVM makes much more sense (so just use it--duh, right?). For throwing bytes over a wire, something like Node is really, really easy and really, really effective. My biggest beef with it is the weak libraries for talking to RDBMSes,…

>Single-threaded isn't a benefit Huh? Of course it has some benefits. Unfortunately everything is just trade-offs. A benefit of single-threadedness is that you don't deal with the certain pitfalls of multi-threadedness.

Seriously, use Erlang or Elixir and have both concurrency and ease of programming and debugging relative to Node.js. Spoken as someone who has created multiple Erlang projects with close to zero unintended downtime for months or years in production.
Post reply on HN