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

221–230 of 306 posts

Re: State of the Art JavaScript in 2016

#221

Post by marcus_holmes »

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.

if you have patents you want to enforce, yes. But I think most software folk kinda assume that if you're the kind of douche that enforces software patents then you deserve everything coming to you...

Re: State of the Art JavaScript in 2016

#222

Post by abledon »

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…

When i clicked on the link, i was really hoping it was a tongue-in-cheek medium article that just said to use jQuery haha.

Re: State of the Art JavaScript in 2016

#223

Post by t1amat »

neovive wrote: post #210

Just wanted to mention VueJS as an option on the front-end for those looking for a simple JS library with components.

I was enjoying lurking, reading some of the freak out around what amounts to spending a day or a week learning a new framework. Whether you believe that this JS theatre is good or bad, learning new concepts and solutions is never a waste of time, even if only to internally validate some other method. But if you thought that being a competent software engineer only required a one-time, upfront educational cost you probably got into the wrong field.

But throughout all this I was wondering who would come out and mention Vue.js. While my own current preference is CLJS and reagent/re-frame, I feel like this largely unknown framework should get some representation.

(Disclaimer: I am not claiming this is the best framework out there, but it is very nice and I believe a great alternative for many of the commenters here who are coming from Angular, trying to figure out where to turn next, but not wanting to toss years of experience.)

If you come from Angular and like it's declarative markup but don't care for the outdated architecture, Vue.js[1] is worth looking at. It's beautifully clean and blazingly fast (v-dom under the hood). If you are willing to use a Webpack or Browserify loader you get a very straightforward single file component style[2], similar to a web component, where you can easily mix and match style (scoped or not), script, and markup language of choice. The script side of the component looks remarkably similar to React if the render function was replaced with an external HTML template in the style of Angular.

For the Angular developers out there who "like things the way they are" (mostly), do yourself a favor and check it out.

[1]: http://vuejs.org/ [2]: http://blog.evanyou.me/2015/10/25/vuejs-re-introduction/

Re: State of the Art JavaScript in 2016

#224

Post by techdragon »

anantzoid wrote: post #184
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…

> You've a choice of 25 frameworks, libraries, tools that change every day and break between versions. And this is what the author has said too, and then presented a list of tools for different purposes to one doesn't fall into analysis-paralysis. Since past few months, JS community and settling down and tools are getting stable and long lasting. Surely, new ones are being developed everyday, but a standard is being…

Yeah... until the mountain of poorly documented plugins built on Webpack causes it to collapse just as Grunt, and Gulp did before it.

The first time I used Webpack... I wanted to punch someone so badly... their documentation for the Webpack plugin they wrote didnt mention that it would also turn all my SCSS/CSS into JavaScript. Imagine the disaster that was. This is the experience I have over and over again. I expect a 'plugin' to plug into things without requiring me to read every line of the plugin's source code... if I have to do that I may as well write my own tool. Community displeasure builds until someone writes a new tool and we get yet another mass exodus to that tool in the hope it will be better. It seems to be about 18 months to 1 year.

I suspect the entire JavaScript ecosystem is suffering from an effect similar to Dunbar's Number, https://en.wikipedia.org/wiki/Dunbar%27s_number

There becomes 'too many libraries' and after a certain point, the tower collapses again to a smaller pool of new dependencies because we cannot without much "fighting the tide" maintain a mental model with the level of complexity necessary to keep all these dependencies in our heads while working.

Re: State of the Art JavaScript in 2016

#225

Post by shados »

Too wrote: post #171
wozer wrote: post #19

Earlier quoted context omitted.

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 s…

Generally when TypeScript is compared to C#/Java, it is about the syntax look, or when contrasting it to other type system such as, let say, Scala. And then it's very much on the C#/Java side of the fence.

