27 ms·

But JS dev has never been fun. Web dev is fun because the browser is a freaking awesome plateform. However, it is _despite_ of JS. There's not a single chara

But JS dev has never been fun. Web dev is fun because the browser is a freaking awesome plateform. However, it is _despite_ of JS. There's not a single characteristic of this language that makes it better than any other mainstream high level language out there. We use it because we have no reasonable alternative on the browser. It has always been a pain to use, requiring: - avoiding part of the language that is badly designed to escape traps. - recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc. - fight with the various implementations to find some code that will work for most of your customers. - use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS. The fact that the community is now shooting itself in the foot by providing so many incompatible, badly documented and breaking-compat-all-the-time tools is just icing on the rotten cake. P.S: since this comment is getting upvotes, I will say that having used in prod vanilla, jquery, react, angular and Vue, I will stick with Vue for the next years. I'm done. My quest is over. It takes 3 hours of reading to be productive with it. It requires no tooling and yet can be used with existing tooling. It's fast. It's well documented. I can now focus on writing software again.

ballenf 9y ago
> - avoiding part of the language that is badly designed to escape traps. This is universally true for any mainstream language where age > 10 years. > - fight with the various implementations to find some code that will work for most of your customers. That's an understandable tradeoff from the ability to write code that can run on thousands of different devices. It's very much preferable than writing native code for each platform and all the various implementations that would require. Basically agree with your other points.
amiraliakbari 9y ago
JS, and the web platform in general, is solving problems that are hard in nature. Considering the constraints imposed by these problems, quite a few features of JS are superior to many other languages. Consider the wide range of devices that a JS code must support. There is some pain in supporting all of them, but compared with Android development, the transpilers and shims available in JS seems like magic. Cross platform programming is hard, and JS seems wierd because any JS code must consider it, while many C programmers never need to think about it. Taking cross-platform into account, I prefer copying some shims from MDN to using IFDEF WIN32's. Or consider GUI development. The nice API for working with DOM, lots of available UI components, and specially the asynchronous programming model made possible by Promises is really nice by GUI-programming standards. Also the good parts/bad parts mindset belongs to the past. I can't remember the last time I even thought of using == vs ===, prototype hacks or similar "bad" parts. The usual post about strange behavior of ">=null" on HN is just amuzing, not problematic for my JS coding experience. As said in other comments, maybe everybody should just stick to using their prefered JS framework and master it.
- heisenbit 9y ago
  > while many C programmers never need to think about it usually do not have to think about it anymore.
turtlebits 9y ago
Async is super simple in JS. Yes callback hell can be an issue, and it may be ugly, but there's many a time where I wished for it in Python and ended writing a script in NodeJS.
- tdbgamer 9y ago
  Python has asynchronous coroutines (the async/await thing) so you don't really need to do callbacks as far as I know. I personally find that syntax much easier to follow than callbacks.
davedx 9y ago
> - recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc. It's not so bad now. The language is evolving and gaining these kind of features (modules, standard methods to manipulate data structures). Lodash is just like #include <stdlib>. > - fight with the various implementations to find some code that will work for most of your customers. Again this has gotten better over the years. We write vanilla ES5 code with Angular 1.4 and it pretty much just works in every browser. With transpilers it's even better. > - use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS. TypeScript and the various babel transforms generally give you a superset of JavaScript, not a different language. JSX lets you write more JavaScript, not less, compared to frameworks that have templating systems. I'm a bit surprised at these comments if you're writing JavaScript today, for me it's much more accurate of the state of affairs 5-10 years ago.
jonny_eh 9y ago
First-class functions are the star feature of JS. It's what makes it a great language for making UIs (like on the web) and single-threaded web servers (like with Node). If you don't like the language, that's fine. There's no shortage of languages out there.
- iainmerrick 9y ago
  That is a pretty ordinary feature for scripting languages.
