18 ms·

The melting pot of JavaScript (2017)

153 points by lewisflude 8y ago

w4tson 8y ago
Is it unfair to say that some of these problems are caused by a lack of awareness (or an unwillingness) to learn from other communities (like, Ruby, Java etc) that have solved these some of these problems already?
- oaiey 8y ago
  No. And that is also why JS is successful. Newbies with little oversight create new tools. Of thousands of them, one or two become popular because of non-functional reasons (right blog post, right fit, easy use, ..). Welcome to the mess :)
  - jskaggz 8y ago
    Tech pop-culture... Navigating these technology growth explosions is like searching for solid reference architecture in a booming shantytown. Some parts of these settlements eventually get things like running water, working sewage, urban planning.
    - oaiey 8y ago
      Do not disagree to that. My comment is not a compliment to JS just a brutal analysis.
vinceguidry 8y ago
I welcome the slow transformation of Javascript into Ruby. Every single thing in there is already a thing in the Ruby ecosystem. Convention over configuration. The careful, but automatic dependency management. Principle of least surprise. All things I didn't know how much I relied on until I moved to NodeJS and found them non-existent.
- humbleMouse 8y ago
  What you said could be true of Java or any other modern server languagae.
zach43 8y ago
I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials. It is good to see that the community is open to introspecting and improving even further
- simion314 8y ago
  >also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) it also used tons of dependencies, in the end I created my app from scratch using only the TS compiler package and the react client library, no extra tools, magic, 1 month old tutorials that are outdated already, no install latest tool of the month etc.
  - gedy 8y ago
    npx create-react-app my-ts-app --typescript takes about 30 seconds from command to running app. Maybe the issue people have is there is no 'js-lang.org' with one tutorial site and getting started. It's a huge community, so of course random blog posts will be a mixed bag of quality.
    - simion314 8y ago
      There are more issues 1 the right tutorial, instruction may not be on top on my search engine, a few months old instructions are too old 2 the create app thing uses tons of "magic", it encourage people not to understand how things work, all is fine until something breaks... here is an issue we hit at work We have a project that uses gulp(the project is old, I did not started it so don't blame me if gulp is not the state of the art today). One dev added an uglify step to gulp and now the gulp watch t process entered in an infinite loop, I as the one with the most experience I worked on figuring it out, since the uglify step causes the issue I investigate this(I discover that some gulp modules the project uses are obsoleted because a cooler/better one was created but I did not started on upgrading the tools), I read on uglify, it's dependencies, I read on watch it's dependencies, read how it is implemented under the hood and in the end I realize that uhe uglify hstep had the side effect of making the process longer (I suspected that some temp files would be created or other things) but this extra seconds triggered an existing issue in our configuration file, the watch task was watching the output min files but it never triggered before because of a timeout it has(or something similar). In the end I ended up looking under the hood of this magic tools because a dev setup a .json config file wrong but the issue did not manifest until years later. Conclusion is that magic tools work fine until they do not , then you have to look under the hood or try the reboot,update,change the tool and maybe it is fixed For tomorrow I need to investigate why npm install package fails to install a package dependencies on a CentOS server, I read that there were some bugs and probably the fixes were not backported and I will have to mess around and understand what is the problem and fix it somehow.
_hardwaregeek 8y ago
Very nice points here. I've always been struck at how the JavaScript community never really adopted the Rails ideas of convention over configuration and optimizing for developer happiness. While it's easy to roll one's eyes at the marketing lingo, these principles do truly make Rails a charm to use. Right now, even setting up the most simple Webpack-Babel-Node config requires writing a whole lot of config and set up for very little gain.
- lewisjoe 8y ago
  Rails (or Python or Java) doesn't really fit into the problem set that JS has to go through. Most softwares written in those tech stay in the server with no need of transpiling, no need of code splitting when built, no need to be sent over the wire, etc. While I agree the package management in JS could have been better, most other too-much-config problem is just because of the variety of problems and the variety of potential solutions.
  - _hardwaregeek 8y ago
    I'm not so sure about that. While there are a lot of complicated situations for JS dev, there's also a lot of similar patterns. I'm not saying we need to ignore the various complexities involved in JS dev, but we should make the general patterns easier to solve. Yes, of course transpilation can have all these different edge cases. But we should be able to have some preset modes that can do 90% of the work automatically. Like it baffles the mind that I still need to tell webpack that JSX files should be loaded by babel. And anyways, there's the entire backend JS ecosystem, which is extremely behind Rails in developer ergonomics. I can spin up a REST API in Rails in half the time it takes to connect Node to a database.
- undersheet 8y ago
  In JS there is a lot of convention but on a micro level. The times of monolithic Rails apps which have strict conventions are over and it's good: Too much magic and strict conventions often forced devs into patterns which didn't match the use case. Even experienced Rails devs tried to solve every problem the same way. You also confusing matters. You need Webpack, Babel etc for the frontend not the backend. And even in the frontend it got abstracted away by things like creat-react-app. So you shouldn't them see them too often.
lewisjoe 8y ago
I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c28f7020a3a523 https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those improvements. Resonates a lot with Dan's write-up. Excellent piece by Dan. A much needed one. I'd probably link this along in my proposal. Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods.
- savanaly 8y ago
  >Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods. Jeez, man, I'm all for minimal tooling too. But ES6 is the lowest hanging fruit there is, I beg you to consider adding a transpile step to your build on your next project so you can use it!
  - lewisjoe 8y ago
    The problem though was Webpack was generating massive bundles (probably something to do with the polyfills needed for different browsers). We were able to achieve much smaller bundles by just sticking to ES5 features supported by the browsers we support. Oh, and code splitting was out of the question. Most modules were attaching themselves to the global namespace (note: a large portion of the app was built even before requireJS was a thing). Which means code-splitting is a developer discipline category, not an automated one. We have slowly started improving these things though. As I've mentioned in the document, the benefits are beginning to far outweigh the cost now, so yeah we'll move to ES6 soon.
- tuesdayrain 8y ago
  Es5 only? Jeez that would be an immediate dealbreaker for me with any potential employers.
DLA 8y ago
Dan Abramov wrote a brilliant post here, IMO. So much here. Unix Philosophy, yes please. Considering the cognitive load of tool options and configuration knobs, and the impact of the JS ecosystem for beginners. "A tool should work with (almost) no configuration." Amen. "Mind your output" from tools (errors must be helpful and sort the important from the unimportant); I've felt this pain and have abandoned tools at the start because of incomprehensible errors. Love the idea of toolboxes w/r/t dependencies. Read the post for the details. Great work Dan!
- deleted 8y ago
  [deleted]
- undersheet 8y ago
  > cognitive load of tool options First time I hear options are bad. Many options and competition lead to best products. There are enough posts and people who tell you what you should use. Or just use npmtrends or npmcharts. 1 second later you know what is going on and what module you should pick. Why are people criticizing something they have never used?
  - fwip 8y ago
    Just to be clear - you don't think the author has ever used a tool with too many configuration options?
  - DLA 8y ago
    My point here on this one is simply that it's investing to think about this factor. For beginners (which I am not), too many options can be confusing. That said, setting reasonable defaults for detail options so things work well without needing to configure then to start is a nice way around this. Deep options exist and can be adjusted as needed but a solid default configuration is set out of the box. "There are enough posts and people who tell you what you should use." -- sure but what if opinions very widely? There's the cognitive load or put another way friction-to-first-use.
    - undersheet 8y ago
spricket 8y ago
I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of the cruft and process that makes Java and C# especially so "uninteresting". Java especially is kind of a joy to work in if you ignore the cruft. Everything is generally well documented, the libraries are mostly very solid, code is almost always backwards compatible, there isn't a zillion ways to do everything, frameworks tend to live for a decade or so. And it's faster than JS, and uses way less memory, and mostly solved dependency hell and bloat over a decade ago. Java feels like it was designed, not grown. Everything follows similar convention so it's easy to pick up new libraries. The advantages are many. The drawbacks are few as long as you use things like Lombok and code generation liberally. By the way; code generation using agents, annotation processors, and bytecode manipulation is pretty much standard and a godsend for doing interesting things (and getting around the cruft) . In java, I can write code on the fly at runtime, or even during compile time using standard tools. Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated
- pwaivers 8y ago
  Since JavaScript is a prototype language, doesn't reflection come in automatically?
  - MarsAscendant 8y ago
    Not for most coders, unfortunately.
  - spricket 8y ago
    Bad/non-existent annotation support prevents you attaching metadata to objects without adding garbage to their structures. Makes reflection a lot less useful
- undersheet 8y ago
me551ah 8y ago
You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, these will become obsolete too.
- MarsAscendant 8y ago
  Interesting. I stopped touching frameworks on my second year in. It's the same problem I have with trying to develop within the constraints of someone else's work: I find it confusing and anxiety-inducing. I'd rather write my own stuff, unless I'm woefully unequipped to to begin with. (Cryptography, authentification, credit card handling...) I feel like I'd learned quite a bit of JavaScript, specifically – especially with the help of someone like Angus Croll [https://javascriptweblog.wordpress.com/ https://javascriptweblog.wordpress.com/]. I'm not that clever a JS developer – or a programmer, for that matter – so his `compose()` and `curry()` sound magical to me.
ausjke 8y ago
I never got the idea of nodejs or javascript for backend, tried it a few times and eventually returned to python and java. It's much easier for python/java to add event-loop and/or restful framework than making javascript looks like python/java one day as far as backend goes. In 2019 I still have 0 interest in javascript/TS for backend, the thousands of modules under node_modules alone is enough for me, and not all real world product need async/promise/callback/SPA, javascript is over-heated too much, not fun at all.
- undersheet 8y ago
  JS is not your daddy's JS anymore.
- hombre_fatal 8y ago
  You don't get to just add an event loop and start writing async code in Python or Java. It opens up its own can of worms now that you're straddling the sync and async worlds. Compare working with Netty (async) to Jetty (sync). It's certainly not trivial. That Javascript is async-everything is one of its best and often overlooked features in these comparisons. I think this snippet encapsulates a lot of why Javascript is actually very pleasant on the server: const results = await Promise.map(urls, (url) => process(url), { concurrency: 8 }) .then((results) => postprocess(results))
  - beatgammit 8y ago
    I don't think it is overlooked. JavaScript doesn't scale, both in terms of code complexity (callback hell) and across cores, and the "gold standard" these days is microservices, which has a ton of issues. If you want to look at bolt-on async working, check out C# or Rust. They've basically taken JavaScript's new async/await and added threading (at least Rust has, not sure about C#). You can write an async app and have it run in a thread pool without much fuss. I don't know what the story is for Java, but seeing as C# is effectively the same thing, it's not hard to imagine adding async being easier than adding threads or performance to JavaScript.
    - 8y ago
c-smile 8y ago
JavaScript was designed to be a glue language - to connect output of one native function with input of other native function. And do all of this in UI event handlers. And it was almost perfect (modulo hoisting, semicolon omission) for that. The trouble has started when Web, as a platform, has failed to provide safe alternative to JS aimed for extendable way of delivering and running high-performant code on the client. Ideally we should have something like <script type="binary/bytecode"> with something close to JavaVM and HTML DOM exposed to it. At least 15 years ago. So we would have a lot of compilers, static compilation and code analysis. Instead we have tons of weirdest possible solutions: Web "threads" with code that need to be downloaded and compiled before running, that ugly WebAsm, transpilers-of-something-into-JS. C++ code "transpiled" into JS, in whose nightmare that bright idea was born? Yet we have crowds of talented people wasting time of writing about how to really HACK the platform that was not meant to be used this way. Create bunch of problems to ourselves just to overcome them heroically. Far from being productive.
- pitaj 8y ago
  > something close to JavaVM and HTML DOM exposed to it > ugly WebAsm WASM isn't fully functional as a standalone alternative to JS in the browser, yet, but you can essentially use it that way with things like wasm-bindgen in the Rust ecosystem. And it performs essentially what you're describing, being a VM running bytecode in a sandbox.
  - c-smile 8y ago
    > but you can essentially use it that way "Essentially" is a nice word. You can use it for example as JavaScript is a programming language, essentially, yeah. W3C DOM was defined initially in terms of Java interfaces. Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning? <script type="binary/web-bytecode" src="myapp.class"> Today we might discuss -strip-dead-code option in your favorite compiler of XYZ language. Instead of fighting with would-be-linker npm.
    - int_19h 8y ago
throwaway427 8y ago
Let's say you'd like to write front-end code in a language that hides as much of the problems with JS as possible, preferably one that comes with a standard library, has elegant (or at least ergonomic) JS to <lang> interop and bridging, simplifies async code, and has a simple, integrated toolchain for targeting JS (all these amongst other things), what would you suggest? Basically what's the best language to write Javascript in : ) Dart? Elm? Clojurescript? Objective-J?
- scns 8y ago
  ReasonML
  - throwaway427 8y ago
    Oh I forgot about Reason. Does it have a standard library that obviates the need for pulling in things like lodash, etc?
mc13 8y ago
save
raxxorrax 8y ago
Unpopular opinion time: I understand why people prefer TypeScript/CoffeeScript but for me personally it just destroys the incentive of a scripting language and I am a fan of keeping deployment as simple as possible and to me transpiling is equivalent to compiling. Packaging is bad as it is. True, maybe everything is different in large scale applications but I hate it if I find something interesting implemented in TypeScript and in 95% of cases I will just move on. Javascript is not a beauty and any superset just seems like a facelift. The result looks like old and used car tires. disclaimer: I am no web dev but somehow come in contact with JS frequently.

153 points by lewisflude 8y ago

Is it unfair to say that some of these problems are caused by a lack of awareness (or an unwillingness) to learn from other communities (like, Ruby, Java etc) that have solved these some of these problems already?

oaiey 8y ago
No. And that is also why JS is successful. Newbies with little oversight create new tools. Of thousands of them, one or two become popular because of non-functional reasons (right blog post, right fit, easy use, ..). Welcome to the mess :)
- jskaggz 8y ago
  Tech pop-culture... Navigating these technology growth explosions is like searching for solid reference architecture in a booming shantytown. Some parts of these settlements eventually get things like running water, working sewage, urban planning.
  - oaiey 8y ago
    Do not disagree to that. My comment is not a compliment to JS just a brutal analysis.

