State of the Art JavaScript in 2016 • Hacker News Board

Re: State of the Art JavaScript in 2016

#91

Post by sotojuan » Sat, Mar 12, 2016, 1:42 AM UTC

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…

? I always just install `isomorphic-fetch` or the browser-only version. Works fine. Why load jQuery instead of that?

Re: State of the Art JavaScript in 2016

#92

Post by coldtea » Sat, Mar 12, 2016, 1:48 AM UTC

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.

Re: State of the Art JavaScript in 2016

#93

Post by b34r » Sat, Mar 12, 2016, 1:50 AM UTC

I wrote an app generator (actively maintained) that actually follows many of these recommendations if anyone is interested: https://www.npmjs.com/package/generator-enigma

Re: State of the Art JavaScript in 2016

#94

Post by bottled_poe » Sat, Mar 12, 2016, 1:52 AM UTC

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.

Re: State of the Art JavaScript in 2016

#95

Post by tomc1985 » Sat, Mar 12, 2016, 1:56 AM UTC

interlocutor wrote: post #78

Kequc wrote: post #73

A huge amount of this stuff is bloat, to me. It seems like this is a collection of libraries that largely were picked out of the problem that is javascript bloat today. Use typescript and just write it to do whatever you want it to do. You don't need React, or any of this stuff. Chai is good for testing. But as far as deploying a production application, there should be literally no dependencies. You don't need them.…

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

Re: State of the Art JavaScript in 2016

#96

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

treenyc wrote: post #84

Why not mithril? https://lhorie.github.io/mithril/ Seems to be way faster, and easier to learn than any of those other framework/libs. For example: How is Mithril Different from Other React: Source: https://lhorie.github.io/mithril/comparison.html "The most visible difference between React and Mithril is that React's JSX syntax does not run natively in the browser, whereas Mithril's uncompiled templates do. Both can…

If you want the React semantic without the size, you can just use something like https://github.com/developit/preact (which is like 3kb once deployed).

You also don't need JSX if you don't want to. Using React without JSX and just aliasing the dom functions ends up looking almost the same.

The reason behind React and Flux is because of pitfalls behind MVC...though the whole rational behind that is probably not fit for an hacker news reply :)

Re: State of the Art JavaScript in 2016

#97

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

Who are all these people that need all these tools to write stuff in js? Go back to coder school!

Is this what it means to look for a job in the startup scene in 2016? It seems overwhelmingly likely that you'll be dropped into some unholy, frankenstein-esque work of "art"

While JS has a few pain points that should be addressed by tooling, I'd draw the line at React and jQuery and a bespoke, well-kept utility library

Re: State of the Art JavaScript in 2016

#98

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

Here's a short story.

I used to do a little bit of JavaScript. Initially it was easy. Functions! Easy enough. Vars! Cool. I get all of that. I wrote some code, worked. Wrote some more and it started not working as expected. I was curious why. I started reading into it and discovered interesting concepts like "hoisting".

Then a friend of mine told me about Clojure/ClojureScript. I never understood hoisting.

Re: State of the Art JavaScript in 2016

#99

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

lsdafjklsd wrote: post #54

At work we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything. It's been a huge boon. PS Ramda it eats lo-dash and its imperative API for lunch. It's for power users, everything curried, higher levels of abstractions. Pick it up and learn it, it'll make you a better programmer. Next stop Clojurescript. Om next is a library where you can get a feel for a Falcor…

Ramda really is awesome.

Re: State of the Art JavaScript in 2016

#100

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

acron0 wrote: post #40

Not even a mention of ClojureScript? :(

ClojureScript is pretty fantastic, and Om had a lot of the ideas behind Redux before Redux (a bit like Elm). It's still a bit early to build a team revolving around FP though (it can be done, but you need a big company commitment in term of hiring practices, training people, etc). Consider React/Redux a gateway drug. Sprinkle in some Ramda, maybe even some Folktale...and then you're in a better spot to go. But starting with ClojureScript if you have a team not too familiar with the JS world is really rough.

I do really wish JS had native immutables with structural sharing, though.