Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

Post reply on HN
Print view View original

161–170 of 306 posts

Re: State of the Art JavaScript in 2016

#161

Post by AlwaysBCoding »

f1hybrid wrote: post #158
natrius wrote: post #113

Earlier quoted context omitted.

React is a paradigm shift in UI development. If you've never tried it or a library inspired by it, that's why you're questioning the proponents. We're trying to spread the gospel that some folks found a better way to do things. Yes, I believe it is a mistake for any UI developer to delay learning React. It's fine to choose other tools later.

I come to HN regularly for advise. Should I be taking yours? I'm a web dev by proffession. React is a paradigm shift? Kind of like the paradigm shift 20 years ago where we said "separate your markup from your style, you'll be better off, promise"? Using css felt right, right from the start. I should really learn React? Mixing js and html in a react flavor does not give the the same sense of being on the right track.

dude, what are you talking about. I've used Backbone, Angular, and React extensively, and React is a significantly better paradigm for building stateful UI's than any of those other frameworks. It's not just a matter of stylistic preference, it's better in an objective way the same way git is better for source control than FTPing files to a server.

Re: State of the Art JavaScript in 2016

#162

Post by spriggan3 »

JDDunn9 wrote: post #139
georgefrick wrote: post #130

I'm not a fan of these discussions at all. We're all supposed to have been using X framework at X time period. In the enterprise we can't just keep rewriting all the god damn applications. For us contractors, we have to answer to clients we had 2 years ago about why their app is in Backbone. I mean, damn; we have to build software here and we aren't all Facebook. You might get warm and fuzzies from constantly startin…

Absolutely. React creates a dependency at the worst possible place, the view/component level. That's the one part of your code that should be the most re-useable. How many times do we have to re-write the same image galleries? The only clear winner can be vanilla JS web components, especially custom elements. A temporary polyfill is fine, but we need to say no to the extra dependencies like React and Polymer that tra…

> The only clear winner can be vanilla JS web component

It cannot work since some browsers have different support for different features. You think people stopped using Android 2.x or old iphones ? So you end up with polyfills and since polyfills become dependencies you end with abstractions akin to frameworks, even worse since you now need to maintain your own mess.

Javascript isn't scoped in an HTML page, that's its first "sin". Therefore, any component architecture needs to work against the natural workflow of a webpage. So no ,the winner is certainly not "vanilla JS" and you know it. unless you are dealing with some trivial apps, I bet you'd use framework X or Z in an heartbeat.

Re: State of the Art JavaScript in 2016

#163

Post by ChrisDutrow »

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.

Perhaps I'm naive, but shouldn't very many users already have jquery cached from several CDNs? So if you use a popular CDN for it, it should affect load times too much in most cases?

Re: State of the Art JavaScript in 2016

#164

Post by spriggan3 »

hoodoof wrote: post #13
shados wrote: post #12

Earlier quoted context omitted.

It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on https://webpack.github.io/docs/shimming-modules.html And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one. That's more a problem with…

Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.

But people should code for Webpack or JSPM or require JS or whatever. A good solution should just work no matter how the lib was coded, if it doesn't then the solution isn't worth the investment.

Re: State of the Art JavaScript in 2016

#165

Post by scrollaway »

f1hybrid wrote: post #158
natrius wrote: post #113

Earlier quoted context omitted.

React is a paradigm shift in UI development. If you've never tried it or a library inspired by it, that's why you're questioning the proponents. We're trying to spread the gospel that some folks found a better way to do things. Yes, I believe it is a mistake for any UI developer to delay learning React. It's fine to choose other tools later.

I come to HN regularly for advise. Should I be taking yours? I'm a web dev by proffession. React is a paradigm shift? Kind of like the paradigm shift 20 years ago where we said "separate your markup from your style, you'll be better off, promise"? Using css felt right, right from the start. I should really learn React? Mixing js and html in a react flavor does not give the the same sense of being on the right track.

You should learn React for one simple reason: It's quite definitely going to be huge. Well, that's what I was saying a year ago - it's fair to say now that it is already huge and it's likely to stick around for a long time (at least in JS years).

