This is how it feels to learn Javascript in 2016
-
It’s 2016 man, no one uses jQuery anymore, it ends up in a bunch of spaghetti code. Everyone knows that.
Right. So my alternative is to load three libraries to fetch data and display a HTML table.
We will just stick to jQuery, TYVM. Fuck all that new-fangled shit.
-
I think this has been doing the rounds before in the funny stuff thread...
-
Ah, okay. I searched for the URL before posting and got no hits.
-
@ChrisH said in This is how it feels to learn Javascript in 2016:
Ah, okay. I searched for the URL before posting and got no hits.
Search works about as well as pagination.
-
The JS ecosystem is a perfect example of Magpie-Driven Development. If it's new and shiny, it's automatically better and you should have started using it yesterday. Right.
I use JS at work every day. Typically that includes TypeScript to keep some sanity, React (no Redux) to have type safety in the views, Gulp for the build process, Webpack to bundle JS into one blob. I see no point in chasing every flavour-of-the-week, this combination works well enough.
-
@ChrisH said in This is how it feels to learn Javascript in 2016:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.p6107sx2n
So.
Page down/Space moves the line that's just off the bottom of the page to just above the top of the page. Yay.
Tapping not only scrolls the page down to show the line, but then brings the page banner down to cover it and the next couple of lines.
-
I'm going to quote myself
When it comes to creating software platforms, there are basically two approaches:
- Include every function a developer might possibly need
- Include a small, but fast, set of instructions providing just the bare minimum, so that someone can create a proper library on top of it.
Most platforms start with the first one, but as time progresses people realize the existing functions are not flexible enough to do what they want. So they end up reimplementing most of the platform on top of a small subset. It's inevitable.
HTML was this thing that was meant to be super "semantic". Like you were supposed to use <strong> instead of <b> because "bold" only technically applies to text and someone could be using screen readers, and CSS was meant to keep "style" and "content" strictly separate, and basically had this idea that a page could be transformed and displayed in 50 different ways and still remain the same page.
And this, as noble an idea as it was, never really went anywhere. Partly because designers want their website to look exactly a certain way, but mostly because web developers are not going to spend 3x the time making their websites a certain way for the sake of an abstract concept they probably don't really understand. They may care about basic accessibility guidelines if you insist enough, but that's about it. And then as HTML5 came, "web apps" became popular and browsers started evolving super fast, people just kinda gave up on the semanticness and started treating web pages more like black boxes not unlike Java or CLI bytecode.
And when you start doing that, it starts making a lot more sense to compile other languages to HTML5+javascript. After all, one language can't possibly be the best one to create everything, right? So people started making their own platforms, and hundreds of "javascript frameworks" broke out in a wave of unprecedented hipsterism.
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.
-
@anonymous234 said in This is how it feels to learn Javascript in 2016:
I'd be embracing the "just use a <canvas> and draw everything there" view if it weren't for the problem of accessibility.
-
@Arantor said in This is how it feels to learn Javascript in 2016:
Search works about as well as pagination.
Pagination works about as well as new-post streaming.
-
@anonymous234 to be brutally honest I'm getting fed up of the whole web thing, it's like all the problems that were solved twenty years ago are suddenly new problems again and I'm tempted to fuck off to regular desktop development because that seems less full of ...
-
@Arantor said in This is how it feels to learn Javascript in 2016:
it's like all the problems that were solved twenty years ago are suddenly new problems again
To be fair, this time around they're web scale!
-
@flabdablet you mean the same size they were before but you're so busy managing the stack you brought with you, you have less resources to deal with the actual problem?
-
@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!
-
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.
-
I made a deal with the rest of the team on the super sekret SockDrawer project: I would do the backend, run usability studies, do the design work, run our testing efforts, and take over the database duties if it meant I didn't have to do the frontend. Because web.
-
Wow. I've gotta send that to my brother. (He's a web developer.)
Reminds me of this:
-
@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.
-
@Rhywden I know I've quoted this article from James Iry before, but it's just a gift that keeps on giving.
1995 - Brendan Eich reads up on every mistake ever made in designing a programming language, invents a few more, and creates LiveScript. Later, in an effort to cash in on the popularity of Java the language is renamed JavaScript. Later still, in an effort to cash in on the popularity of skin diseases the language is renamed ECMAScript.
-
Instead of some complex transport protocol that no one will let traverse a firewall, we use HTTP.
I hate how true this is. Idiot network admins have effectively killed every protocol but HTTP. Now everything tunnels over HTTP. And once again we're back to the starting point but with an extra layer of shit.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
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.
How about, instead of hard-coded, you just let it happen.
And how about, if the attribute doesn't exist, you just SHRUG BECAUSE YOU DON'T KILL A WEBPAGE FOR SHIT LIKE THAT....huff puff
-
@anonymous234 said in This is how it feels to learn Javascript in 2016:
And once again we're back to the starting point but with an extra layer of shit
-
@masonwheeler The sorry thing is that SOAP really is simple by comparison to some of the alternatives.
Fuck.
-
@ChrisH said in This is how it feels to learn Javascript in 2016:
Fuck all that new-fangled shit.
That's exactly the problem with web dev right now. Lots of people writing yet another framework instead of looking up what already exi…
Ooooh! Look! A squirrel!
-
2016 State of ECZEMAScript:
"You know how virtually every standard browser has X feature?"
"Yeah, go on."
"Well, we need to 'improve' it and tack on our unique interpretation of it."
"Say no more fam." downloads jQuey, React, Angular, and whatever library Google uses
-
@dkf said in This is how it feels to learn Javascript in 2016:
@ChrisH said in This is how it feels to learn Javascript in 2016:
Fuck all that new-fangled shit.
That's exactly the problem with web dev right now. Lots of people writing yet another framework instead of looking up what already exi…
Ooooh! Look! A squirrel!Hey! It doesn't do that 0.0001% of things I need! So I'm justified creating an entirely new framework. That doesn't do 13.4234% of the things you need.
-
-
-
@ChrisH jQuery is the reason why it takes 10 second to load a webpage on a mobile phone after the dev decided to use the slowest fucking selectors. They worked fine on his 16 core hyperthreaded i7 machine with 32gb of ram and his phone is the latest Android phone that has 8 cores and 3 gb of ram.
-
@ChrisH I love James mickens! His talks never fail to make me laugh.
My favourite talk of his:
I also recommend at least looking at an article or two of his.
-
Why do we even need jQuery? Is typing
$('#foo.bar').css({backgroundColor: '#abc'})
so much easier than typingdocument.querySelector("#foo.bar").style.backgroundColor = '#abc'
that we need to include a quarter megabyte of JavaScript to make that possible?
-
@ben_lubar jQuery handles the business of looping for you so the code's the same whether a given selector returns 1 or 1000 elements.
Wouldn't be so bad if NodeLists/wtf you call the DOM's arraylikes actually implemented .forEach and friends...
-
@coderpatsy https://jsfiddle.net/ok42w1uz/
Works on my dhromebook.
-
@ben_lubar Not here. It's coming in Firefox 50 according to MDN.
-
@coderpatsy said in This is how it feels to learn Javascript in 2016:
@ben_lubar Not here. It's coming in Firefox 50 according to MDN.
Why would you run a buggy version of Chrome with less features? Why not just run Firefox 22 if you want to do that?
-
And in any case, toArray can be written as just
[].slice.call
, which works in any browser that supports JavaScript.
-
@ben_lubar said in This is how it feels to learn Javascript in 2016:
@coderpatsy https://jsfiddle.net/ok42w1uz/
Works on my dhromebook.
What is it?
-
HTTP/1.1: http://http2.golang.org/gophertiles?latency=1000
HTTP/2: https://http2.golang.org/gophertiles?latency=1000
-
@ben_lubar said in This is how it feels to learn Javascript in 2016:
HTTP/1.1: http://http2.golang.org/gophertiles?latency=1000
HTTP/2: https://http2.golang.org/gophertiles?latency=1000I don't understand what's being demonstrated here? The fact that there is a higher limit to the number of simultaneous requests allowed when using http/2?
-
@Tsaukpaetra said in This is how it feels to learn Javascript in 2016:
@ben_lubar said in This is how it feels to learn Javascript in 2016:
HTTP/1.1: http://http2.golang.org/gophertiles?latency=1000
HTTP/2: https://http2.golang.org/gophertiles?latency=1000I don't understand what's being demonstrated here? The fact that there is a higher limit to the number of simultaneous requests allowed when using http/2?
The picture made by that grid of images is what's important. Ignore the thing that page is actually demonstrating.
-
@ben_lubar said in This is how it feels to learn Javascript in 2016:
Why do we even need jQuery? Is typing
$('#foo.bar').css({backgroundColor: '#abc'})
so much easier than typingdocument.querySelector("#foo.bar").style.backgroundColor = '#abc'
that we need to include a quarter megabyte of JavaScript to make that possible?Putting aside the fact that you should be changing element classes instead of inline styles most of the time...
This list of jQuery's browser bug workarounds makes a counter-argument.
Also, jQuery does more than just DOM selectors and manipulation. If you want just selectors, you can use the standalone Sizzle engine. If you want more, you can make a custom jQuery build throwing out the bits you don't need. Still faster overall than crafting your own replacement.
@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.How many more utility functions will you need? Before you know it, you'll have reimplemented half the convenience methods that jQuery or Lo-Dash give you.
-
@DCoder said in This is how it feels to learn Javascript in 2016:
How many more utility functions will you need?
Utility expressions? I don't see how
convertToArray
is any better than[].slice.call
, at least until JavaScript gets more sensible types for the DOM.
-
If jQuery is your only dependency, sure, you can probably cut it out and save yourself time and effort.
If, however, you're anything like the folks I work with where you find off-the-shelf components to drop in, you probably need jQuery as those plugins all use it.
-
@DCoder said in This is how it feels to learn Javascript in 2016:
This list of jQuery's browser bug workarounds makes a counter-argument.
This. I use jQuery not (only) because I'm too lazy to type native JS, but because manually keeping up with and catering to every little incompatibility browser vendors keep inventing is just insane.
-
This month's great and wholly original insight into the javascript ecosystem churn.
"I can replace 17 different javascript frameworks with this one line of jQuery. Aren't I smart!?"
Sure thing granpa, you just keep telling yourself that.
Nothing new to see in this article.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
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 go b="propertyName1: variableName1, propertyName2: variableName2, ..." instead of having to do a onChange={(event, value) => setVariable(value) for every single one of them.
That's.... horrifying. *shudder*
-
@cartman82 What, having to do the
onChange
part?
-
@cartman82 said in This is how it feels to learn Javascript in 2016:
This month's great and wholly original insight into the javascript ecosystem churn.
"I can replace 17 different javascript frameworks with this one line of jQuery. Aren't I smart!?"
Sure thing granpa, you just keep telling yourself that.
Nothing new to see in this article.
I think the argument that you could, say, easily reimplement nodebb (with all its misfeatures) is poor, but the argument that you need a CI pipeline and browseify to write a simple page that 'makes the monkey dance' (I.e. JavaScript's original purpose) is just as bad.
-
@Rhywden said in This is how it feels to learn Javascript in 2016:
@cartman82 What, having to do the onChangepart?
Tying your code to a home-made hack in your current build system of choice.
Dude... no. Just type onChange. It's not that hard.
-
@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 What, having to do the onChangepart?
Tying your code to a home-made hack in your current build system of choice.
Dude... no. Just type onChange. It's not that hard.
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.
Also, "hack"? That's the preferred way óf doing a binding in C#/XAML.
-
@bb36e said in This is how it feels to learn Javascript in 2016:
I think the argument that you could, say, easily reimplement nodebb (with all its misfeatures) is poor, but the argument that you need a CI pipeline and browseify to write a simple page that 'makes the monkey dance' (I.e. JavaScript's original purpose) is just as bad.
Yeah. But here's the thing - no one is saying that you need browserify to make the monkey dance. I use jQuery all the time for simple pages. All frontend devs do.
However, that's just not enough anymore. All the complex business software that used to be implemented as desktop apps, then WebForms/MVC apps, is now moving to client + API apps. Backend is getting trimmed down to pure API-s or not even that (google "serverless"), while all the logic is moving to browsers and mobile devices. There's no stopping that. All these build systems and SPA frameworks are aimed at solving that, not animating web pages.
So when someone from peanut gallery comes out whining how you can do <simple demo> easier with just jQuery, it just sounds ignorant. You're not gonna make a maintainable equivalent of a typical mobile/desktop app without equivalent level of tooling.