6 ms·

TL;DR: JS with a ton of make up and tooling to not write JS is not as horrible as it used to be. Well. That doesn't make it awesome either. You just traded so

TL;DR: JS with a ton of make up and tooling to not write JS is not as horrible as it used to be. Well. That doesn't make it awesome either. You just traded some problems for others. Like the damn source map never working correctly, the build time being longer and longer, and the never ending list of plugins you expend every day after stumbling on yet another small-minuscule-not-that-important-I-swear detail. The tool chain you spend more and more time on, despite all the "5-minutes" bundles provided by facebook or on githubs. Explaining things to new comers has never been as difficult as it is now. Teaching is a pain. Choosing your stack is a dangerous bet, and the odds and steaks are changing all the time. If you opt-in for a flux architecture, you will soon write Java-as-in-the-90 on the frontend instead of Javascript, with so many adapters and design patterns as layers you will become angry. If you don't (you-totally-don't-need-redux-to-use-react-guys) then most documentations and tutorials will not answer your questions, and you are own your own solving every single problems. Even the simplest ones, like redirecting on a route after data changes and closing a panel at the same time. "Libs, not framework" means you need to relearn everything, rewrite a lot of code, tests and doc and renew maintenance for each new project. Meanwhile nobody agree on what a the proper stack is. JS, despite all the paint on the rust, still has the old gotchas. This is still weird. ";" is still auto inserted. "==" still compares like nothing else. Errors come in different so many different forms it's not funny. Basic maths assumptions like commutativity are out of scope. Still no namespaces, but instead we use monstrosity like webpack and incompatible import systems to encapsulate things. Stdlib still doesn't have essential things like hashing, string/date formatting or encoding. Even basic operation like removing an element from an array using an index is a pain. No, I'm sorry, JS has not become awesome. We just arrived to a point were we accepted we have everything to built with it and agree to pay the huge price for it. That's all. Projects like vue.js makes me think there is still hope we end up with elegant tools from people who care. But right now I just embrace the madness and make money with it: all those poor customers don't realize the trap the current mindset lead them to, and I have so many solutions to the problem they should never have had to sell them.

lhnz 9y ago
> If you opt-in for a flux architecture, you will > soon write Java-as-in-the-90 on the frontend > instead of Javascript, with so many adapters > and design patterns as layers you will become angry. That's not necessary. It depends where you're working. I agree that teaching the complete stack is a pain. I guess there is `create-react-app` to help you there, but its scope is very small: you're not going to get static typing for example.
- dullgiulio 9y ago
  My biggest problem is "the complete stack." Which one? How many months will it be the blessed way of doing things? As soon as I get some work outsourced, here it comes yet another build system and yet another complete stack I have to get expert at. Javascript lacks a standard library (a mistake from the beginning) as well as standard tools (can't blame Netscape for this, but today we could totally come up with something more definitive.
  - tonyedgecombe 9y ago
    If JavaScript had a standard library from the beginning we would be replacing it now because it wouldn't support Unicode or promises or async or whatever is coming next.
    - sametmax 9y ago
      The stdlib can evolve with the W3C the same way the language evolves.
      - tonyedgecombe 9y ago
        You mean we're stuck with the legacy stuff forever.
      - hajile 9y ago
        The w3c cannot break the web. Once something is in the language a certain way, it stays (technically, there have been a couple small breaking changes, but the fact that you don't hear about them speaks to their size and impact)
cerved 9y ago
FYI, you don't need to use `this`, omit `;` or use `==`. Also JavaScript is commutative as long as FP64 is. Out of curiosity, what's the pain with removing an index using `splice(index, 1)`?
- sametmax 9y ago
  > FYI, you don't need to use `this` You do if you use react. > omit `;` or use `==`. Mistakes are made all the time. > Also JavaScript is commutative as long as FP64 is. Nope. $ node > [] + {} '[object Object]' > {} + [] 0 > Out of curiosity, what's the pain with removing an index using `splice(index, 1)`? Finding it. Remembering it. Getting it right. Reading it back. Remove the 3rd and get it in Python: res = a.pop(4) In JS: var res = a[4]; a.splice(4, 1); // usually a comment to remind you that you pop It's verbose, ugly, unintuitive. It's like this : https://xkcd.com/1168/ https://xkcd.com/1168/ But for JS.
  - Guillaume86 9y ago
    fyi splice returns the slice you remove, and ES6 allows array deconstruction so you could just use `var [res] = a.splice(4, 1);`.
  - gvx 9y ago
    > $ node > [] + {} '[object Object]' > {} + [] 0 Note that that has nothing to do with math. It has to do with braces being used for both blocks and object literals. Of course, I'm not too happy about the automatic coercion of everything and anything to either strings or numbers, but if you want consistency, try parentheses, or a + [], where a = {}.
  - cerved 9y ago
    Haven't used React but I'm sceptical. In what case do you need to use `this`? The only time I believe I've used this was maybe using a class? Which is shit so why would I want to do that anyway? Okay, so there are footguns. Don't use them, use a linter, problem solved. That doesn't look like math. What are you saying exactly? What's your problem with let res = a.splice(4, 1) ? I don't understand really, the method name and extra parameter?
z3t4 9y ago
This is still weird. Use variables. Not this. ";" is still auto inserted. If you insert the semicolons yourself and don't depend on the auto insertions, you don't have to worry about the edge cases where the lack of a semicolon would introduce a bug. "==" still compares like nothing else. Use === if you want to be explicit. Errors come in different so many different forms it's not funny. I agree, but this is only a problem with new API's like service workers, what where they (TC39) thinking when introducing unspecified errors !? That can't even be detected !! There's already a convention to use err.code to specify type of error, use that please! Basic maths assumptions like commutativity are out of scope. The commutativity is the same like in classic Maths I think, it's just he floating point errors that mess things up. Still no namespaces, but instead we use monstrosity like webpack and incompatible import systems to encapsulate things. The module system (require) in Node.JS comes from user-land, and can be implemented in pure JavaScript, so you can use it in the browser too! Stdlib still doesn't have essential things like hashing, string/date formatting or encoding. We have .toString, parseInt, atob, btoa, etc. The rest can be implemented in user-land: var md5 = require("md5") Even basic operation like removing an element from an array using an index is a pain. I think it's fine. If you use a named list {} you can "delete foo[bar]"
- sametmax 9y ago
  > Use variables. Not this. You can't if you use react. Besides, JS is the only language I know where half of it is recommended to not be used. > If you insert the semicolons yourself and don't depend on the auto insertions, you don't have to worry about the edge cases where the lack of a semicolon would introduce a bug. But that's not the point. The point is my students will forget the semicolon in some code that is not properly checked, and it will work. Most of the time. Until it doesn't. > Use === if you want to be explicit. No shit sherlock ? But again, half of the language is forbidden. And you know somebody is going to write != instead of !== one day, tired. > The commutativity is the same like in classic Maths I think, it's just he floating point errors that mess things up. Nope. Nope. Nope. Nope. $ node > [] + {} '[object Object]' > {} + [] 0 > We have .toString, parseInt, atob, btoa, etc. Come on, you never used Java, Perl, Ruby, Python? Any language with decent string formatting ? That doesn't need a leftpad dependancy ? That can format date without importing 34ko of moment.js ? > The rest can be implemented in user-land: var md5 = require("md5") And then you get the current 3Mo pages we all hate. Are you even serious with your arguments or is it trolling ? > I think it's fine. If you use a named list {} you can "delete foo[bar]" A mapping is not a list. It doesn't perform the same. You can't push and unshift. You can map on it without Object.stuff. Length is a costly operation. Concat without spread is a pain. And how do you get the "next 3 elements after the 2nd" ?
deleted 9y ago
[deleted]
lopatin 9y ago
Agreed, I stopped recommending React to beginners. I still love it and think it's the future, but in the sense that it's the new low-level. Eventually I think it will be standard to compile futuristic, high level, built-for-apps languages into React code. But for now, makes sense to just use a batteries-included framework. I don't know what the most sure shot is there though. Ember? Vue?
- aaron-lebo 9y ago
  Mithril. Much simpler than anything else and batteries included. It's a great way to get beginners into front-end frameworks and gain knowledge that transfers easily.
  - brlewis 9y ago
    Indeed. I use it to introduce beginners to modern front-end frameworks here: https://medium.com/front-end-hacking/how-it-feels-to-learn-javascript-in-2017-a934b801fbe https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
  - lopatin 9y ago
    Mithril is nice. W.r.t. going for batteries included, it's still a bit minimal for my taste. Personally I would lean towards something more dogmatic, in the spirit of Rails. For example, things that I would miss from Ember: ember-data, models (with relations), controllers, opinions, integrated tooling, etc ... But Mithril looks cool I've been meaning to play with it too. You're right that skills gained from learning Mithril will be more widely applicable to general front-end dev than Ember.
    - alttab 9y ago
      How about rails?
      - lopatin 9y ago
        Rails is great, but where it really shines is server side apps, content sites, blogs, CMSs, etc .. If you know you're building purely a SPA, Rails isn't really the right tool for that.
cookiecaper 9y ago
>No, I'm sorry, JS has not become awesome. We just arrived to a point were we accepted we have everything to built with it and agree to pay the huge price for it. That's all. Yep, this is the crux. ES6+ has finally made JavaScript look more or less like the languages we were using in the mid-90s, so I appreciate that, but it's not like it's some glorious boon to the developer community. Any gains from the new semi-tolerable semantics are quickly overwhelmed by requiring layer-upon-layer-upon-layer of crap, including hundreds of dangerous random modules from GitHub to compensate for the virtually non-existent standard library and a "build pipeline" that consists of several unrelated runners, bundlers, transpilers and transformers to make code that's actually usable in real environments. JavaScript is a tragedy for the development community from start to finish, and its increasing prominence should disabuse us of the notion that development is dictated by meritocracy or any such fantastical nonsense like that. Marketing and groupthink have just as much pull here as anywhere else (if not more because so many of us egotistically believe we are immune to it).
- cutler 9y ago
  Add to this the WTF ES6 added to the lanuage like different "this" scoping for arrow functions. Great. Now I have 2 headaches instead of 1.
  - devdad 9y ago
    I'd say you have one. If you had one before, you didn't know what really happened when you went `var that = this;` and aired your opinion about how `this` is being stupid. So you got the arrow function, where `this` acts the way you expected before, when you said it was stupid. You can't complain about both. The scoping of `this` has never really been too hard to understand. I learned it my first week doing JS.
- hajile 9y ago
  Everyone complains about the build tools, but they simply haven't thought through the issues. Let's say you were writing the web using Python. New browsers run v3.x, but old ones run 2.x or even 1.x. Further, features in newer versions of v3.x won't work on older versions of v3.x. New browsers could include all three runtimes, but old ones would be SOL. How do you use v3 features and target v2 or v1? You must transpile knowing that newer browsers also have v2 and v1 engines included too. You have hundreds of Python files in your system. Delivering hundreds of files is simply not practical on HTTP/2. You combine them and now you have webpack. What about libraries? As big as the standard lib is for Python, it doesn't do everything. You use pip or conda and now have npm/yarn. What about code consistency? The solution is pylint. What about testing? Add that to your chain as well. It's the unique issues of the web -- NOT Javascript -- that makes the build pipeline what it is. Until a few short years ago, these things weren't even possible. Today, if you know node/npm, webpack, babel, and eslint, you know the overwhelming majority of build processes. I'd finally add that make, Jenkins, etc are far more complicated to learn than the JS systems.
calafrax 9y ago
plain old javascript is perfectly fine. es6 is better. if you can't write good apps with js it is because you aren't a good programmer and you wouldn't be able to write good apps in any language.
w4tson 9y ago
Brilliant. Absolutely brilliant. Bravo

lhnz 9y ago

> If you opt-in for a flux architecture, you will > soon write Java-as-in-the-90 on the frontend > instead of Javascript, with so many adapters > and design patterns as layers you will become angry. That's not necessary. It depends where you're working. I agree that teaching the complete stack is a pain. I guess there is `create-react-app` to help you there, but its scope is very small: you're not going to get static typing for example.

dullgiulio 9y ago
My biggest problem is "the complete stack." Which one? How many months will it be the blessed way of doing things? As soon as I get some work outsourced, here it comes yet another build system and yet another complete stack I have to get expert at. Javascript lacks a standard library (a mistake from the beginning) as well as standard tools (can't blame Netscape for this, but today we could totally come up with something more definitive.
- tonyedgecombe 9y ago
  If JavaScript had a standard library from the beginning we would be replacing it now because it wouldn't support Unicode or promises or async or whatever is coming next.
  - sametmax 9y ago
    The stdlib can evolve with the W3C the same way the language evolves.
    - tonyedgecombe 9y ago
      You mean we're stuck with the legacy stuff forever.
    - hajile 9y ago
      The w3c cannot break the web. Once something is in the language a certain way, it stays (technically, there have been a couple small breaking changes, but the fact that you don't hear about them speaks to their size and impact)

cerved 9y ago

FYI, you don't need to use `this`, omit `;` or use `==`. Also JavaScript is commutative as long as FP64 is. Out of curiosity, what's the pain with removing an index using `splice(index, 1)`?

sametmax 9y ago
> FYI, you don't need to use `this` You do if you use react. > omit `;` or use `==`. Mistakes are made all the time. > Also JavaScript is commutative as long as FP64 is. Nope. $ node > [] + {} '[object Object]' > {} + [] 0 > Out of curiosity, what's the pain with removing an index using `splice(index, 1)`? Finding it. Remembering it. Getting it right. Reading it back. Remove the 3rd and get it in Python: res = a.pop(4) In JS: var res = a[4]; a.splice(4, 1); // usually a comment to remind you that you pop It's verbose, ugly, unintuitive. It's like this : https://xkcd.com/1168/ https://xkcd.com/1168/ But for JS.
- Guillaume86 9y ago
  fyi splice returns the slice you remove, and ES6 allows array deconstruction so you could just use `var [res] = a.splice(4, 1);`.
- gvx 9y ago
  > $ node > [] + {} '[object Object]' > {} + [] 0 Note that that has nothing to do with math. It has to do with braces being used for both blocks and object literals. Of course, I'm not too happy about the automatic coercion of everything and anything to either strings or numbers, but if you want consistency, try parentheses, or a + [], where a = {}.
- cerved 9y ago
  Haven't used React but I'm sceptical. In what case do you need to use `this`? The only time I believe I've used this was maybe using a class? Which is shit so why would I want to do that anyway? Okay, so there are footguns. Don't use them, use a linter, problem solved. That doesn't look like math. What are you saying exactly? What's your problem with let res = a.splice(4, 1) ? I don't understand really, the method name and extra parameter?

z3t4 9y ago

This is still weird. Use variables. Not this. ";" is still auto inserted. If you insert the semicolons yourself and don't depend on the auto insertions, you don't have to worry about the edge cases where the lack of a semicolon would introduce a bug. "==" still compares like nothing else. Use === if you want to be explicit. Errors come in different so many different forms it's not funny. I agree, but this is only a problem with new API's like service workers, what where they (TC39) thinking when introducing unspecified errors !? That can't even be detected !! There's already a convention to use err.code to specify type of error, use that please! Basic maths assumptions like commutativity are out of scope. The commutativity is the same like in classic Maths I think, it's just he floating point errors that mess things up. Still no namespaces, but instead we use monstrosity like webpack and incompatible import systems to encapsulate things. The module system (require) in Node.JS comes from user-land, and can be implemented in pure JavaScript, so you can use it in the browser too! Stdlib still doesn't have essential things like hashing, string/date formatting or encoding. We have .toString, parseInt, atob, btoa, etc. The rest can be implemented in user-land: var md5 = require("md5") Even basic operation like removing an element from an array using an index is a pain. I think it's fine. If you use a named list {} you can "delete foo[bar]"

sametmax 9y ago
> Use variables. Not this. You can't if you use react. Besides, JS is the only language I know where half of it is recommended to not be used. > If you insert the semicolons yourself and don't depend on the auto insertions, you don't have to worry about the edge cases where the lack of a semicolon would introduce a bug. But that's not the point. The point is my students will forget the semicolon in some code that is not properly checked, and it will work. Most of the time. Until it doesn't. > Use === if you want to be explicit. No shit sherlock ? But again, half of the language is forbidden. And you know somebody is going to write != instead of !== one day, tired. > The commutativity is the same like in classic Maths I think, it's just he floating point errors that mess things up. Nope. Nope. Nope. Nope. $ node > [] + {} '[object Object]' > {} + [] 0 > We have .toString, parseInt, atob, btoa, etc. Come on, you never used Java, Perl, Ruby, Python? Any language with decent string formatting ? That doesn't need a leftpad dependancy ? That can format date without importing 34ko of moment.js ? > The rest can be implemented in user-land: var md5 = require("md5") And then you get the current 3Mo pages we all hate. Are you even serious with your arguments or is it trolling ? > I think it's fine. If you use a named list {} you can "delete foo[bar]" A mapping is not a list. It doesn't perform the same. You can't push and unshift. You can map on it without Object.stuff. Length is a costly operation. Concat without spread is a pain. And how do you get the "next 3 elements after the 2nd" ?

deleted 9y ago

[deleted]

lopatin 9y ago

Agreed, I stopped recommending React to beginners. I still love it and think it's the future, but in the sense that it's the new low-level. Eventually I think it will be standard to compile futuristic, high level, built-for-apps languages into React code. But for now, makes sense to just use a batteries-included framework. I don't know what the most sure shot is there though. Ember? Vue?

aaron-lebo 9y ago
Mithril. Much simpler than anything else and batteries included. It's a great way to get beginners into front-end frameworks and gain knowledge that transfers easily.
- brlewis 9y ago
  Indeed. I use it to introduce beginners to modern front-end frameworks here: https://medium.com/front-end-hacking/how-it-feels-to-learn-javascript-in-2017-a934b801fbe https://medium.com/front-end-hacking/how-it-feels-to-learn-j...
- lopatin 9y ago
  Mithril is nice. W.r.t. going for batteries included, it's still a bit minimal for my taste. Personally I would lean towards something more dogmatic, in the spirit of Rails. For example, things that I would miss from Ember: ember-data, models (with relations), controllers, opinions, integrated tooling, etc ... But Mithril looks cool I've been meaning to play with it too. You're right that skills gained from learning Mithril will be more widely applicable to general front-end dev than Ember.
  - alttab 9y ago
    How about rails?
    - lopatin 9y ago
      Rails is great, but where it really shines is server side apps, content sites, blogs, CMSs, etc .. If you know you're building purely a SPA, Rails isn't really the right tool for that.

cookiecaper 9y ago

>No, I'm sorry, JS has not become awesome. We just arrived to a point were we accepted we have everything to built with it and agree to pay the huge price for it. That's all. Yep, this is the crux. ES6+ has finally made JavaScript look more or less like the languages we were using in the mid-90s, so I appreciate that, but it's not like it's some glorious boon to the developer community. Any gains from the new semi-tolerable semantics are quickly overwhelmed by requiring layer-upon-layer-upon-layer of crap, including hundreds of dangerous random modules from GitHub to compensate for the virtually non-existent standard library and a "build pipeline" that consists of several unrelated runners, bundlers, transpilers and transformers to make code that's actually usable in real environments. JavaScript is a tragedy for the development community from start to finish, and its increasing prominence should disabuse us of the notion that development is dictated by meritocracy or any such fantastical nonsense like that. Marketing and groupthink have just as much pull here as anywhere else (if not more because so many of us egotistically believe we are immune to it).

cutler 9y ago
Add to this the WTF ES6 added to the lanuage like different "this" scoping for arrow functions. Great. Now I have 2 headaches instead of 1.
- devdad 9y ago
  I'd say you have one. If you had one before, you didn't know what really happened when you went `var that = this;` and aired your opinion about how `this` is being stupid. So you got the arrow function, where `this` acts the way you expected before, when you said it was stupid. You can't complain about both. The scoping of `this` has never really been too hard to understand. I learned it my first week doing JS.
hajile 9y ago
Everyone complains about the build tools, but they simply haven't thought through the issues. Let's say you were writing the web using Python. New browsers run v3.x, but old ones run 2.x or even 1.x. Further, features in newer versions of v3.x won't work on older versions of v3.x. New browsers could include all three runtimes, but old ones would be SOL. How do you use v3 features and target v2 or v1? You must transpile knowing that newer browsers also have v2 and v1 engines included too. You have hundreds of Python files in your system. Delivering hundreds of files is simply not practical on HTTP/2. You combine them and now you have webpack. What about libraries? As big as the standard lib is for Python, it doesn't do everything. You use pip or conda and now have npm/yarn. What about code consistency? The solution is pylint. What about testing? Add that to your chain as well. It's the unique issues of the web -- NOT Javascript -- that makes the build pipeline what it is. Until a few short years ago, these things weren't even possible. Today, if you know node/npm, webpack, babel, and eslint, you know the overwhelming majority of build processes. I'd finally add that make, Jenkins, etc are far more complicated to learn than the JS systems.

calafrax 9y ago

plain old javascript is perfectly fine. es6 is better. if you can't write good apps with js it is because you aren't a good programmer and you wouldn't be able to write good apps in any language.

w4tson 9y ago

Brilliant. Absolutely brilliant. Bravo