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.
State of the Art JavaScript in 2016
71–80 of 306 posts
Re: State of the Art JavaScript in 2016
#72Re: State of the Art JavaScript in 2016
#73Use typescript and just write it to do whatever you want it to do. You don't need React, or any of this stuff. Chai is good for testing. But as far as deploying a production application, there should be literally no dependencies. You don't need them.
There is nothing today that typescript or even just raw javascript can't do perfectly fine on its own.
Re: State of the Art JavaScript in 2016
#74This article echoes my experience this year and last, moving from a Backbone app into React + Fluxxor, and eventually into ES6 with Babel + Flow + Webpack. It's a huge pain to configure and understand all this tooling, but man is it nice once it's all working. It definitely gives me hope for the web as an application platform. Re: Flow, it's good but nowhere near as developed as TypeScript, but it's getting better. 0…
Every comment is has a different litany of obscure libraries and frameworks and combinations that sound like a set of random dictionary words with just a few common threads "react, react, blah blah."
It doesn't seem like "pace of technology change" and it certainly doesn't inspire the idea of relative maturity of the web as an app platform .... it seems like a comedy.
Re: State of the Art JavaScript in 2016
#75I'm a little bit bummed that the author seems to think there's "No API solution." Nodal [1] was released in early January to a great response, and I'd hope that more people are paying attention. Our most recent announcement was that we're focusing on being API-first [2]. We also have out-of-the-box GraphQL support [3]. [1] http://nodaljs.com/ [2] https://medium.com/@keithwhor/realtime-doesn-t-belong-everyw... [3] htt…
Don't be bummed :) The point was that there's no "obvious" solution. Something released in January needs a bit more time to become an obvious go-to. Doesn't mean it's not great or that it won't.
Re: State of the Art JavaScript in 2016
#76We all have our opinions and I would say take this article with a huge grain of salt (as well as my comment). State of the art javascript should still be considered a browser + editor + files. There is no need to overcomplicate things, and unfortunately Webpack and Babel do. It is terrifying to see javascript turn into the new Java - build steps and compile steps and configuration and everything you don't need except…
You're downvoted but I for one agree. KISS. If you really NEED all that stuff, fine, but it's quite clear why modern web pages are so bloated and slow on anything but current-gen hardware and fast networks.
Re: State of the Art JavaScript in 2016
#77Re: State of the Art JavaScript in 2016
#78A huge amount of this stuff is bloat, to me. It seems like this is a collection of libraries that largely were picked out of the problem that is javascript bloat today. Use typescript and just write it to do whatever you want it to do. You don't need React, or any of this stuff. Chai is good for testing. But as far as deploying a production application, there should be literally no dependencies. You don't need them.…
UIBuilder is basically TypeScript's TSX file but without React's bloat. The whole UIBuilder is about 100 lines of code. The advantage over Mustache is compile-time error checking of expressions used in the template, and of course full Intellisense, Refactoring etc if you are using Visual Studio.
Re: State of the Art JavaScript in 2016
#79We all have our opinions and I would say take this article with a huge grain of salt (as well as my comment). State of the art javascript should still be considered a browser + editor + files. There is no need to overcomplicate things, and unfortunately Webpack and Babel do. It is terrifying to see javascript turn into the new Java - build steps and compile steps and configuration and everything you don't need except…
I saw a headline of an article the other day, something about "collections of microservices becoming the new monoliths" and it seems like that's what JS community is tending toward, an enormous amount combinations of these these frameworks/libraries/build tools/package managers. I guess the advantage of this style over traditional monoliths is there are more conferences to go to, I dunno.
Re: State of the Art JavaScript in 2016
#80> Unless you’re working on a legacy application or have 3rd party libraries that depend on it, there’s no reason to include it. That means you need to replace $.ajax. > I like to keep it simple and just use fetch. It’s promise based, it’s built in Firefox and Chrome, and it Just Works (tm). For other browsers, you’ll need to include a polyfill. I laughed. Is this satire? There's no reason to have X, therefore you nee…