It's weird how a language got to be one of the most popular in the world just by a single feature: It runs in browsers. Everything else about JavaScript is terrible but it runs in browsers. Half...
It's weird how a language got to be one of the most popular in the world just by a single feature: It runs in browsers. Everything else about JavaScript is terrible but it runs in browsers. Half the libraries and hype trends just come down to fixing the mess that the language is at its core but that's super important because it runs in browsers. It barely makes sense to use server-side but it's the only language that runs in browsers so why not focus on the lowest common denominator? It's awfully bloated for native apps but you got a website that runs in browser basically for free.
You're not entirely wrong but you undersell it a little bit based on JS' surface-level features. Node benefits from operating on a language with an already existing userbase but it really wouldn't...
You're not entirely wrong but you undersell it a little bit based on JS' surface-level features. Node benefits from operating on a language with an already existing userbase but it really wouldn't have been such a success if PHP or Python had easy ways to create event-driven asynchronous systems. Javascript frameworks in turn just take advantage of that and reduce the overall complexity of your stack because suddenly instead of having a Java, PHP or Python back-end and a Javascript front-end trying their best to communicate with each other you have everything in one single language.
You imply that it's any more difficult to communicate between Python and a browser than Node and a browser. You need to serialize JSON in each. Python's dictionaries are a great analog to...
instead of having a Java, PHP or Python back-end and a Javascript front-end trying their best to communicate with each other you have everything in one single language
You imply that it's any more difficult to communicate between Python and a browser than Node and a browser. You need to serialize JSON in each. Python's dictionaries are a great analog to Javascript's objects.
One benefit I can see is that you can easily share constants between the server and client code if you have a full JS stack. But I don't know if that's so important.
However, TypeScript does typing much better than typed Python. So if I needed a "typed" language on the back-end I might actually prefer Node.
I'm not sure if it's what @clerical_terrors meant specifically, but if you don't have a JS runtime somewhere on your server, you'll have to duplicate all of your UI logic and templating to do the...
I'm not sure if it's what @clerical_terrors meant specifically, but if you don't have a JS runtime somewhere on your server, you'll have to duplicate all of your UI logic and templating to do the same thing in two different languages. It's a maintenance headache and an easy place for bugs to creep in, and one I'll avoid given the opportunity!
I'm not sure I understand what you mean. Typically there isn't that much copied functionality between frontend and backend processes. Are you talking about user input validation?
I'm not sure I understand what you mean. Typically there isn't that much copied functionality between frontend and backend processes. Are you talking about user input validation?
User-input validation is the big one I run into a lot. Have to verify it on the client for convenience, and then on the server for security. Sharing a codebase for that would be lovely. Another...
User-input validation is the big one I run into a lot. Have to verify it on the client for convenience, and then on the server for security. Sharing a codebase for that would be lovely.
Another real-world example is server-side rendering of a SPA. This is often done on first load for performance reasons.
Input validation is definitely a useful one, but I was actually talking about HTML generation and all the associated logic (URL routing, data mapping, state conditional behaviour, etc.). A lot of...
Input validation is definitely a useful one, but I was actually talking about HTML generation and all the associated logic (URL routing, data mapping, state conditional behaviour, etc.).
A lot of complex sites render the whole thing client side with something like React or Angular, to allow complex interactions and keep the experience smooth and fast. For accessibility, first-load speed, and SEO it's generally a requirement that the server can render the same HTML from the same data - meaning you either have to duplicate all of the logic and templating, or call the JS on the server as well. If you're running at least one JS process on the server, it starts to build an argument for keeping the API in the same process, rather than calling the JS from another language.
Yes this is pretty much exactly what I meant. A simple website with only some basic forms and AJAX calls is easy enough to maintain in a multi-lingual paradigm as long as you're careful but...
Yes this is pretty much exactly what I meant. A simple website with only some basic forms and AJAX calls is easy enough to maintain in a multi-lingual paradigm as long as you're careful but complex webapps benefit from being written in one language for the reasons you've described.
Am I the only one that enjoys writing Javascript? It integrates nicely with the DOM and user events, and there isn't a ton of boilerplate required just to get work done. The dev tools are also...
Everything else about JavaScript is terrible but it runs in browsers.
Am I the only one that enjoys writing Javascript? It integrates nicely with the DOM and user events, and there isn't a ton of boilerplate required just to get work done. The dev tools are also amazing, and I like the overall flow of the language. Functions as a first-class citizen is the way to go. JSON is also a great invention for passing data and constructing objects.
It just seems really nice and fluid to me. Especially once I wrapped my head around closures and real uses for function expressions. There's a few warts ('this' keyword, or requiring 'var/let'), but what language is without issues? Even my lovely Python has the ugliest constructor in town.
So what's the issue today? Lack of a standard library? It's become a lot more powerful in ES6, and common libraries like jQuery are no longer needed.
There's too many libraries/frameworks? They're only tools. They're there to solve a problem. If you don't have that problem, then you probably don't need the tool.
Maybe I simply have different opinions about what constitutes a good language, but I don't get the hate in 2018.
It's fun how fast you can get things done! It's just when something goes wrong, its often a mess. You can feel that it was never intended to be more than a quick scripting language to do things...
It's fun how fast you can get things done! It's just when something goes wrong, its often a mess. You can feel that it was never intended to be more than a quick scripting language to do things like add two numbers on a shopping site or open a popup.
It's nuts how many things evaluate to false/true instead of crashing, which seems to be a measure to make bad code work as good as possible rather than to enforce good code. It's also nuts that there is no integer. But even if you deal with this (at least there's some consistency), you have that philosophy of web development to rely on a complex web of dependencies (a node_modules folder with 30k files for a simple website) that constantly change or break. IMO a ton of that is because it encourages you to rather require some 50-line library that does some simple string manipulation than doing it yourself because that library handles all the potential gotchas. I still remember left-pad.
It's a very "black box" style of coding and a lot of dealing with unenforced standards and special cases that should not exist. In order to have any real confidence to say your code is "stable", you have to do an amount of testing and error-handling that often dwarfs any actual functionality.
This hasn't been my experience. Chrome's dev tools in particular make it very easy to set breakpoints, view callstacks, trace performance, and overall understand exactly what is happening at...
It's just when something goes wrong, its often a mess.
This hasn't been my experience. Chrome's dev tools in particular make it very easy to set breakpoints, view callstacks, trace performance, and overall understand exactly what is happening at runtime.
Firefox is also getting there. We're years beyond Firebug now.
It's nuts how many things evaluate to false/true instead of crashing...
Might this be an argument against loosely typed languages instead? Remember that Javascript has triple equals for strict type comparisons, and double equals for value comparison.
There's also TypeScript if that's more up your alley.
But even if you deal with this, you have that philosophy of web development to rely on a complex web of dependencies (a node_modules folder with 30k files for a simple website) that constantly change or break.
This one might require further explanation. If the website is simple, why does it need a package manager?
I'd refer back to my "tools" argument. Tools are there for your convenience. There's many great Javascript tools for solving issues like CSS transpiling, image optimization, concatenation, minification, bundling, tree shaking, etc. But the developer still needs to choose the right tools for the job. Some devs do reach for a power drill when a hand chisel would suffice.
One final comment on npm. Small libraries aren't necessarily a bad thing, as it means that code is far more likely to be battle tested and stable. But it also adds complexity and dependencies which can carry a cost. Again this one is on the developer to weigh the pros and cons of adding dependencies. I wouldn't take it as a criticism of the language, though.
Javascript was the language of Netscape, and Netscape was king of the browsers in it's time. Similar to how C became the standard or PHP became the standard. I remember back in the aughties even...
Javascript was the language of Netscape, and Netscape was king of the browsers in it's time. Similar to how C became the standard or PHP became the standard.
I remember back in the aughties even Javascript was basically the best way to add interactivity to your site. Sure you had Java applets and Flash, but those were resource hogs, had big security flaws, or were otherwise unwieldy.
"The 2000s" breaks the conventional naming scheme for me of "seventies", "eighties", etc. Also aughties is slightly esoteric but not incorrect, so it's fun.
"The 2000s" breaks the conventional naming scheme for me of "seventies", "eighties", etc.
Also aughties is slightly esoteric but not incorrect, so it's fun.
You know the "seventies", "eighties", etc are abbreviations for the "1970s", "1980s", etc. The question is how to abbreviate "the 2000s". The "aughties" comes from the convention of using "aught"...
You know the "seventies", "eighties", etc are abbreviations for the "1970s", "1980s", etc.
The question is how to abbreviate "the 2000s". The "aughties" comes from the convention of using "aught" as a term for zero (e.g. "double aught buckshot" is 00 buckshot), and trying to force-fit it to the "-ies" suffix.
My vote is for just using the full "the 2000s" without an attempt at abbreviation because the question I ask is: "How do you refer to our current decade, the one from 2010 to 2019?" The "10s" doesn't really make sense since it's occasionally used for the 1910s, so you'll have to specify "the 2010s" anyways.
Of course, the English language is so malleable and up for changing based on the general consensus of its speakers and their customs at the time (e.g. the origin of "OK") so history will be the ultimate decision maker :)
1800-1899 we refer to as "the 1800s", 1900 to 1999 "the 1900s", and 1910-1919 is "the 1910s" but not "the tens", yet 1920-29 = "the twenties", 1930-39 = "the thirties" and so on... yet most people...
1800-1899 we refer to as "the 1800s", 1900 to 1999 "the 1900s", and 1910-1919 is "the 1910s" but not "the tens", yet 1920-29 = "the twenties", 1930-39 = "the thirties" and so on... yet most people often refer to 2000-2009 as "the 2000s" instead of 2000-2999 like we did the previous centuries. And what will we end up calling 2010-19? Surely not "the tens" nor 2020-2029 "the twenties" again since that would be confusing! So will the naming convention change to account for us using "the 2000s" for a decade instead of a century like the previous ones, and instead we will use "the 2010s", "the 2020s", "the 2030s" and so on? It's so weirdly inconsistent! :P
It seems fairly likely to me that we end up with "the teens" and "the twenties," a 100 year gap is enough that there won't be a conflict in daily conversation and every alternative takes a whole...
And what will we end up calling 2010-19, surely not "the tens" since that would be confusing, not 2020-2029 "the twenties" again...
It seems fairly likely to me that we end up with "the teens" and "the twenties," a 100 year gap is enough that there won't be a conflict in daily conversation and every alternative takes a whole lot more work. Whatever we land on for the first decade of this century is up in the air, since that's always been awkward even just to talk about the first decade of the last century. I'm pulling for just "the aughts" with no -ies, but I doubt it'll pan out that way.
Nah, that'll be the new 'roaring twenties' and don't think for one second marketing won't make mountains of hay out of that one. I was just reading this set of comments thinking 'it's aughts!' -...
Nah, that'll be the new 'roaring twenties' and don't think for one second marketing won't make mountains of hay out of that one.
I was just reading this set of comments thinking 'it's aughts!' - aughties makes me cringe for some reason.
Generally, when dealing with slang, the term with the smallest number of syllables always wins, because people are lazy. ;)
JavaScript has a weird history. Netscape wanted to compete with Microsoft and collaborated with Sun to bring Java into its browser. That didn't work out but the "Java" part stuck despite it being...
JavaScript has a weird history. Netscape wanted to compete with Microsoft and collaborated with Sun to bring Java into its browser. That didn't work out but the "Java" part stuck despite it being completely different. Java was huge for web development back then (arguably still is), so its syntax was chosen over Python or similar. They eventually had a single guy write a JavaScript prototype over the course of 10 days. It took longer to actually get a release but the whole thing was still a rushed mess. Because Netscape was huge in the 90s and it was quickly standardized, it somehow stuck.
I must say, for some quick and dirty in-browser functionality (as it was initially intended to be used!) JavaScript is very okay! Way better than having to run some external plugin. It's just ridiculous what kind of complex code is now written in JavaScript. Go to the google.com homepage and "view source". It's anxiety-inducing!
I use JS at work for manipulation of data streams, I believe this is mainly because the IDE we use for our ETL work only has a JS plugin available, but it seems to work fairly well. I'm a newbie...
I use JS at work for manipulation of data streams, I believe this is mainly because the IDE we use for our ETL work only has a JS plugin available, but it seems to work fairly well.
I'm a newbie programmer though so what do I know :)
OK, so I finally took the time to look over each page of this. At first I thought everything sounded just about right. Of course everyone's using React now, GraphQL is the new hotness, and most...
OK, so I finally took the time to look over each page of this. At first I thought everything sounded just about right. Of course everyone's using React now, GraphQL is the new hotness, and most people who have touched Angular don't want to ever do that again.
And then I looked at how 85% of everyone said they liked building JS apps and I realized the respondents must clearly be insane. /s
In all seriousness, I am much happier with the state of the JS ecosystem now compared to just one or two years ago when the whole JS world was exploding. After all, it's really hard to take advantage of an explosion. I'll admit, though, that most of the reason for me hating it so much was having to mangle manage learning Angular.
The one thing I'm really surprised about is just how popular Typescript is. ECMA really needs to add a typing system of some sort into the next version of JavaScript.
The way I see Typescript is that it allows you to add a layer on top which forced you yo write somewhat better code, similar to how PHP 7 introducted static typing. Most of the interesting...
The way I see Typescript is that it allows you to add a layer on top which forced you yo write somewhat better code, similar to how PHP 7 introducted static typing. Most of the interesting features like classes and imports exist in ES6+ but having a transpiler yell at you for giving a string where an int is expected is still somewhat useful imo.
It's weird how a language got to be one of the most popular in the world just by a single feature: It runs in browsers. Everything else about JavaScript is terrible but it runs in browsers. Half the libraries and hype trends just come down to fixing the mess that the language is at its core but that's super important because it runs in browsers. It barely makes sense to use server-side but it's the only language that runs in browsers so why not focus on the lowest common denominator? It's awfully bloated for native apps but you got a website that runs in browser basically for free.
You're not entirely wrong but you undersell it a little bit based on JS' surface-level features. Node benefits from operating on a language with an already existing userbase but it really wouldn't have been such a success if PHP or Python had easy ways to create event-driven asynchronous systems. Javascript frameworks in turn just take advantage of that and reduce the overall complexity of your stack because suddenly instead of having a Java, PHP or Python back-end and a Javascript front-end trying their best to communicate with each other you have everything in one single language.
You imply that it's any more difficult to communicate between Python and a browser than Node and a browser. You need to serialize JSON in each. Python's dictionaries are a great analog to Javascript's objects.
One benefit I can see is that you can easily share constants between the server and client code if you have a full JS stack. But I don't know if that's so important.
However, TypeScript does typing much better than typed Python. So if I needed a "typed" language on the back-end I might actually prefer Node.
I'm not sure if it's what @clerical_terrors meant specifically, but if you don't have a JS runtime somewhere on your server, you'll have to duplicate all of your UI logic and templating to do the same thing in two different languages. It's a maintenance headache and an easy place for bugs to creep in, and one I'll avoid given the opportunity!
I'm not sure I understand what you mean. Typically there isn't that much copied functionality between frontend and backend processes. Are you talking about user input validation?
User-input validation is the big one I run into a lot. Have to verify it on the client for convenience, and then on the server for security. Sharing a codebase for that would be lovely.
Another real-world example is server-side rendering of a SPA. This is often done on first load for performance reasons.
Input validation is definitely a useful one, but I was actually talking about HTML generation and all the associated logic (URL routing, data mapping, state conditional behaviour, etc.).
A lot of complex sites render the whole thing client side with something like React or Angular, to allow complex interactions and keep the experience smooth and fast. For accessibility, first-load speed, and SEO it's generally a requirement that the server can render the same HTML from the same data - meaning you either have to duplicate all of the logic and templating, or call the JS on the server as well. If you're running at least one JS process on the server, it starts to build an argument for keeping the API in the same process, rather than calling the JS from another language.
More here, if you're interested: https://medium.com/airbnb-engineering/isomorphic-javascript-the-future-of-web-apps-10882b7a2ebc
Yes this is pretty much exactly what I meant. A simple website with only some basic forms and AJAX calls is easy enough to maintain in a multi-lingual paradigm as long as you're careful but complex webapps benefit from being written in one language for the reasons you've described.
Am I the only one that enjoys writing Javascript? It integrates nicely with the DOM and user events, and there isn't a ton of boilerplate required just to get work done. The dev tools are also amazing, and I like the overall flow of the language. Functions as a first-class citizen is the way to go. JSON is also a great invention for passing data and constructing objects.
It just seems really nice and fluid to me. Especially once I wrapped my head around closures and real uses for function expressions. There's a few warts ('this' keyword, or requiring 'var/let'), but what language is without issues? Even my lovely Python has the ugliest constructor in town.
So what's the issue today? Lack of a standard library? It's become a lot more powerful in ES6, and common libraries like jQuery are no longer needed.
There's too many libraries/frameworks? They're only tools. They're there to solve a problem. If you don't have that problem, then you probably don't need the tool.
Maybe I simply have different opinions about what constitutes a good language, but I don't get the hate in 2018.
It's fun how fast you can get things done! It's just when something goes wrong, its often a mess. You can feel that it was never intended to be more than a quick scripting language to do things like add two numbers on a shopping site or open a popup.
It's nuts how many things evaluate to false/true instead of crashing, which seems to be a measure to make bad code work as good as possible rather than to enforce good code. It's also nuts that there is no integer. But even if you deal with this (at least there's some consistency), you have that philosophy of web development to rely on a complex web of dependencies (a node_modules folder with 30k files for a simple website) that constantly change or break. IMO a ton of that is because it encourages you to rather require some 50-line library that does some simple string manipulation than doing it yourself because that library handles all the potential gotchas. I still remember left-pad.
It's a very "black box" style of coding and a lot of dealing with unenforced standards and special cases that should not exist. In order to have any real confidence to say your code is "stable", you have to do an amount of testing and error-handling that often dwarfs any actual functionality.
This hasn't been my experience. Chrome's dev tools in particular make it very easy to set breakpoints, view callstacks, trace performance, and overall understand exactly what is happening at runtime.
Firefox is also getting there. We're years beyond Firebug now.
Might this be an argument against loosely typed languages instead? Remember that Javascript has triple equals for strict type comparisons, and double equals for value comparison.
There's also TypeScript if that's more up your alley.
This one might require further explanation. If the website is simple, why does it need a package manager?
I'd refer back to my "tools" argument. Tools are there for your convenience. There's many great Javascript tools for solving issues like CSS transpiling, image optimization, concatenation, minification, bundling, tree shaking, etc. But the developer still needs to choose the right tools for the job. Some devs do reach for a power drill when a hand chisel would suffice.
One final comment on npm. Small libraries aren't necessarily a bad thing, as it means that code is far more likely to be battle tested and stable. But it also adds complexity and dependencies which can carry a cost. Again this one is on the developer to weigh the pros and cons of adding dependencies. I wouldn't take it as a criticism of the language, though.
I guess it's less poor JavaScript itself but the complexity and brittleness of the web development ecosystem it mostly exists in.
How did such a language even gain support in all browsers? Why not the better ones already existing in 1995? Or a more professionally designed one
Javascript was the language of Netscape, and Netscape was king of the browsers in it's time. Similar to how C became the standard or PHP became the standard.
I remember back in the aughties even Javascript was basically the best way to add interactivity to your site. Sure you had Java applets and Flash, but those were resource hogs, had big security flaws, or were otherwise unwieldy.
Oh no. I haven't heard that before but I already don't like it.
I seem to have a negative physiological reaction to that decade being called anything but "the 2000s". Every other naming scheme just sounds... wrong.
The most 2000's thing possible is to call them the noughties
"The 2000s" breaks the conventional naming scheme for me of "seventies", "eighties", etc.
Also aughties is slightly esoteric but not incorrect, so it's fun.
You know the "seventies", "eighties", etc are abbreviations for the "1970s", "1980s", etc.
The question is how to abbreviate "the 2000s". The "aughties" comes from the convention of using "aught" as a term for zero (e.g. "double aught buckshot" is 00 buckshot), and trying to force-fit it to the "-ies" suffix.
My vote is for just using the full "the 2000s" without an attempt at abbreviation because the question I ask is: "How do you refer to our current decade, the one from 2010 to 2019?" The "10s" doesn't really make sense since it's occasionally used for the 1910s, so you'll have to specify "the 2010s" anyways.
Of course, the English language is so malleable and up for changing based on the general consensus of its speakers and their customs at the time (e.g. the origin of "OK") so history will be the ultimate decision maker :)
1800-1899 we refer to as "the 1800s", 1900 to 1999 "the 1900s", and 1910-1919 is "the 1910s" but not "the tens", yet 1920-29 = "the twenties", 1930-39 = "the thirties" and so on... yet most people often refer to 2000-2009 as "the 2000s" instead of 2000-2999 like we did the previous centuries. And what will we end up calling 2010-19? Surely not "the tens" nor 2020-2029 "the twenties" again since that would be confusing! So will the naming convention change to account for us using "the 2000s" for a decade instead of a century like the previous ones, and instead we will use "the 2010s", "the 2020s", "the 2030s" and so on? It's so weirdly inconsistent! :P
It seems fairly likely to me that we end up with "the teens" and "the twenties," a 100 year gap is enough that there won't be a conflict in daily conversation and every alternative takes a whole lot more work. Whatever we land on for the first decade of this century is up in the air, since that's always been awkward even just to talk about the first decade of the last century. I'm pulling for just "the aughts" with no -ies, but I doubt it'll pan out that way.
"the aughts" does have a nice, old timey ring to it. I like it. Although hopefully 2020-2029 doesn't end up as "the twaughts" if we use it! :P ;)
Nah, that'll be the new 'roaring twenties' and don't think for one second marketing won't make mountains of hay out of that one.
I was just reading this set of comments thinking 'it's aughts!' - aughties makes me cringe for some reason.
Generally, when dealing with slang, the term with the smallest number of syllables always wins, because people are lazy. ;)
JavaScript has a weird history. Netscape wanted to compete with Microsoft and collaborated with Sun to bring Java into its browser. That didn't work out but the "Java" part stuck despite it being completely different. Java was huge for web development back then (arguably still is), so its syntax was chosen over Python or similar. They eventually had a single guy write a JavaScript prototype over the course of 10 days. It took longer to actually get a release but the whole thing was still a rushed mess. Because Netscape was huge in the 90s and it was quickly standardized, it somehow stuck.
I must say, for some quick and dirty in-browser functionality (as it was initially intended to be used!) JavaScript is very okay! Way better than having to run some external plugin. It's just ridiculous what kind of complex code is now written in JavaScript. Go to the google.com homepage and "view source". It's anxiety-inducing!
I use JS at work for manipulation of data streams, I believe this is mainly because the IDE we use for our ETL work only has a JS plugin available, but it seems to work fairly well.
I'm a newbie programmer though so what do I know :)
OK, so I finally took the time to look over each page of this. At first I thought everything sounded just about right. Of course everyone's using React now, GraphQL is the new hotness, and most people who have touched Angular don't want to ever do that again.
And then I looked at how 85% of everyone said they liked building JS apps and I realized the respondents must clearly be insane. /s
In all seriousness, I am much happier with the state of the JS ecosystem now compared to just one or two years ago when the whole JS world was exploding. After all, it's really hard to take advantage of an explosion. I'll admit, though, that most of the reason for me hating it so much was having to
manglemanage learning Angular.The one thing I'm really surprised about is just how popular Typescript is. ECMA really needs to add a typing system of some sort into the next version of JavaScript.
The way I see Typescript is that it allows you to add a layer on top which forced you yo write somewhat better code, similar to how PHP 7 introducted static typing. Most of the interesting features like classes and imports exist in ES6+ but having a transpiler yell at you for giving a
stringwhere anintis expected is still somewhat useful imo.