This is how it feels to learn Javascript in 2016
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
It's just a post-processor which does the exact same thing - the resulting code will be the same. It's just saving me from typing the same stuff over and over again.
You're making a horrible legacy nightmare for which future maintainers will hate you. It's bad enough keeping track with all these fluid babel features and react syntax. Don't add another layer of crud on top of it.
-
@cartman82 said in This is how it feels to learn Javascript in 2016:
@Rhywden said in This is how it feels to learn Javascript in 2016:
It's just a post-processor which does the exact same thing - the resulting code will be the same. It's just saving me from typing the same stuff over and over again.
You're making a horrible legacy nightmare for which future maintainers will hate you. It's bad enough keeping track with all these fluid babel feature and react syntax. Don't add another layer of crud on top of it.
I'm the only one who will maintain the code. So, please spare me your griping about how real men code by shuffling bits on the platter around. I'm using this for a proof of concept and I quite like not having type the same three functions over and over again.
And React syntax is bad? Do yourself a favour and never look at XAML. Because you'll see quite a lot of similarities.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
I'm the only one who will maintain the code.
Wat? Is this your first project? Have you never seen what happens with "simple" on-off projects if they take off?
Wait.
NIH syndrome. Over-engineered solution divorced from industry reality. Condescending holier-than-though attitude.
Are you in academia?
-
@cartman82 I'm honestly not getting where a really simple shorthand for a two-way binding of an attribute to a variable, which is quite clearly visible in code is harder to maintain than multiple line code doing the exact same.
Especially when this shorthand is used in a similar way in C#/XAML.
Are you off your meds again?
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
@cartman82 I'm honestly not getting where a really simple shorthand for a two-way binding of an attribute to a variable, which is quite clearly visible in code is harder to maintain than multiple line code doing the exact same.
Especially when this shorthand is used in a similar way in C#/XAML.I don't know. I guess we'll see in 5-6 years, when a future maintainer posts an angry rant with some actual code samples.
-
@cartman82 said in This is how it feels to learn Javascript in 2016:
@Rhywden said in This is how it feels to learn Javascript in 2016:
@cartman82 I'm honestly not getting where a really simple shorthand for a two-way binding of an attribute to a variable, which is quite clearly visible in code is harder to maintain than multiple line code doing the exact same.
Especially when this shorthand is used in a similar way in C#/XAML.I don't know. I guess we'll see in 5-6 years,
whenif a future maintainer posts an angry rant with some actual code samples.It's documented, it's easy to understand and keeps the code rather more clean than your "pure" version. I guess you have reached the "Git off mah lawn" stage now.
This is the same logic which would condemn
foreach
for being an unneccessary shorthand forfor(i=1;i<iterable.length;i++)
-
@ben_lubar said in This is how it feels to learn Javascript in 2016:
And in any case, toArray can be written as just
[].slice.call
, which works in any browser that supports JavaScript.Now you're just demonstrating why the rest of us just go, and write the simple thing in jQuery. I have shit that needs to get done. I don't have time to worry about which browser supports what and how to work around all that.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
This is the same logic which would condemn foreach for being an unneccessary shorthand for for(i=1;i<iterable.length;i++)
As someone who coded my own version of
forEach
and used it everywhere in a project, damn right.You'll learn.
-
@ben_lubar said in This is how it feels to learn Javascript in 2016:
And in any case, toArray can be written as just [].slice.call, which works in any browser that supports JavaScript.
Akhm.
Array.prototype.slice.call
, please.
-
@cartman82 said in This is how it feels to learn Javascript in 2016:
@Rhywden said in This is how it feels to learn Javascript in 2016:
This is the same logic which would condemn foreach for being an unneccessary shorthand for for(i=1;i<iterable.length;i++)
As someone who coded my own version of
forEach
and used it everywhere in a project, damn right.You'll learn.
By that kind of backwards logic, we'd still be developing on punch cards. I can (somewhat) understand the griping if it was about inventing a completely new mechanic.
This is appropriating a tried-and-true mechanic from another language.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
This is appropriating a tried-and-true mechanic from another language.
That's exactly what I did when I first moved from C# to javascript. I tried to reinvent all the crap I was used to working with in C#- Dictionaries, fancy data structures, exactly the forEach semantics I liked...
A few years from now you'll hopefully hate your code. Or your successor will hate you.
-
@cartman82 said in This is how it feels to learn Javascript in 2016:
@Rhywden said in This is how it feels to learn Javascript in 2016:
This is appropriating a tried-and-true mechanic from another language.
That's exactly what I did when I first moved from C# to javascript. I tried to reinvent all the crap I was used to working with in C#- Dictionaries, fancy data structures, exactly the forEach semantics I liked...
A few years from now you'll hopefully hate your code. Or your successor will hate you.
All I'm currently hearing is the wah-wah-wah of someone who codes like crap so that he cannot make sense of what he wrote in a few years unless he sticks to the basics.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
All I'm currently hearing is the wah-wah-wah of someone who codes like crap so that he cannot make sense of what he wrote in a few years unless he sticks to the basics.
"I AM AN ARTISTE, CARTMAN! HISTORY WILL CHERISH MY BRILLIANCE! MY CODE WILL LIVE FOREVER!"
You must be the most minmaxed INT over WIS type of person I've ever seen. I don't know how old you are, but for your sake, I hope you're under 25.
-
@cartman82 @Rhywden Get a room, you two!
-
@asdf Preferably in the Trolleybus Garage…
-
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
@Weng said in This is how it feels to learn Javascript in 2016:
Yeah. I have decided I don't do web anymore. Closest I'll go is C# WebAPI. Fact is I can build an entire ecosystem of cross platform native apps with less fucking complexity than Hello World in modern JS.
I have people for the in browser shit.
Aye. Just two days ago I argued with a developer whose plugin for Babel is supposed to make one-way and two-way bindings easy in React - just do a
b="propertyName: variableName"
and you're done. This is indeed a timesaver if you have to bind to multiple properties because you can simply gob="propertyName1: variableName1, propertyName2: variableName2, ..."
instead of having to do aonChange={(event, value) => setVariable(value)
for every single one of them.The problem: He developed it so that it only works with the standard DOM elements like
<input />
and such. However, he praised it as making React contain less boilerplate. React components usually don't expose standard attributes, though.He then argued that "you cannot know which component exposes which attributes". And he also told me that C# and XAML also have this problem.
I'm pretty sure that I've created several custom components in C#/XAML (and also used several 3rd party, paid and free component libraries) where I never had problems binding to an exposed attribute.
Geeze.
You prabably did, since it's entirely possible. That's where inheritance shows off.
You see, .NET is bad because Microsoft and huge corporation and they do what they want in a consistent matter, while decentralization and doing what you want in an inconsistent manner is the right way. How else do you cool and hipster?
-
@kt_ said in This is how it feels to learn Javascript in 2016:
You see, .NET is bad because Microsoft and huge corporation and they do what they want in a consistent matter, while decentralization and doing what you want in an inconsistent manner is the right way. How else do you cool and hipster?
What's more, every
libraryframework can do it differently! This enables diversity and makes building a combined application ever so much fun!
-
@cartman82 said in This is how it feels to learn Javascript in 2016:
@Rhywden said in This is how it feels to learn Javascript in 2016:
All I'm currently hearing is the wah-wah-wah of someone who codes like crap so that he cannot make sense of what he wrote in a few years unless he sticks to the basics.
"I AM AN ARTISTE, CARTMAN! HISTORY WILL CHERISH MY BRILLIANCE! MY CODE WILL LIVE FOREVER!"
You must be the most minmaxed INT over WIS type of person I've ever seen. I don't know how old you are, but for your sake, I hope you're under 25.
Your attitude reminds me of my grandmother who's 95 by now.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
Your attitude reminds me of my grandmother who's 95 by now.
-
@ben_lubar said in This is how it feels to learn Javascript in 2016:
until JavaScript gets more sensible types
Ever the optimist, eh?
-
@pydsigner said in This is how it feels to learn Javascript in 2016:
@anonymous234 said in This is how it feels to learn Javascript in 2016:
And frankly, I'd be embracing the "just use a <canvas> and draw everything there" view if it weren't for the problem of accessibility.
Yeah! Who needs performance anyways!
Isn’t that the basic problem? Computers of the last n years are powerful enough that it doesn’t really matter for performance to put stuff on a web page in roundabout ways like using Javascript when straightforward HTML would do just as well. So why should the designer care about doing things the proper way? Or so they think, anyway.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
All I'm currently hearing is the wah-wah-wah of someone who codes like crap so that he cannot make sense of what he wrote in a few years unless he sticks to the basics.
As the saying goes, you can code Fortran in any language. If you fight the conventions of the language in which you work, other people are going to hate your code, at least.
-
@cartman82 said in This is how it feels to learn Javascript in 2016:
@Rhywden said in This is how it feels to learn Javascript in 2016:
It's just a post-processor which does the exact same thing - the resulting code will be the same. It's just saving me from typing the same stuff over and over again.
You're making a horrible legacy nightmare for which future
maintainers will hate youTDWTF articles will be submitted.FTFY
-
@HardwareGeek said in This is how it feels to learn Javascript in 2016:
Ever the optimist, eh?
Enforced types? Sounds like he's a fan of Bondage and Discipline in his programming…
-
@dkf said in This is how it feels to learn Javascript in 2016:
@HardwareGeek said in This is how it feels to learn Javascript in 2016:
Ever the optimist, eh?
Enforced types? Sounds like he's a fan of Bondage and Discipline in his programming…
Extended use of JavaScript does tend to suggest leanings towards sadomasochism...
-
@Arantor said in This is how it feels to learn Javascript in 2016:
@dkf said in This is how it feels to learn Javascript in 2016:
@HardwareGeek said in This is how it feels to learn Javascript in 2016:
Ever the optimist, eh?
Enforced types? Sounds like he's a fan of Bondage and Discipline in his programming…
Extended use of JavaScript does tend to suggest leanings towards sadomasochism...
...said the PHP guy.
-
@Maciejasjmj does JavaScript have native tools for type safety in their language now? Because PHP does. Unlike JavaScript, the PHP devs recognise their language is shitty and are actively taking steps to fix the shitty.
-
This is how it feels, as a user, to use anything that heavily depends on Javascript
-
“JavaScript Fatigue Fatigue” @ossia https://medium.freecodecamp.com/javascript-fatigue-fatigue-66ffb619f6ce
Counter-article.
-
@cartman82 Meh, just waving your hand and going 'it's complicated, suck it up' without actually justifying why the complexity should actually be there doesn't really counter the original article.
-
@Gurth said in This is how it feels to learn Javascript in 2016:
@pydsigner said in This is how it feels to learn Javascript in 2016:
@anonymous234 said in This is how it feels to learn Javascript in 2016:
And frankly, I'd be embracing the "just use a <canvas> and draw everything there" view if it weren't for the problem of accessibility.
Yeah! Who needs performance anyways!
Isn’t that the basic problem? Computers of the last n years are powerful enough that it doesn’t really matter for performance to put stuff on a web page in roundabout ways like using Javascript when straightforward HTML would do just as well. So why should the designer care about doing things the proper way? Or so they think, anyway.
Everybody's got an i7 by now, Shirley.
-
@kt_ said in This is how it feels to learn Javascript in 2016:
Everybody's got
an i7a 10Mb always-active not-shitty-mobile connection by now, Shirley.
-
@kt_ said in This is how it feels to learn Javascript in 2016:
@Gurth said in This is how it feels to learn Javascript in 2016:
@pydsigner said in This is how it feels to learn Javascript in 2016:
@anonymous234 said in This is how it feels to learn Javascript in 2016:
And frankly, I'd be embracing the "just use a <canvas> and draw everything there" view if it weren't for the problem of accessibility.
Yeah! Who needs performance anyways!
Isn’t that the basic problem? Computers of the last n years are powerful enough that it doesn’t really matter for performance to put stuff on a web page in roundabout ways like using Javascript when straightforward HTML would do just as well. So why should the designer care about doing things the proper way? Or so they think, anyway.
Everybody's got an i7 by now, Shirley.
Huh. Whodathunkit...
@bb36e said in This is how it feels to learn Javascript in 2016:
@kt_ said in This is how it feels to learn Javascript in 2016:
Everybody's got
an i7a 10Mb always-active not-shitty-mobile connection by now, Shirley.Google considers "Good 3g" to be 1.5Mb, and that's the maximum that most carriers will throttle you down to after you've reached your limit.
-
@Tsaukpaetra said in This is how it feels to learn Javascript in 2016:
that's the maximum that most carriers will throttle you down to after you've reached your limit.
Mine throttles down to 25 kbps. My connection speed ranges from 10mbps to 10/0kbps....woohoo shitty network. At least it's cheap.
-
@bb36e said in This is how it feels to learn Javascript in 2016:
10/0kbps
Not quite sure what to make of that speed. Just can't figure out how to define it.
-
@Dreikin said in This is how it feels to learn Javascript in 2016:
Not quite sure what to make of that speed. Just can't figure out how to define it.
I intended to write 'non-existent' instead of 0, but I guess undefined covers that case :p
-
@coderpatsy said in This is how it feels to learn Javascript in 2016:
Wouldn't be so bad if NodeLists/wtf you call the DOM's arraylikes actually implemented .forEach and friends...
With the spread operator it's pretty easy.
[...document.querySelectorAll('p')].forEach(...)
And if you need to support shitty, ancient browsers like IE11, then
slice
is the easiest way to hack it.
-
@anotherusername said in This is how it feels to learn Javascript in 2016:
@coderpatsy said in This is how it feels to learn Javascript in 2016:
Wouldn't be so bad if NodeLists/wtf you call the DOM's arraylikes actually implemented .forEach and friends...
With the spread operator it's pretty easy.
[...document.querySelectorAll('p')].forEach(...)
And if you need to support shitty, ancient browsers like IE11, then
slice
is the easiest way to hack it."I don't know what y'all are complaining about. All you have to do is hack around the awfulness of your first hack with another awful hack hack that won't even work in
n-1
browsers. JavaScript is the best thing since skin cancer!"
-
@anotherusername that's still bullshit
imagine if someone told you that MUMPS added a preprocessor macro that saved you from typing 10 characters per line and this made it not that bad
you'd call them crazy and stop talking to them
-
@bb36e ugh. Look, if you want someone to blame, blame the W3C and their DOM specs; for
NodeList
objects, they only identify the propertylength
and the methoditem
. If you want it to have array-like methods, you have to properly cast it into an array.
-
@anotherusername said in This is how it feels to learn Javascript in 2016:
@coderpatsy said in This is how it feels to learn Javascript in 2016:
Wouldn't be so bad if NodeLists/wtf you call the DOM's arraylikes actually implemented .forEach and friends...
With the spread operator it's pretty easy.
[...document.querySelectorAll('p')].forEach(...)
And if you need to support shitty, ancient browsers like IE11, then
slice
is the easiest way to hack it.Or use the for...in loop, which looks much clearer (and works almost wherever the spread operator works)
-
@anotherusername said in This is how it feels to learn Javascript in 2016:
Look, if you want someone to blame, blame the W3C and their DOM specs; for NodeList objects, they only identify the property length and the method item. If you want it to have array-like methods, you have to properly cast it into an array.
I blame lots of developers for looking at that spec and not implementing it with an array (except in a few languages like C). Yes, it doesn't say it, but it's what anyone sane would do, given that the DOM is really a language-independent specification. Lots of my fellow developers are not sane, and have the common sense of a woodlouse. The fact that an array isn't called a
NodeList
at the type level isn't a big deal; you weren't going to copy that C# code byte-for-byte over into C++ anyway.
-
@dkf said in This is how it feels to learn Javascript in 2016:
@anotherusername said in This is how it feels to learn Javascript in 2016:
Look, if you want someone to blame, blame the W3C and their DOM specs; for NodeList objects, they only identify the property length and the method item. If you want it to have array-like methods, you have to properly cast it into an array.
I blame lots of developers for looking at that spec and not implementing it with an array (except in a few languages like C). Yes, it doesn't say it, but it's what anyone sane would do, given that the DOM is really a language-independent specification. Lots of my fellow developers are not sane, and have the common sense of a woodlouse. The fact that an array isn't called a
NodeList
at the type level isn't a big deal; you weren't going to copy that C# code byte-for-byte over into C++ anyway.Giving an object more features than the spec specifies completely goes against ensuring portability, which is kind of the point of a spec. The moment you use forEach on a NodeList, you have no guarantee the code will work on any current or future implementation
-
@cark said in This is how it feels to learn Javascript in 2016:
Giving an object more features than the spec specifies completely goes against ensuring portability
There's no reason that a language can't take the DOM core and profile it to work like I said. The only issue you'd have then is that you wouldn't have portability between programming languages, and nobody really cares that much about that. Really. The code has to be rewritten anyway when being ported to that extent.
-
@kt_ said in This is how it feels to learn Javascript in 2016:
Everybody's got an i7 by now, Shirley.
That’s a very American way of solving problems: more horsepower.
-
@boomzilla said in This is how it feels to learn Javascript in 2016:
@Rhywden said in This is how it feels to learn Javascript in 2016:
All I'm currently hearing is the wah-wah-wah of someone who codes like crap so that he cannot make sense of what he wrote in a few years unless he sticks to the basics.
As the saying goes, you can code Fortran in any language. If you fight the conventions of the language in which you work, other people are going to hate your code, at least.
Yes, and that I'm "fighting" those conventions, for that we only have your word.
Listen, @cartman82 has been burned by his shitty coding and now he somehow automatically assumes just because he wrote shit, everyone else not doing what he perceives as best practice must code shit as well.
Again: This particular add-on is easily documented, easily understood and even makes understanding the purpose of the code easier.
If he wants to whine about something like that then I really can't understand that.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
This particular add-on is easily documented, easily understood and even makes understanding the purpose of the code easier for me.
FTFY
If you're layering multiple paradigms and libraries/frameworks together at once, it can bite you in unexpected ways and as any fule kno, there's nothing more permanent than temporary: just because only you will maintain this now doesn't mean it still won't be in use after you leave whereupon someone else will have to maintain it. And will likely as not curse you for it.
-
@dkf said in This is how it feels to learn Javascript in 2016:
@cark said in This is how it feels to learn Javascript in 2016:
Giving an object more features than the spec specifies completely goes against ensuring portability
There's no reason that a language can't take the DOM core and profile it to work like I said. The only issue you'd have then is that you wouldn't have portability between programming languages, and nobody really cares that much about that. Really. The code has to be rewritten anyway when being ported to that extent.
The DOM spec by itself is too vague to work with for DOM implementations (e.g. How do you implement
iterable
?). Every DOM implementation today (that I know of) uses Javascript, and the specs for that are WebIDL and ECMAScript. It's a bit pointless to talk about DOM implementions in any other language until the equivalent of WebIDL is produced for that languageAnd for Javascript, WebIDL already specifies a way to loop over
NodeList
andHTMLCollection
like an Array: the for...inof loop. No point in making them actual Arrays. Plus, the 'live'-ness requirement of these collections make Array operations on them a bit unintuitive. In the current spec, applying this code// Edit: Fixed var divs = document.getElementsByTagName('div'); for (let d of divs) { d.remove(); }
to this html
<div id='1'></div> <div id='2'></div> <div id='3'></div> <div id='4'></div>
is actually well defined and must delete items 1 and 3 according to spec. Nobody wants to go through the whole suite of Array operations and attributes and figure out how 'live'-ness interacts with each of them.
-
@cark said in This is how it feels to learn Javascript in 2016:
Plus, the 'live'-ness requirement of these collections make Array operations on them a bit unintuitive.
Yes, but that's why the 'live'-ness requirement is stupid.