wwweston 9y ago
I don't have a lot of arguments against tooling/framework issues in the JS world now. The proliferation and churn and quality limits are part of what make things very much not-fun for me. Good thing I can ditch to the server side and other places when I need a break. :) I think things like Vue, though, mark a point where developers are stepping back after the recent madness and asking themselves exactly what problem their tools and frameworks are really trying to solve and starting to do better. But when it comes to the language itself... speak for yourself. Up until about 5 years ago, I thought JS development was a blast, and I was enjoying it enough that I was using Rhino as my alternate language for the JVM and having fun there too. And I've built things in a dozen languages, so this isn't didn't-know-much-else-ism. The fun didn't start, though, until I stopped expecting it to be something else. "avoiding part of the language that is badly designed to escape traps" == understand the language well enough that what you expect to happen is what actually happens (and accept that just because you're familiar with one behavior in other languages doesn't obligate any other language to replicate it -- those expectations do not necessarily constitute the principle of least surprise). "recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc." == understand the features that exist in JS well enough that you know how they can do the job you expected features from other languages to be required in order to do And that's been true of any fun language I've found. There are some languages that never became fun for me because either I don't want to do things the way that the designers do (and in some cases because I expect the designers don't want anybody to have fun, they just want it to be a tool), but all the ones that did become fun required me to actually learn them first. And if somebody actually likes dynamic scripting languages at all, I'm baffled if JS-the-language isn't something they can't achieve contented productivity in. In fact, I'd go so far as to say I'm skeptical that a developer who can't achieve that in JS can genuinely achieve it in Python or Ruby. "remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS." For one thing: coffeescript has never been anything other than JS semantics, saying that using babel is an attempt to avoid using JS is like arguing that using Python 3 is an attempt to avoid using Python, and JSX is entirely orthogonal to this topic as it's essentially a templating tool that happens to be a language extension (like E4X) instead of a string processing library. For another thing... I do remember that 10 years ago that among the contenders for JS libraries there were a number whose central conceit was that the problem with web development was that JS wasn't enough like development in some other language. Prototype's ethos, for example, seemed to be that it wasn't enough like Ruby. jQuery was like "nope, the chief pain point is our browser APIs, what if we had some that were more amenable to concise practical use, took advantage of JS's functional strengths, and were normalized across browsers?" I think it's pretty obvious in retrospect who had the key insight. And I think that most of the progress from this point will come from people who have the same insight: understand JS's strengths, play to them, don't treat the browser or the language as if they need to be some other platform, think about what the general project pain points really are.
reaperducer 9y ago
Dare we dream of a world where Javascript goes the way of Flash.

ballenf 9y ago

> - avoiding part of the language that is badly designed to escape traps. This is universally true for any mainstream language where age > 10 years. > - fight with the various implementations to find some code that will work for most of your customers. That's an understandable tradeoff from the ability to write code that can run on thousands of different devices. It's very much preferable than writing native code for each platform and all the various implementations that would require. Basically agree with your other points.

amiraliakbari 9y ago

JS, and the web platform in general, is solving problems that are hard in nature. Considering the constraints imposed by these problems, quite a few features of JS are superior to many other languages. Consider the wide range of devices that a JS code must support. There is some pain in supporting all of them, but compared with Android development, the transpilers and shims available in JS seems like magic. Cross platform programming is hard, and JS seems wierd because any JS code must consider it, while many C programmers never need to think about it. Taking cross-platform into account, I prefer copying some shims from MDN to using IFDEF WIN32's. Or consider GUI development. The nice API for working with DOM, lots of available UI components, and specially the asynchronous programming model made possible by Promises is really nice by GUI-programming standards. Also the good parts/bad parts mindset belongs to the past. I can't remember the last time I even thought of using == vs ===, prototype hacks or similar "bad" parts. The usual post about strange behavior of ">=null" on HN is just amuzing, not problematic for my JS coding experience. As said in other comments, maybe everybody should just stick to using their prefered JS framework and master it.

heisenbit 9y ago
> while many C programmers never need to think about it usually do not have to think about it anymore.

turtlebits 9y ago

Async is super simple in JS. Yes callback hell can be an issue, and it may be ugly, but there's many a time where I wished for it in Python and ended writing a script in NodeJS.

tdbgamer 9y ago
Python has asynchronous coroutines (the async/await thing) so you don't really need to do callbacks as far as I know. I personally find that syntax much easier to follow than callbacks.

davedx 9y ago

> - recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc. It's not so bad now. The language is evolving and gaining these kind of features (modules, standard methods to manipulate data structures). Lodash is just like #include <stdlib>. > - fight with the various implementations to find some code that will work for most of your customers. Again this has gotten better over the years. We write vanilla ES5 code with Angular 1.4 and it pretty much just works in every browser. With transpilers it's even better. > - use tooling to compensate any weakness you can. Remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS. TypeScript and the various babel transforms generally give you a superset of JavaScript, not a different language. JSX lets you write more JavaScript, not less, compared to frameworks that have templating systems. I'm a bit surprised at these comments if you're writing JavaScript today, for me it's much more accurate of the state of affairs 5-10 years ago.

jonny_eh 9y ago

First-class functions are the star feature of JS. It's what makes it a great language for making UIs (like on the web) and single-threaded web servers (like with Node). If you don't like the language, that's fine. There's no shortage of languages out there.

iainmerrick 9y ago
That is a pretty ordinary feature for scripting languages.

wwweston 9y ago

I don't have a lot of arguments against tooling/framework issues in the JS world now. The proliferation and churn and quality limits are part of what make things very much not-fun for me. Good thing I can ditch to the server side and other places when I need a break. :) I think things like Vue, though, mark a point where developers are stepping back after the recent madness and asking themselves exactly what problem their tools and frameworks are really trying to solve and starting to do better. But when it comes to the language itself... speak for yourself. Up until about 5 years ago, I thought JS development was a blast, and I was enjoying it enough that I was using Rhino as my alternate language for the JVM and having fun there too. And I've built things in a dozen languages, so this isn't didn't-know-much-else-ism. The fun didn't start, though, until I stopped expecting it to be something else. "avoiding part of the language that is badly designed to escape traps" == understand the language well enough that what you expect to happen is what actually happens (and accept that just because you're familiar with one behavior in other languages doesn't obligate any other language to replicate it -- those expectations do not necessarily constitute the principle of least surprise). "recreating basic features that you take for granted in any other tech like isolation, namespacing, primitive stlib features, etc." == understand the features that exist in JS well enough that you know how they can do the job you expected features from other languages to be required in order to do And that's been true of any fun language I've found. There are some languages that never became fun for me because either I don't want to do things the way that the designers do (and in some cases because I expect the designers don't want anybody to have fun, they just want it to be a tool), but all the ones that did become fun required me to actually learn them first. And if somebody actually likes dynamic scripting languages at all, I'm baffled if JS-the-language isn't something they can't achieve contented productivity in. In fact, I'd go so far as to say I'm skeptical that a developer who can't achieve that in JS can genuinely achieve it in Python or Ruby. "remember the most popular projects in JS (coffee, tsx, jsx, babel, webpack, etc) are mostly projects allowing you... to avoid writing JS." For one thing: coffeescript has never been anything other than JS semantics, saying that using babel is an attempt to avoid using JS is like arguing that using Python 3 is an attempt to avoid using Python, and JSX is entirely orthogonal to this topic as it's essentially a templating tool that happens to be a language extension (like E4X) instead of a string processing library. For another thing... I do remember that 10 years ago that among the contenders for JS libraries there were a number whose central conceit was that the problem with web development was that JS wasn't enough like development in some other language. Prototype's ethos, for example, seemed to be that it wasn't enough like Ruby. jQuery was like "nope, the chief pain point is our browser APIs, what if we had some that were more amenable to concise practical use, took advantage of JS's functional strengths, and were normalized across browsers?" I think it's pretty obvious in retrospect who had the key insight. And I think that most of the progress from this point will come from people who have the same insight: understand JS's strengths, play to them, don't treat the browser or the language as if they need to be some other platform, think about what the general project pain points really are.

reaperducer 9y ago

Dare we dream of a world where Javascript goes the way of Flash.