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

301–310 of 323 posts

Re: JavaScript is Eating the World

#301

Post by flavio81 »

seanwilson wrote: post #296
flavio81 wrote: post #293

Earlier quoted context omitted.

My take is that having dynamic typing plus strong typing is a (pretty) good compromise. And static typing plus weak typing, insufficient.

What languages would you put in these two categories?

Not all languages but here's a list:

dynamic typing, strong typing: python (for the most part), Scheme

dynamic typing, weak typing: Javascript, PHP

static typing, strong typing: Pascal, Ada, Java, C#

static typing, weak typing: C, Typescript, perhaps others

SPECIAL CASES:

strongly typed, dynamically typed, but with some compilers it can also be statically typed: Common Lisp

strongly typed, statically typed but can infer types: Haskell, ML family

strongly typed, can infer type with "auto" keyword: C++ (latest version)

non-typed: Machine language, assembler, perhaps Forth

Re: JavaScript is Eating the World

#302

Post by tisdy »

TrickyRick wrote: post #44
johannes1234321 wrote: post #28

Earlier quoted context omitted.

In Nginx you're not doing computation, just passing IO thru between file system, external processes (i.e. PHP via fpm) and the network. If Nginx ever is CPU bound there's something bad happening. As I mentioned PHP: In PHP each worker is single threaded, too, but you can scale by having more workers in isolation.

What computations do you do in a webserver which hosts a REST API? Most of it is simple CRUD connected to a database, possibly with an auth layer on top, which is pretty much what you describe, passing IO through to a database and back.

Honest related question:

Does HN think putting 2-15KB JSON blobs in a Postgres DB running on Docker on a router is a good idea? Oh, and the table stores log data, so there's about 2 million rows after 5 days uptime. What do you think?

EDIT: This was not entirely related but it goes to the notion that it seems like a lot of myopic decision-making has somehow become even more acceptable and I would say this leads to dumb situations as above, and Node.

Re: JavaScript is Eating the World

#303

Post by seanwilson »

flavio81 wrote: post #301
seanwilson wrote: post #296

Earlier quoted context omitted.

What languages would you put in these two categories?

Not all languages but here's a list: dynamic typing, strong typing: python (for the most part), Scheme dynamic typing, weak typing: Javascript, PHP static typing, strong typing: Pascal, Ada, Java, C# static typing, weak typing: C, Typescript, perhaps others SPECIAL CASES: strongly typed, dynamically typed, but with some compilers it can also be statically typed: Common Lisp strongly typed, statically typed but can in…

What better alternative do you have to TypeScript right now though that you can use practically with existing libraries? Perfect is the enemy of good. TypeScript can capture more complex properties than C as well.

Re: JavaScript is Eating the World

#304

Post by exo128 »

tchaffee wrote: post #248
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? Not a great analogy. A more accurate analogy is switching from one very big toolbox to another very big toolbox. If you are used to one and know where all the tools are, and they have been used so much that the wood perfectly fits your hand, then it's just going to take some time to get used to the new toolbox. I'm not saying it's a hard rule and you s…

Going further with the toolbox analogy...

Imagine we have carpenters and brick layers. Two distinct jobs that maybe have some overlap of tools.

We decide that we have a lot more carpenters than brick layers, so we'll take a carpenters' toolbox and add a few brick layer inspired tools to it (but they're not necessarily the same, and some of the tools that can overlap maybe aren't quite as specialized, nuances, nuances, etc.).

Now, we can tell our managers that our problems are solved. All of our carpenters can now do masonry work.

The root problem of all of this mess is that both of these domains are different. Problems and solutions in the front-end tend to be different than in the back-end.

Management is sold on this "everyone is an interchangeable cog now" fantasy they have been chasing for decades and crappy decisions are made. We end up with most developers not really learning at least one of the areas of the full stack very well (and not learning both if they are really striving to under-achieve...).

Note: This same thing happened in Java before NodeJS, but in reverse. Back-end developers refused to really learn web development and so we ended up with misguided solutions like GWT and virtually every other high level Java web framework/library.

