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.
State of the Art JavaScript in 2016
131–140 of 306 posts
Re: State of the Art JavaScript in 2016
#132I'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…
Re: State of the Art JavaScript in 2016
#133Ember 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 ...
Re: State of the Art JavaScript in 2016
#134Measuring 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.
Re: State of the Art JavaScript in 2016
#135Earlier 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.
Re: State of the Art JavaScript in 2016
#136Why 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…
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
#137Ember 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.
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
#138I'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…
Well, I thought they were neat before at least.
Re: State of the Art JavaScript in 2016
#139I'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…
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
#140Can 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.