If you're involved in the JS scene, learning React will give you a big advantage. At which point you can decide whether you like it or not.

As for mixing JS and HTML, I went to a talk at last year's React Europe that beautifully explained why this isn't a concern. I had the same reservations at first, but I was convinced then. Suffice to say, give it a shot and see how you feel about it after (besides, jsx is optional).

Start here: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...

Re: State of the Art JavaScript in 2016

#166

Post by spriggan3 »

leeoniya wrote: post #117
pkrumins wrote: post #114

Ok, I've had enough. I'm making a prediction that the entire JavaScript ecosystem will collapse. This just doesn't make any sense. None of this is nice. It's all ugly and complicated. There's no beauty to these tools. There are no fundamental tools either. Everything is evolving too quickly. You've a choice of 25 frameworks, libraries, tools that change every day and break between versions. The complexity is growing…

Good ideas get standardized. Ideas from Coffeescript made it into es6, Promises, fetch, etc. Once there are sufficient standards that solve the pain points, the fragmentation will go away. JS is playing catch-up because it was pointless to advance the language when IE didn't even support the existing standards and had 90% market share. Now it has to distill all the good ideas from the past 2 decades and other languag…

Standardization isn't enough. No browser implements ES6 modules thus the webpacks and co.

Re: State of the Art JavaScript in 2016

#167

Post by AlwaysBCoding »

tarsinge wrote: post #160
georgefrick wrote: post #130

I'm not a fan of these discussions at all. We're all supposed to have been using X framework at X time period. In the enterprise we can't just keep rewriting all the god damn applications. For us contractors, we have to answer to clients we had 2 years ago about why their app is in Backbone. I mean, damn; we have to build software here and we aren't all Facebook. You might get warm and fuzzies from constantly startin…

My maybe controversial opinion is that a lot of these hype problems, fatigue, ... come from one thing : Angular is a bad framework which beneficiated from an ENORMOUS buzz. I clearly remember 2-3 years ago when there was still no big apps written in it but everyone wanted to use it because "the JavaScript framework from Google! It will rule them all!". Meetups were full, enterprise catched on, and everyone invested h…

You nailed it. I feel like I've been permanently damaged from digest cycles, ng-filters, providers, transclusion etc... I feel like others must have been damaged enough to write off new Javascript frameworks entirely, which is unfortunate given how great React is.

Re: State of the Art JavaScript in 2016

#168

Post by spriggan3 »

untog wrote: post #144
bottled_poe wrote: post #94

Earlier quoted context omitted.

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.

JavaScript is hardly the only language to have multiple test runners.

chai and expect aren't test runners, just libraries with assert helpers. I personnally stick to jasmine. Chai is what happens when Rubyists try to write some JS like they write some ruby.

Re: State of the Art JavaScript in 2016

#169

Post by [deleted] »

spriggan3 wrote: post #166
leeoniya wrote: post #117

Earlier quoted context omitted.

Good ideas get standardized. Ideas from Coffeescript made it into es6, Promises, fetch, etc. Once there are sufficient standards that solve the pain points, the fragmentation will go away. JS is playing catch-up because it was pointless to advance the language when IE didn't even support the existing standards and had 90% market share. Now it has to distill all the good ideas from the past 2 decades and other languag…

Standardization isn't enough. No browser implements ES6 modules thus the webpacks and co.

[deleted]

Re: State of the Art JavaScript in 2016

#170

Post by [deleted] »

spriggan3 wrote: post #166
leeoniya wrote: post #117

Earlier quoted context omitted.

Good ideas get standardized. Ideas from Coffeescript made it into es6, Promises, fetch, etc. Once there are sufficient standards that solve the pain points, the fragmentation will go away. JS is playing catch-up because it was pointless to advance the language when IE didn't even support the existing standards and had 90% market share. Now it has to distill all the good ideas from the past 2 decades and other languag…

Standardization isn't enough. No browser implements ES6 modules thus the webpacks and co.

[deleted]
Post reply on HN