State of the Art JavaScript in 2016 • Hacker News Board

Re: State of the Art JavaScript in 2016

#251

Post by shados » Sat, Mar 12, 2016, 7:14 PM UTC

CuriousSkeptic wrote: post #238

fleshweasel wrote: post #8

I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number". Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your…

The article isn't clear on this, but eslint and Babel works together to provide just enough typing to get you by, even checking symbol references across modules. I was planning in giving TypeScript a go after having some problems a type system should be able to fix, but after having used just eslint for a while I don't really feel the need any more. Maybe something to reduce the syntax tax of Reacts propTypes would b…

Flow's way of handling classes nominally and interfaces structurally is really nice.

By the way, can you extrapolate on eslint and babel working to check symbols across modules? I don't think I ever noticed that feature.

Re: State of the Art JavaScript in 2016

#252

Post by mst » Sat, Mar 12, 2016, 7:38 PM UTC

cetra3 wrote: post #136

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…

I'm really interested in mithril from a technology stand point. The thing that holds me back from using it is the ecosphere around it. You look at powerhouses like react and angular and you can find a whole gamut of reusable components that you can just plug and play from the community. For instance: the twitter bootstrap framework we have options for both react ( https://react-bootstrap.github.io/ ) and angular ( ht…

Getting a more MVC approach and still leveraging the react ecosystem is making me seriously consider trying react+mobx.

Re: State of the Art JavaScript in 2016

#253

Post by lomnakkus » Sat, Mar 12, 2016, 7:39 PM UTC

andybak wrote: post #195

Disappointing that after months of moaning about the paralysis of choice, few of the comments are positive about a genuine and fairly defensible attempt to cut through that. He proposes a fairly simple stack (and for the sake of argument he assumes you're needs are beyond the 'static html and a touch of jQuery' stage). He spends time explaining them and makes a fairly good attempt to avoid the overly-new or overly-co…

Well, I guess I can count myself amongst the "haters". Specifically, I noticed your

> 4. I hate dynamic typing

... but I absolutely disagree with the phrasing. Your underlying assumption seems to be that "dynamic typing" is a Good Thing, by definition. I want to challenge that.

Thing is... I don't hate dynamic typing[1] as long as everyone is being "consenting adults" about it (GvR)... I just LOVE static type checking since it helps people who absolutely hate each other to get along on >= 1 axis! So much so that I try to evangelize at every opportunity.

> 5. Javascript is broken beyond repair

This is a straw man. People usually have very specific and valid(!) objections to JS semantics... and, sure, they can and probably will be fixed at some point, but given the facts and constraints of the web platform it's going to take years and years. Personally, I'd want to be programming in a better language ASAP rather than in several years.

[1] Should really be "dynamic type checking", but whatever.

Re: State of the Art JavaScript in 2016

#254

Post by house9-2 » Sat, Mar 12, 2016, 7:44 PM UTC

melvinmt wrote: post #126

Is there a boilerplate repo somewhere with all these frameworks and tools combined? Would love to dig more into this but configuring them all together would take me days.

My co-workers put together https://github.com/CodingZeal/react-boilerplate but the documentation is a bit lacking at the moment, you really need to know a lot about redux to use it.

Recommend: https://egghead.io/series/getting-started-with-redux

Re: State of the Art JavaScript in 2016

#255

Post by CuriousSkeptic » Sat, Mar 12, 2016, 8:16 PM UTC

shados wrote: post #251

CuriousSkeptic wrote: post #238

Earlier quoted context omitted.

The article isn't clear on this, but eslint and Babel works together to provide just enough typing to get you by, even checking symbol references across modules. I was planning in giving TypeScript a go after having some problems a type system should be able to fix, but after having used just eslint for a while I don't really feel the need any more. Maybe something to reduce the syntax tax of Reacts propTypes would b…

Flow's way of handling classes nominally and interfaces structurally is really nice. By the way, can you extrapolate on eslint and babel working to check symbols across modules? I don't think I ever noticed that feature.

As a plugin https://www.npmjs.com/package/eslint-plugin-import

Re: State of the Art JavaScript in 2016

#256

Post by ChrisDutrow » Sat, Mar 12, 2016, 8:23 PM UTC

nobleach wrote: post #244

ChrisDutrow wrote: post #159

Earlier quoted context omitted.

Out of curiosity, what's wrong with backbone?

I don't think anything is "wrong" with Backbone. It's dated in its ideologies though. Backbone comes from an era of script tags and a global "Backbone" namespace. Until recently, it required jQuery to do its "innerHtml/append" DOM manipulation. As a way to add structure to a jQuery app, it's great. It leaves a lot of freedom to the implementer. I did find that I required something like Marionette to assist with views…

Yeah, I use Backbone with Marionette on a project that's a few years old ( demo.enterprisejazz.com ). The "freedom to the implementer" part is very important to someone like me.

I don't think it would be productive to switch to something new even if that new thing was better.

Re: State of the Art JavaScript in 2016

#257

Post by Silhouette » Sat, Mar 12, 2016, 9:06 PM UTC

tobltobs wrote: post #220

marcus_holmes wrote: post #155

Earlier quoted context omitted.

This. I get that there's a few corporates that might have a patent portfolio they'd conceivably want to enforce against Facebook. But for the rest of humanity this is just a non-argument. If FB want to pick a fight with you, you're in a fight whether you use React or not.

It's just that with using react you leave your castles gate wide open.

But again, how is React any different in this respect to any other library or, for that matter, anything you develop in-house? Most of those libraries and anything you build in-house don't come with patent grants at all, and even if one other party grants you rights you still don't know whether some third party might also have a claim against you.

Patents, and particularly submarine patents, have been a risk in the software industry for a long time. This is particularly true in jurisdictions like the US, where both the everyone-pays legal system and the recognition of software patents are unfavourable to the little guy in most circumstances. No doubt many of us don't particularly agree with or support the current legal position, but there it is.

So that brings us back to my earlier question, which I notice you haven't actually answered: for this to make any difference in law, Facebook would need to have relevant patents that will apply if you use React, so what are they?

And if your argument is still that it doesn't matter because they can just sue you and keep pumping money in until you lose through attrition in court, then this is all irrelevant anyway, because in that case surely there would be any number of other grounds they could use to support an artificial, aggressive lawsuit like that without even mentioning anything about patents. I don't really believe even the US legal system is that distorted, by the way, I'm just playing along with your earlier argument to show why it wouldn't matter even if you were right.

Re: State of the Art JavaScript in 2016

#258

Post by gotchange » Sat, Mar 12, 2016, 9:06 PM UTC

andybak wrote: post #211

oneeyedpigeon wrote: post #206

Earlier quoted context omitted.

"HN comments needs an on-topic vs off-topic filter. Or a "yes we already know that" filter..." They already do; if something doesn't positively contribute to the discussion, downvote it.

I wasn't entirely serious about the filters but that's a fair point. I suppose what I'm actually saying is "Can we all downvote the more worn-out type of comments a bit more actively?". Which now I'm come out and said it sounds overly optimistic. ;-)