TypeScript definitely got the structural checking of interfaces right, but I beleive (correct me if I'm wrong, I'm referring to https://github.com/Microsoft/TypeScript/issues/202) that classes are also structurally checked. Flow does nominal checking for those, with very good reasons.

While it's a shame the details are light because you kind of need the presenter to go with the slides, the following explains a few of the reasons between TypeScript vs Flow:

http://www.scs.stanford.edu/16wi-cs240h/slides/fb-slides.htm...

(not the whole deck, just a few slides after 45)

Re: State of the Art JavaScript in 2016

#226

Post by t1amat »

shados wrote: post #100
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 starti…

I don't feel like the barrier to entry in ClojureScript is that deep. I think you will find it is awfully easy to pick up if you fall into one of the following categories:

- You have experience with Lisp dialects (even better, Clojure specifically).

In this case, you know the language semantics but not the application of in this domain. The core concepts are so simple, and there is so much material out there covering it, that picking this up should be easy.

- You have experience with modern reactive architectures in any language and an understanding to structure application state atoms.

In this case the concepts you learned will largely prevail and you will be left learning the language semantics. While Clojure has an enormous core library, you can do a lot with only a very rudimentary knowledge of the language.

Also, what you aim for will probably make a difference. Reagent and the hiccup style is incredibly easy to pick up, and re-frame supplies a very nice state manager. Om and Om/Next are probably more difficult to pick up, and at least in the case of Om, probably not worth it now. Om/Next seems to be an attempt at replicating an entire React/Relay or Falcor/GraphQL stack in Clojure/ClojureScript, and at this point it is dubious what size of an application you need to develop to break even on the architecture and complexity costs.

Re: State of the Art JavaScript in 2016

#227

Post by techdragon »

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…

Personally, my ideal library would be one that doesn't make me 'beg for help'... one that is so easy to use that I can just 'weave it in' to all of my existing HTML that need it without needing a mountain of pre made parts to work faster. After all... making strait HTML is pretty damn fast with any competent template engine, server side or client side.

Re: State of the Art JavaScript in 2016

#228

Post by shados »

ilostmykeys wrote: post #154

Relay beats Redux any day https://gist.github.com/idibidiart/49a095b6bc528638f34f

Until there's no 1:1 relationship between the client and the server APIs, or you don't control all parts of the server... Relay is amazing, but it makes assumptions about the server (its kind of the point).

Re: State of the Art JavaScript in 2016

#229

Post by shados »

tomc1985 wrote: post #97

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

Redux is 100~ lines of code without all the sanity check. Thunk is -4-.

You kind of need to settle on some kind of design pattern on how your data exists, flows, etc. You'll want to be reasonably DRY doing it. Whatever you code will probably be around the same scope. May as well use something that's already documented and done. Same some time.

Then if you want to roll up your own bundler, minifier, manage your script tags on your own, spend more time testing, etc...well, that's up to you :)

Re: State of the Art JavaScript in 2016

#230

Post by t1amat »

bbcbasic wrote: post #193

I have found using Elm a real joy, albeit for hobby projects. I do hope pure functional languages become state of the art by 2026.

Elm has a lot of beauty to it. I would definitely promote anyone interested in learning FRP in web development to look here first. They really nailed the essence of the architecture, and getting some experience with ML-family languages is bonus, as they are likely more approachable than Lisp-family languages for many. I'm really hoping Evan and the community can make this a more viable solution in the coming years.

That said, Elm can be difficult to use today. The foreign function interface is not all that great of an experience. There is a lot of friction in just defining, serializing and deserializing JSON objects. You wind up writing a lot of code you wish you didn't have too. Their great time traveling, hot reloading debugger doesn't actually hot reload anymore. And there is no real back end language synergy to speak of at the moment. Many are looking toward Elixir and Phoenix for support instead of more language-similar Haskell options like Yesod and Snap.

The competing PureScript, GHCJS, Websharper and FunScript alternatives also complicate the landscape that Elm plays in greatly.

Post reply on HN