vinceguidry 8y ago

I welcome the slow transformation of Javascript into Ruby. Every single thing in there is already a thing in the Ruby ecosystem. Convention over configuration. The careful, but automatic dependency management. Principle of least surprise. All things I didn't know how much I relied on until I moved to NodeJS and found them non-existent.

humbleMouse 8y ago
What you said could be true of Java or any other modern server languagae.

zach43 8y ago

I personally think that the JavaScript community is doing a great job with its tooling and approach. Compared to other language environments I’ve worked with (C, C++, Python), most common JS tools work in predictable, user-friendly ways...also they frequently have good documentation and “getting started” tutorials. It is good to see that the community is open to introspecting and improving even further

simion314 8y ago
>also they frequently have good documentation and “getting started” tutorials. I tried making a TypeScript react app around Christmas, I found a tutorial, the commands did not work, I do not remember the details but it was using some bundler and probably the tutorial was a bit old and packages updated in npm. I found a different tutorial, to use create_react_app, I seen it uses npx(not sure when this tool appeared) it also used tons of dependencies, in the end I created my app from scratch using only the TS compiler package and the react client library, no extra tools, magic, 1 month old tutorials that are outdated already, no install latest tool of the month etc.
- gedy 8y ago
  npx create-react-app my-ts-app --typescript takes about 30 seconds from command to running app. Maybe the issue people have is there is no 'js-lang.org' with one tutorial site and getting started. It's a huge community, so of course random blog posts will be a mixed bag of quality.
  - simion314 8y ago
    There are more issues 1 the right tutorial, instruction may not be on top on my search engine, a few months old instructions are too old 2 the create app thing uses tons of "magic", it encourage people not to understand how things work, all is fine until something breaks... here is an issue we hit at work We have a project that uses gulp(the project is old, I did not started it so don't blame me if gulp is not the state of the art today). One dev added an uglify step to gulp and now the gulp watch t process entered in an infinite loop, I as the one with the most experience I worked on figuring it out, since the uglify step causes the issue I investigate this(I discover that some gulp modules the project uses are obsoleted because a cooler/better one was created but I did not started on upgrading the tools), I read on uglify, it's dependencies, I read on watch it's dependencies, read how it is implemented under the hood and in the end I realize that uhe uglify hstep had the side effect of making the process longer (I suspected that some temp files would be created or other things) but this extra seconds triggered an existing issue in our configuration file, the watch task was watching the output min files but it never triggered before because of a timeout it has(or something similar). In the end I ended up looking under the hood of this magic tools because a dev setup a .json config file wrong but the issue did not manifest until years later. Conclusion is that magic tools work fine until they do not , then you have to look under the hood or try the reboot,update,change the tool and maybe it is fixed For tomorrow I need to investigate why npm install package fails to install a package dependencies on a CentOS server, I read that there were some bugs and probably the fixes were not backported and I will have to mess around and understand what is the problem and fix it somehow.

_hardwaregeek 8y ago

Very nice points here. I've always been struck at how the JavaScript community never really adopted the Rails ideas of convention over configuration and optimizing for developer happiness. While it's easy to roll one's eyes at the marketing lingo, these principles do truly make Rails a charm to use. Right now, even setting up the most simple Webpack-Babel-Node config requires writing a whole lot of config and set up for very little gain.

lewisjoe 8y ago
Rails (or Python or Java) doesn't really fit into the problem set that JS has to go through. Most softwares written in those tech stay in the server with no need of transpiling, no need of code splitting when built, no need to be sent over the wire, etc. While I agree the package management in JS could have been better, most other too-much-config problem is just because of the variety of problems and the variety of potential solutions.
- _hardwaregeek 8y ago
  I'm not so sure about that. While there are a lot of complicated situations for JS dev, there's also a lot of similar patterns. I'm not saying we need to ignore the various complexities involved in JS dev, but we should make the general patterns easier to solve. Yes, of course transpilation can have all these different edge cases. But we should be able to have some preset modes that can do 90% of the work automatically. Like it baffles the mind that I still need to tell webpack that JSX files should be loaded by babel. And anyways, there's the entire backend JS ecosystem, which is extremely behind Rails in developer ergonomics. I can spin up a REST API in Rails in half the time it takes to connect Node to a database.
undersheet 8y ago
In JS there is a lot of convention but on a micro level. The times of monolithic Rails apps which have strict conventions are over and it's good: Too much magic and strict conventions often forced devs into patterns which didn't match the use case. Even experienced Rails devs tried to solve every problem the same way. You also confusing matters. You need Webpack, Babel etc for the frontend not the backend. And even in the frontend it got abstracted away by things like creat-react-app. So you shouldn't them see them too often.

lewisjoe 8y ago

I just wrote a proposal for my team today as to how the front-end tooling has changed recently and why we'd need to adopt them in our workflow. https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c28f7020a3a523 https://writer.zoho.com/writer/open/0y4wx08838bdbcf954b1398c... With confidential details masked, it's still a pretty good read for the rest of the Internet. Outlines why JS fatigue is not really bad but just improvements and what exactly is stopping us from adopting those improvements. Resonates a lot with Dan's write-up. Excellent piece by Dan. A much needed one. I'd probably link this along in my proposal. Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods.

savanaly 8y ago
>Note: We've built a pretty fat browser app with plain vanilla JS, strictly ES5 only, crude bash scripts for building a bundled js & all such ancient methods. Jeez, man, I'm all for minimal tooling too. But ES6 is the lowest hanging fruit there is, I beg you to consider adding a transpile step to your build on your next project so you can use it!
- lewisjoe 8y ago
  The problem though was Webpack was generating massive bundles (probably something to do with the polyfills needed for different browsers). We were able to achieve much smaller bundles by just sticking to ES5 features supported by the browsers we support. Oh, and code splitting was out of the question. Most modules were attaching themselves to the global namespace (note: a large portion of the app was built even before requireJS was a thing). Which means code-splitting is a developer discipline category, not an automated one. We have slowly started improving these things though. As I've mentioned in the document, the benefits are beginning to far outweigh the cost now, so yeah we'll move to ES6 soon.
tuesdayrain 8y ago
Es5 only? Jeez that would be an immediate dealbreaker for me with any potential employers.

DLA 8y ago

Dan Abramov wrote a brilliant post here, IMO. So much here. Unix Philosophy, yes please. Considering the cognitive load of tool options and configuration knobs, and the impact of the JS ecosystem for beginners. "A tool should work with (almost) no configuration." Amen. "Mind your output" from tools (errors must be helpful and sort the important from the unimportant); I've felt this pain and have abandoned tools at the start because of incomprehensible errors. Love the idea of toolboxes w/r/t dependencies. Read the post for the details. Great work Dan!

deleted 8y ago
[deleted]
undersheet 8y ago
> cognitive load of tool options First time I hear options are bad. Many options and competition lead to best products. There are enough posts and people who tell you what you should use. Or just use npmtrends or npmcharts. 1 second later you know what is going on and what module you should pick. Why are people criticizing something they have never used?
- fwip 8y ago
  Just to be clear - you don't think the author has ever used a tool with too many configuration options?
- DLA 8y ago
  My point here on this one is simply that it's investing to think about this factor. For beginners (which I am not), too many options can be confusing. That said, setting reasonable defaults for detail options so things work well without needing to configure then to start is a nice way around this. Deep options exist and can be adjusted as needed but a solid default configuration is set out of the box. "There are enough posts and people who tell you what you should use." -- sure but what if opinions very widely? There's the cognitive load or put another way friction-to-first-use.
  - undersheet 8y ago

spricket 8y ago

I really like the kind of sanity that TypeScript brings to JS, super well designed and usually a pleasure to work with. That said, I've worked in many languages and I can't see any reason you would willing write your backend in JS or TypeScript. Java, C#, Rails, and to some extent Python are much saner choices. The massive churn of the JS ecosystem bleeds through to the backend, hard. JS could use a little more of the cruft and process that makes Java and C# especially so "uninteresting". Java especially is kind of a joy to work in if you ignore the cruft. Everything is generally well documented, the libraries are mostly very solid, code is almost always backwards compatible, there isn't a zillion ways to do everything, frameworks tend to live for a decade or so. And it's faster than JS, and uses way less memory, and mostly solved dependency hell and bloat over a decade ago. Java feels like it was designed, not grown. Everything follows similar convention so it's easy to pick up new libraries. The advantages are many. The drawbacks are few as long as you use things like Lombok and code generation liberally. By the way; code generation using agents, annotation processors, and bytecode manipulation is pretty much standard and a godsend for doing interesting things (and getting around the cruft) . In java, I can write code on the fly at runtime, or even during compile time using standard tools. Js barely even supports reflection. This is a huge underrated shortcoming of js if you're doing anything complicated

pwaivers 8y ago
Since JavaScript is a prototype language, doesn't reflection come in automatically?
- MarsAscendant 8y ago
  Not for most coders, unfortunately.
- spricket 8y ago
  Bad/non-existent annotation support prevents you attaching metadata to objects without adding garbage to their structures. Makes reflection a lot less useful
undersheet 8y ago

me551ah 8y ago

You never really learn javascript, you learn frameworks. I was a js developer about 7-8 years ago and dabbled with jQuery , dojo and the likes and then moved over to backend and mobile development. I tried getting back into javascript again and realized that I just could not get in and start coding. There are a lot more frameworks now that I have to learn to get started and I'm sure that a few years down the line, these will become obsolete too.

MarsAscendant 8y ago
Interesting. I stopped touching frameworks on my second year in. It's the same problem I have with trying to develop within the constraints of someone else's work: I find it confusing and anxiety-inducing. I'd rather write my own stuff, unless I'm woefully unequipped to to begin with. (Cryptography, authentification, credit card handling...) I feel like I'd learned quite a bit of JavaScript, specifically – especially with the help of someone like Angus Croll [https://javascriptweblog.wordpress.com/ https://javascriptweblog.wordpress.com/]. I'm not that clever a JS developer – or a programmer, for that matter – so his `compose()` and `curry()` sound magical to me.

ausjke 8y ago

I never got the idea of nodejs or javascript for backend, tried it a few times and eventually returned to python and java. It's much easier for python/java to add event-loop and/or restful framework than making javascript looks like python/java one day as far as backend goes. In 2019 I still have 0 interest in javascript/TS for backend, the thousands of modules under node_modules alone is enough for me, and not all real world product need async/promise/callback/SPA, javascript is over-heated too much, not fun at all.

undersheet 8y ago
JS is not your daddy's JS anymore.
hombre_fatal 8y ago
You don't get to just add an event loop and start writing async code in Python or Java. It opens up its own can of worms now that you're straddling the sync and async worlds. Compare working with Netty (async) to Jetty (sync). It's certainly not trivial. That Javascript is async-everything is one of its best and often overlooked features in these comparisons. I think this snippet encapsulates a lot of why Javascript is actually very pleasant on the server: const results = await Promise.map(urls, (url) => process(url), { concurrency: 8 }) .then((results) => postprocess(results))
- beatgammit 8y ago
  I don't think it is overlooked. JavaScript doesn't scale, both in terms of code complexity (callback hell) and across cores, and the "gold standard" these days is microservices, which has a ton of issues. If you want to look at bolt-on async working, check out C# or Rust. They've basically taken JavaScript's new async/await and added threading (at least Rust has, not sure about C#). You can write an async app and have it run in a thread pool without much fuss. I don't know what the story is for Java, but seeing as C# is effectively the same thing, it's not hard to imagine adding async being easier than adding threads or performance to JavaScript.
  - 8y ago

c-smile 8y ago

JavaScript was designed to be a glue language - to connect output of one native function with input of other native function. And do all of this in UI event handlers. And it was almost perfect (modulo hoisting, semicolon omission) for that. The trouble has started when Web, as a platform, has failed to provide safe alternative to JS aimed for extendable way of delivering and running high-performant code on the client. Ideally we should have something like <script type="binary/bytecode"> with something close to JavaVM and HTML DOM exposed to it. At least 15 years ago. So we would have a lot of compilers, static compilation and code analysis. Instead we have tons of weirdest possible solutions: Web "threads" with code that need to be downloaded and compiled before running, that ugly WebAsm, transpilers-of-something-into-JS. C++ code "transpiled" into JS, in whose nightmare that bright idea was born? Yet we have crowds of talented people wasting time of writing about how to really HACK the platform that was not meant to be used this way. Create bunch of problems to ourselves just to overcome them heroically. Far from being productive.

pitaj 8y ago
> something close to JavaVM and HTML DOM exposed to it > ugly WebAsm WASM isn't fully functional as a standalone alternative to JS in the browser, yet, but you can essentially use it that way with things like wasm-bindgen in the Rust ecosystem. And it performs essentially what you're describing, being a VM running bytecode in a sandbox.
- c-smile 8y ago
  > but you can essentially use it that way "Essentially" is a nice word. You can use it for example as JavaScript is a programming language, essentially, yeah. W3C DOM was defined initially in terms of Java interfaces. Where we would be now if we were allowed to run Java bytecodes in browser directly from the very beginning? <script type="binary/web-bytecode" src="myapp.class"> Today we might discuss -strip-dead-code option in your favorite compiler of XYZ language. Instead of fighting with would-be-linker npm.
  - int_19h 8y ago

throwaway427 8y ago

Let's say you'd like to write front-end code in a language that hides as much of the problems with JS as possible, preferably one that comes with a standard library, has elegant (or at least ergonomic) JS to <lang> interop and bridging, simplifies async code, and has a simple, integrated toolchain for targeting JS (all these amongst other things), what would you suggest? Basically what's the best language to write Javascript in : ) Dart? Elm? Clojurescript? Objective-J?

scns 8y ago
ReasonML
- throwaway427 8y ago
  Oh I forgot about Reason. Does it have a standard library that obviates the need for pulling in things like lodash, etc?

mc13 8y ago

save

raxxorrax 8y ago

Unpopular opinion time: I understand why people prefer TypeScript/CoffeeScript but for me personally it just destroys the incentive of a scripting language and I am a fan of keeping deployment as simple as possible and to me transpiling is equivalent to compiling. Packaging is bad as it is. True, maybe everything is different in large scale applications but I hate it if I find something interesting implemented in TypeScript and in 95% of cases I will just move on. Javascript is not a beauty and any superset just seems like a facelift. The result looks like old and used car tires. disclaimer: I am no web dev but somehow come in contact with JS frequently.