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

181–190 of 323 posts

Re: JavaScript is Eating the World

#181

Post by tedunangst »

alayek wrote: post #138
krapp wrote: post #96

I feel like it's less Javascript that's eating the world and more Node and NPM. It seems as if it's impossible to publish a Javascript project without taking for granted that the developer has, or even wants , a package manager with dependencies, arbitrary toolchain and transpiler along with it. Maybe I'm just a dinosaur for not wanting my "build process" for javascript to be more complicated than including a script…

The way to look at it, is that browser is a target runtime platform. When you write code in a team, you optimize for readability, maintainability etc. You spread your code over 5 directories, 50 subdirectories, 3000 files. When you want to run this in a browser environment, it needs to be optimized for delivery - faster download, less time-to-be-interactive. You need to split your JS codebase as per routes in your ap…

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.

Re: JavaScript is Eating the World

#182

Post by tjoff »

shados wrote: 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…

I miss the days when javascript meant changing the color of links.

It's hard to admire the work being put into javascript when you see the result every living minute of every day.

Re: JavaScript is Eating the World

#183

Post by tedunangst »

ghostbrainalpha wrote: post #163
Sacho wrote: post #24

Earlier quoted context omitted.

I tried your code snippet on my inferior Windows OS and inferior IE Edge browser. The tab stopped functioning. I opened a few other tabs and continued to work. Eventually IE showed a notice that the tab had stopped responding - I had the option to close the tab or recover the webpage. I clicked 'recover webpage', the page was refreshed and I could continue using it. Truly, Javascript is eating the world. Or perhaps t…

You have me curious. Why would you run IE Edge instead of Chrome?

Edge support for touch screens is considerably better than chrome.

Re: JavaScript is Eating the World

#184

Post by 52-6F-62 »

coldtea wrote: post #115
hood_syntax wrote: post #4

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 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??? So, like Nginx's model? Or 99% of Python servers? You can still run multiple processes...

Yes, I'm surprised nobody has mentioned child processes or the Cluster module.

https://nodejs.org/api/cluster.html

There are a lot of knowledgable people commenting, but it's starting to seem like they haven't familiarized themselves with the tools available within the NodeJs base.

To another point, I could put the time into writing a server and back end application in Go or Rust or C++ or whatever, but it would take (at least me) 10x as long to build out the application I need as it does to pull express into a project and build out a server, back end computations, file manipulation, authentication, and roll a MongoDB store with a fully-fleshed out front end (even if it's not so stylish).

Mind you I work in an enterprise environment where these kinds of things are required to serve maybe twenty people and run on a single multi-cored machine at any given time and not tens of thousands users.

It's a fantastic tool that works from small to mid-large projects, and would serve as an excellent prototyping and MVP-dev environment for even the naysayers who are probably more skilled than I am in other areas.

Re: JavaScript is Eating the World

#185

Post by holydude »

My personal opinion is that what applies to big companies offering "free" products applies in tech as well.I call it the good enough concept. The product is not exceptional but it is good enough when you consider all things involved (price in case of big companies (it being free) and performance in case of javascript.

So for a lot of people web apps are good enough. They do not need native apps. The same applies to developers. Sure you can avoid transpiling to JS but JS also became good enough for people to just stick to it. And while they were at it they found out it is also good enough on the backend (nodejs) and on the mobile (react native) and also on the desktop (electron).

Only time will tell if it is or was the right choice.

Re: JavaScript is Eating the World

#186

Post by shados »

DonbunEf7 wrote: post #168
shados wrote: 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…

I bet you love pugs, bulldogs, and dalmatians too.

I'm a cat person.

Re: JavaScript is Eating the World

#187

Post by enraged_camel »

tedunangst wrote: post #181
alayek wrote: post #138

Earlier quoted context omitted.

The way to look at it, is that browser is a target runtime platform. When you write code in a team, you optimize for readability, maintainability etc. You spread your code over 5 directories, 50 subdirectories, 3000 files. When you want to run this in a browser environment, it needs to be optimized for delivery - faster download, less time-to-be-interactive. You need to split your JS codebase as per routes in your ap…

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 who spend more time wrestling with webpack et al than working on actual features.

Re: JavaScript is Eating the World

#188

Post by quacker »

dirkc wrote: post #172
krapp wrote: post #96

I feel like it's less Javascript that's eating the world and more Node and NPM. It seems as if it's impossible to publish a Javascript project without taking for granted that the developer has, or even wants , a package manager with dependencies, arbitrary toolchain and transpiler along with it. Maybe I'm just a dinosaur for not wanting my "build process" for javascript to be more complicated than including a script…

I felt frustrated by the typical Node toolchain until I remembered the typical Qt toolchain for developing cross-platform desktop apps. I can't remember everything, but here goes. To compile a Qt app you need: - the meta object compiler (moc) to add dynamic features to C++ for Qt use - the Resource Compiler (rcc) to embed icons or sounds as arrays in header files - the Qt Quick Compiler if you are using QML files for…

I think it's more accurate to compare Node to C++, compare NPM to apt/yum/etc+CMake, and compare something like Electron to Qt.

Of course, your point still stands. But's a tradeoff. C++/Qt has a ton of compile-time bloat, while Node/Electron has runtime bloat (see the Slack client using hundreds of megs of ram). And you can use bindings, like PyQt, where you have Python/Qt and then you get Python's dependency management.

Re: JavaScript is Eating the World

#189

Post by tomc1985 »

woah wrote: post #124
fundabulousrIII wrote: post #71

What they don't say in this panegyric to node is that.. 1. The language (js) is absolutely horrific. 2. node is single threaded and non-blocking/async in I/O for some operations but when blocking requires libuv and gymnastics. 3. It moves too fast for stability. I've encountered huge memory leaks with node at various versions that are terrible to debug. 4. It is designed to the lowest possible specification for devel…

There are languages that I like better than JS. However, JS servers power trillions of dollars of business. People who grasp for reasons to hate on JS are a little like people who get into flame wars about video game franchise rivalries. It's symptomatic of deep unmet emotional needs in that person's life.

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

Re: JavaScript is Eating the World

#190

Post by dboreham »

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.

The thing is : it isn't an "idea" at all. These projects ended up with a big lock, or not tolerating reentrancy due to history -- they were developed at a time, and in an environment where there were no threads (or where support for threads wasn't of interest to the developer). It's just a bug. Not an idea, not a benefit. All the talk of it being the best way is nonsense invented after the fact to try to justify something that's just broken.
Post reply on HN