State of the Art JavaScript in 2016 • Hacker News Board

Re: State of the Art JavaScript in 2016

#101

Post by shados » Sat, Mar 12, 2016, 2:07 AM UTC

hoodoof wrote: post #34

cnp wrote: post #30

Earlier quoted context omitted.

If you mean old jQuery plugins or libraries that aren't CommonJS compatable, Webpack even has your back on that via its various plugins. I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way. Highly disagree.

I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack? I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure…

Most people don't need these things. And more and more companies have devops and infrastructure teams that can deal with that.

We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions.

That being said, dealing with legacy code always always suck.

Re: State of the Art JavaScript in 2016

#102

Post by BinaryIdiot » Sat, Mar 12, 2016, 2:09 AM UTC

hughes wrote: post #70

alextgordon wrote: post #60

> Unless you’re working on a legacy application or have 3rd party libraries that depend on it, there’s no reason to include it. That means you need to replace $.ajax. > I like to keep it simple and just use fetch. It’s promise based, it’s built in Firefox and Chrome, and it Just Works (tm). For other browsers, you’ll need to include a polyfill. I laughed. Is this satire? There's no reason to have X, therefore you nee…

Have you ever started a js app thinking you don't need jQuery? It usually goes great until you need to make a request. One look at `XMLHttpRequest` and suddenly including a 92kb (unminified) library starts to sound appealing. I'd happily include a 9kb (unminified) polyfill and work off the assumption that I can remove it a few years down the road.

