Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

131–140 of 306 posts

Re: State of the Art JavaScript in 2016

#131

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.

It's Django flavored but take a look at this repo[1]. Disclaimer, I'm the author. It wouldn't be too much effort to abstract out the front-end and make it back-end agnostic.

[1] https://github.com/scottwoodall/django-react-template

Re: State of the Art JavaScript in 2016

#132

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…

AMEN

Re: State of the Art JavaScript in 2016

#133

Ember barely gets mentioned and includes each "piece of modern web applications" OUT OF THE BOX with a great support community. I love not making all of those decisions and doing all the integration BS work. Ember feels like the worst kept secret.

Come on, Ember is so 2015 ...

Not sure if sarcasm or serious, but this sums up everything that is wrong with the Javascript community succinctly

Re: State of the Art JavaScript in 2016

#134

Measuring time intervals in years for everything JS related is to imprecise. "State of the Art in 3/2016" or at least quarterly would make more sense.

Sadly, I had the same thought. By the time you + your team get on that latest greatest, it's now been usurped. I really hope that the JS communities can come together for some common needs and have just a couple of "paved road" solutions. I can only imagine how confusing the current state of affairs is for someone who "[just] wants to get started building modern JavaScript apps"

Re: State of the Art JavaScript in 2016

#135
post #70

Earlier quoted context omitted.

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.

It's not so bad honestly. Just a little awkward. For my little JavaScript library I wrote a small utility that lets me do Ajax calls that work in node and the browser. It's limited but it's all I need and it's pretty well tested (msngr if you're board). $.Ajax is awesome and while XMLHttpRequest is awkward it's pretty straight forward.

If that's all you're after, I'd suggest something like Zepto win only the Ajax module: http://zeptojs.com

Re: State of the Art JavaScript in 2016

#136
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 (https://angular-ui.github.io/bootstrap/).

But with mithril, the only bootstrap library I have found has not been updated in 2 years (https://github.com/eddyystop/mithril-components-bootstrap).

I really wish mithril had a bigger community around it, as when I used it for a few prototypes it was a pleasure to work with and fast as hell.

Re: State of the Art JavaScript in 2016

#137

Ember barely gets mentioned and includes each "piece of modern web applications" OUT OF THE BOX with a great support community. I love not making all of those decisions and doing all the integration BS work. Ember feels like the worst kept secret.

This. My team is currently making a pretty big bet on the future of Ember, and so far it's been amazing (coming from Drupal + Rails templates with jQ everywhere). Back-ends are in Rails API. Works great with Ember and you don't have to make 47462685868 decisions to get started with a project, make all the tooling play nice, then teaching the rest of your team how it all works. We're currently in the process of establishing a "paved road" for CI/CD for Rails API back-end + Ember front-end apps.

Ember CLI is also awesome, and Ember CLI Deploy is damn cool once you get it: http://ember-cli.com/ember-cli-deploy/docs/v0.4.x/lightning-...

Deployments take tens of seconds. Roll-backs take single-digit seconds. Previewing not-active-but-uploaded versions of the UI is trivial. Everyone does the same exact thing when they deploy (or throw it on Jenkins for even more fun).

Re: State of the Art JavaScript in 2016

#138

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.

Re: State of the Art JavaScript in 2016

#139

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 trap us in dependency hell and minimize re-useability.

Re: State of the Art JavaScript in 2016

#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.
Post reply on HN