Perhaps I haven't run into the right people, but mostly my experience with other JavaScript devs is they don't even know the fundamentals really (they don't understand scope rules in JS, they don't really understand weak typing, they don't understand JS is single threaded, they don't understand closures very well, etc.). I don't know if this lack of understanding is due to a lack of experience programming at all, or just not really learning JavaScript (many non-JS devs are forced to learn enough JS to get the front-end working -- or at least seemingly working).

The thought of lowering the bar on development even further is frightening (Johnny did some web development last year, I'm sure he can transition to writing our back-end API since he knows JS). I'm all for anyone learning and improving as a developer -- and sharing in my passion. What I hate is this false confidence more and more people seem to have with everything and the problems it causes (they don't bother to learn the tools they have or the tools that came before them, they are too lazy to learn a new language/framework/library, and they have extreme NIH syndrome).

Re: JavaScript is Eating the World

#305

Post by crimsonalucard »

kin wrote: post #290
crimsonalucard wrote: post #289

Earlier quoted context omitted.

Is that a good thing? I would argue that enforcing guidelines can make any type of code base workable. The holy grail is a language that enforces guidelines itself, for example: a type system.

I think static vs. loosely typed both have their pros and cons but that's the thing that's great about the Javascript community. It's not opinionated on things like this. So if you want statically typed, then you can code in Typescript. This is in contrast to something like Rails which is super opinionated and doesn't give you much of a choice if you as a developer or even as a company as a whole were to disagree wit…

Also rails is not a language, it is a framework, aka an opinion. Languages should lean towards being opinion agnostic while frameworks by there very nature should be opinionated.

Re: JavaScript is Eating the World

#306

Post by Retra »

abrax3141 wrote: post #47
voidhorse wrote: post #10

I think a few aspects of the language contribute to this: 1. It is relatively easy to comprehend and pick up and play around with. 2. With the advent of node.js, and later electron, it is incredibly relevant whether you're developing web apps, servers, or now, even desktop apps. 3. Some of the newer features, such as arrow functions actually make writing javascript a lot of fun! JS has come a long way. I do think the…

Re: fun... You want to have fun programming, use Lisp. (Which, BTW, invented "arrow" fns ... aka Lambda functions!)

Lisp did not 'invent' Lambda functions, they were invented by Alonzo Church in the 1930s. And even that was only a minor syntactical innovation.

Re: JavaScript is Eating the World

#307

Post by mch82 »

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.

See also, Excel and VBA in corporate America. Will companies let employees install language environment X? Probably not, but they'll have access to Excel with VBA.

Re: JavaScript is Eating the World

#308

Post by TheDongIsYou »

quacker wrote: post #288
always_good wrote: post #236

Earlier quoted context omitted.

I don't understand the distinction. JavaScript tooling is notoriously complicated on the front-end, not the back-end. And I doubt they're saying that they switched to Python on the front-end.

> I don't understand the distinction. The distinction was that cdnsteve was motivated to switch to Python due to issues with the toolchain and build system, not that JavaScript was weakly-typed. > JavaScript tooling is notoriously complicated on the front-end, not the back-end. And I doubt they're saying that they switched to Python on the front-end. You have a good point, though you still have to pull in dependencie…

I still don't see the point, you'll probably need to pull dependencies whether you use is or any other language.

And as for build tools, people like to complain way too much, maybe they prefer just using bash scripts instead..

Re: JavaScript is Eating the World

#309

Post by TheDongIsYou »

flavio81 wrote: post #93
talmand wrote: post #37

Earlier quoted context omitted.

I'm beginning to think npm has joke potential like regex. "I had a problem. I started using regex and now I have two problems." Becomes... "I had a problem. I ran npm install and now I have 21,735 problems."

For me, going from Lisp package installs to Node package installs was like traveling from a Bahamas beach to Siberia, with the same clothes. ES7 is okay, Node.js is good, V8 is GREAT, but NPM is an atrocity.

Can you elaborate why? Aside from install times which there are solutions for.

Re: JavaScript is Eating the World

#310

Post by coldtea »

wolco wrote: post #279
coldtea wrote: post #123

Earlier quoted context omitted.

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

Maybe against php 4. PHP 7 is much faster

It's just about 2x as fast as PHP5.

JS JIT were already many times faster than PHP5. There's no comparison to the complexity, quality, resources and top-notch teams in play in JS JITs (just consider the vendors making them: Google, Apple, Microsoft and Mozilla) and PHP.

Post reply on HN