Yes we can and I started by yours. Sorry not adding to the discussion.

Re: State of the Art JavaScript in 2016

#259

Post by spankalee » Sat, Mar 12, 2016, 9:13 PM UTC

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…

I'm on the Polymer team, so admittedly biased here, but I don't understand your comment about Polymer minimizing reusability.

Polymer is designed to _mazimize_ reusability and interoperability via standards. Polymer elements just elements and you use them via standard API - set properties, attributes, listen for events, add children. The only wrinkle is that Shadow DOM is a little slow to polyfill, so we're using a wrapper on the DOM API. This will eventually go away.

Polymer is also extremely small compared to other libraries, and has no external dependencies: 34k gzipped without polyfills and 42k with. This will get better as native Custom Elements arrive across browsers later this year.

My main point is that in the Web Components future, it will not matter so much what libraries are used to implement components, as long as they are standard elements on the outside. The guts can be Polymer, some future web-component supporting React, Angular, etc., or just plain JS.

Re: State of the Art JavaScript in 2016

#260

Post by yazaddaruvala » Sat, Mar 12, 2016, 9:16 PM UTC

iffe_closure wrote: post #249

mbrock wrote: post #181

Earlier quoted context omitted.

> 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. Um. That applies to all software... but not especially to React and Redux. Or what are you comparing with? Is there anything in particular you dislike about React, or Redux, or Babel? I don't think this ecosystem is going to "collapse" at all. Something else will come along, as always. Until then…

> Redux is such a simple idea that I accidentally invented... >put your app's state in a global immutable object, then use values to represent actions that transform the state. It's not ugly or complicated. i agree that react is fairly simple..it's the other pieces to get it to be a complete solution that are just ugly and complex. I'm sorry but flux and redux are another layer of abstraction that are much harder for…

> I'm sorry but flux and redux are another layer of abstraction that are much harder for new starters to grasp. The advocates are so deep in the echo chamber that you don't realize how daunting all this.

As always in a large enough population, there exists multiple dichotomies. Its a difficult problem; In this case, some people want better(more specific) tools, and others want less choice and time to learn one tool well. There is no really good answer to this, given that you can't please everyone, and software empowers minorities to fulfill their visions regardless of the majority. Ideally we can just hope that all evolution is cyclic (explosion of ideas, consolidation of ideas, repeat) and overall we stay in a healthy equilibrium. However, this is a problem in all aspects of life, from fashion to food. Even within computer science its not a problem unique to JavaScript.

JavaScript without Babel, React + (Flux | Meteor | Redux | Relay) is a non-starter. Some may also swap out for: Angular | Ember | Backbone + jQuery. And almost always there are additional "custom"[0] homegrown frameworks on top of or alongside everything else. Java without (Spring | Guice), Lombok, (AspectJ | Spring AOP), Guava, (JodaTime | Java8), ApacheCommons, (Log4J | SLF4J), (Hibernate | ...) is a non-starter. Some may also swap out for: JavaEE + (Glassfish | JBoss). And almost always there are additional "custom"[0] homegrown frameworks on top of or alongside everything else.

I'm just using Java because I have to deal with it daily. However, undoubtedly this is a problem across any language or tool that has a large enough population.

[0] "custom" is in quotes because developers that create them always claim they are general purpose, regardless that in reality only one application has ever used it in production.