It's not so bad honestly. Just a little awkward. For my little JavaScript library I wrote a small utility that lets me do Ajax calls that work in node and the browser. It's limited but it's all I need and it's pretty well tested (msngr if you're board).

$.Ajax is awesome and while XMLHttpRequest is awkward it's pretty straight forward.

Re: State of the Art JavaScript in 2016

#103

Post by reedlaw » Sat, Mar 12, 2016, 2:12 AM UTC

I agree that React, Webpack, et al. are great improvements compared to their predecessors. But do I really want to start an app in 2016 knowing that there may be even better tools in 2017? Most likely I would use these but what ails me is the thought that I might have to learn yet another tool and migrate. Why does the JavaScript ecosystem move so quickly? I get that browser technology is exciting and constantly improving. But why can't we settle on some well designed concepts and keep them well maintained? I hope React is it because I like it but it really depends on Facebook's commitment.

Re: State of the Art JavaScript in 2016

#104

Post by BinaryIdiot » Sat, Mar 12, 2016, 2:13 AM UTC

achairapart wrote: post #77

Can we all agree that State of the Art JavaScript in 2016 is a mess?

It's always been a mess and the trend will likely continue :)

Every few months there is a new, up and coming framework everyone is saying that's better than the last popular one. And it's written in a dialect of JavaScript that isn't supported in most places so it has to be transpired first.

Good times /s

Honestly when I'm going into a new project I use a handful of utility type libraries and that's it. You can still develop very quickly this way. The DOM is awkward but very easy to use. I'm not convinced you need a framework.

Re: State of the Art JavaScript in 2016

#105

Post by interlocutor » Sat, Mar 12, 2016, 2:14 AM UTC

tomc1985 wrote: post #95

interlocutor wrote: post #78

Earlier quoted context omitted.

You still need some sort of templating library. You can use Handlebars or Mustache, but if you are using TypeScript there is now something better: https://github.com/wisercoder/uibuilder UIBuilder is basically TypeScript's TSX file but without React's bloat. The whole UIBuilder is about 100 lines of code. The advantage over Mustache is compile-time error checking of expressions used in the template, and of course ful…

You can write your own "templating library" in about 20 lines of regular boring ol' JS

With compile-time error checking of expressions that insert dynamic content into the template? With support for intellisense and refactoring?

Re: State of the Art JavaScript in 2016

#106

Post by alextgordon » Sat, Mar 12, 2016, 2:15 AM UTC

coldtea wrote: post #92

alextgordon wrote: post #60

> Unless you’re working on a legacy application or have 3rd party libraries that depend on it, there’s no reason to include it. That means you need to replace $.ajax. > I like to keep it simple and just use fetch. It’s promise based, it’s built in Firefox and Chrome, and it Just Works (tm). For other browsers, you’ll need to include a polyfill. I laughed. Is this satire? There's no reason to have X, therefore you nee…

You would have a point only if X was smaller (or at least equal) to size, complexity etc to Y + Z. And the whole point of TFA is that this is not the case. You can argue that it is, but not without getting into specifics. Merely asking how can 2 things be simpler/smaller/better than 1 thing without taking into account what those 3 things are, makes absolutely no sense.

jQuery is an 86kB static resource that almost certainly already exists in the browser's cache. You can choose to use it, or not, but you can't get stop it from being there!

So I'm unsure what kind of complexity you're adding by using it. Mental? Spiritual? Metaphysical?

Re: State of the Art JavaScript in 2016

#107

Post by increment_i » Sat, Mar 12, 2016, 2:19 AM UTC

Whenever these kinds of JS commentaries pop up on HN nowadays, I notice two distinct camps of commenters emerge: Those who are obviously steeped in the JS scene and are delighted to argue the finer, more sophisticated points of it, and those who take their best look, step back, and criticize this convoluted house of cards - and of course proceed to be downvoted into the Stone Age as the latest casualty of HN censorship.

My only observation of note I guess is the sheer marvel that all of this is nearly entirely supported by the Open Source community, and the amount of engineering effort being poured into the JS ecosystem at this point in time is nothing short of astounding. I can't wait to see where it goes in the next few years.

Re: State of the Art JavaScript in 2016

#108

Post by Silhouette » Sat, Mar 12, 2016, 2:24 AM UTC

tobltobs wrote: post #63

Silhouette wrote: post #58

Earlier quoted context omitted.

The problem with React is its patent rider. React.js comes with a BSD license, but has a patent rider that gives you a license to React's patents. The obvious next question is: what patents are necessarily infringed in the first place, just because you used React? It's a useful tool, but even if Facebook have successfully acquired relevant US software patents, it's hard to believe there's anything significant in ther…

The obvious problem with this interpretation is that it doesn't matter if a patent contains anything significant. How much cash you have and how long you can endure the uncertaintities which come with a legal confrontation with facebooks lawyers are what matters.

Your "obvious" problem is based on the premise that whoever has the most money will win a lawsuit in the US. In that case, almost no-one using React needs to worry about this, because either Facebook is going to come after them and they will lose but that could happen regardless of how they act, or Facebook is going to decide they don't want to come after them and it doesn't matter.

Re: State of the Art JavaScript in 2016

#109

Post by Niksko » Sat, Mar 12, 2016, 2:25 AM UTC

I'm in the process of learning a JS stack at the moment, and I've come to almost an identical conclusion to this article about the packages and tools to use.

One difference though is that I've read Relay and GraphQL will eventually win out over Redux. Thoughts?

Re: State of the Art JavaScript in 2016

#110

Post by yread » Sat, Mar 12, 2016, 2:32 AM UTC

bottled_poe wrote: post #94

Lazare wrote: post #15

I agree with 90% of this. React, Redux, ESLint with airbnb config, npm, webpack, lodash, ramda, fetch, css modules...absolutely. I disagree with the breezy assertion that types don't matter, and the offhand dismisal of TypeScript. And saying that "TypeScript tries too hard to make JavaScript like C# or Java" reveals, in my view, a fundamental failure to understand what TypeScript does. I also think the author is a bi…

mocha, ava, expect, chai, painless... honestly what the fuck is this. I'm not a javascript developer - is the ecosystem really so fragmented? What a nightmare.

I was kinda hoping it was satire