Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

171–180 of 306 posts

Re: State of the Art JavaScript in 2016

#171
post #19

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…

Agree. Typescript doesn't have real algebraic data types becauses at the end of the day, Typescript is just a statically-typed version of Javascript. And Javascript doesn't have adts. For me, the biggest advantage of static typing is that code is much more self-documenting. Also, refactoring becomes much easier.

Refactoring type safe code vs non type safe code is like night and day. We had a code base in js where even minor refactoring meant frenetic greping and manually replacing things a whole day, fixing problems for a week and occasionally getting a remaining bug on the production site a month after that. We rewrote the whole thing to typescript and after that you could do major refactoring in just minutes and be quite sure that nothing else would break. Also during the rewrite, the compiler always pointed out at least one potential bug in each file, this was quite funny to see because we already considered our old js-code to have quite high quality.

The whole code browsing experience is just different, you can actually read partial sections of the code base and understand them, use code completion, "go to definition" and "find all usages" and it works reliably. Not using types is in my book professional misconduct.

His comparison with C#/Java is also very weird and shows he hasn't given it a proper try. The ducktyping nature of interfaces makes the code much less rigid than in java but still maintains most of the safety you need.

Re: State of the Art JavaScript in 2016

#172
post #140
post #125

Can anyone tell me where to start on all of this as a self-taught beginner? I feel like I follow tutorials well and get basic apps up and running via tutorials. I've even built some basic tools in use by a handful of people at my job with Node and Meteor. But the minute I try to dive into React and some of these more professional tools in the ecosystem, I find myself totally lost.

The article mentions https://github.com/petehunt/react-howto . Its a damn good place to start.

I just took a look, really good article.

Re: State of the Art JavaScript in 2016

#173
post #69

Earlier quoted context omitted.

Seems like it makes sense to me. Here's an analogous situation to jquery: X = a huge workshop with a million tools, a table saw, ladders, and yes, a hammer and some nails Y = some nails Z = a hammer You need to hammer stuff as part of your job. Yeah, if you get rid of X you need to replace it with Y and Z, but it still seems like simplifying to me, if you're replacing a whole room full of tools with just the tools yo…

The workshop is free to use (it's on Google CDN), but the hammer and nails cost money. Seems like a no brainer to use the workshop. If the hammer and nails were actually better, then fine. But there's nothing actually wrong with $.ajax, that I can tell.

Why would you need the workshop if you're not going to use any of it except one thing?

Re: State of the Art JavaScript in 2016

#174

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…

I just shipped another of many successful projects using Angular. There are lots of blog posts out there complaining about it, such as that it's over-hyped, or that it causes messy HTML templates. I didn't start using it because of the hype, and I don't find it hard to write clean templates. The complaints are mostly nonsense, as far as I'm concerned, and I'm highly suspicious of any argument in favour of React that's simply based on saying it has "won" or that it is the "next generation".

Re: State of the Art JavaScript in 2016

#175

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. This sounds like a good thing, right? But this rider has a "strong retaliation clause" which says that if you make any sort of patent claim against Facebook this patent license automatically terminates. Which means Facebook can now sue you for patent infringement for using…

This clause is awesome. Software patents are awful and this clause reduces the chances of patent lawsuits.

Re: State of the Art JavaScript in 2016

#176

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…

It's also more than a little frustrating when you come to HN and people say "Angular/Node/whatever is bad, and you're a bad person if you use it" all while I'm actually making neat stuff using the aforementioned tools. Well, I thought they were neat before at least.

While other people are busy writing blog posts, I've been shipping successful projects with Angular. I'm getting paid to write code, and I don't get paid to write blog posts defending Angular, so I don't bother. Also, I've shipped some very complex apps built with Angular, and it's very obvious to me that many of the common complaints about it are nonsense written by people who have just used it for a few days.

Re: State of the Art JavaScript in 2016

#177
post #101

Earlier quoted context omitted.

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.

I'd wager a bet that most people using JS today are nowhere close to having devops and infrastructure teams, but are still single people in their bedrooms copying and pasting stuff from Stack Overflow trying to make their online flower shops work. For the life of me I cannot remember who it was, but somebody once essentially said that Javascript had the quality of allowing anybody to bring to life what's in their hea…

I feel like if you are trying to make your online flower shop work, you probably shouldn't go near any where near any of these libraries. I think they are for experts who are working on large projects, probably 30,000+ lines. For the casual developer, use a script tag and go sell some flowers. I love that you can do that with Javascrpt, it's really easy to just write some code, so many fewer things to worry about for the beginner/intermediate than languages like Java and you can be so much more productive at the non-expert level.

Re: State of the Art JavaScript in 2016

#179

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…

> we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything

Would you mind elaborating what you mean by that? We also use Ember and I've been championing the use of Ramda. I'm curious how you fit immutable.js into Ember.

Re: State of the Art JavaScript in 2016

#180

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…

> It's all ugly and complicated. There's no beauty to these tools.

Which succesful, widely adopted languages have beauty to their tools?

Post reply on HN