Meteor isn't even being mentioned anymore in most of these posts, but it really does reduce the need for so much tooling. Plus, it can use React as the view layer.
State of the Art JavaScript in 2016
81–90 of 306 posts
Re: State of the Art JavaScript in 2016
#82Can we all agree that State of the Art JavaScript in 2016 is a mess?
[deleted]
Re: State of the Art JavaScript in 2016
#83Meteor isn't even being mentioned anymore in most of these posts, but it really does reduce the need for so much tooling. Plus, it can use React as the view layer.
Meteor is so February 2016
Re: State of the Art JavaScript in 2016
#84Why 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 be compiled, but React's compiled code still has function calls for each virtual DOM element; Mithril templates compile into static Javascript data structures.
Another difference is that Mithril, being an MVC framework, rather than a templating engine, provides an auto-redrawing system that is aware of network asynchrony and that can render views efficiently without cluttering application code with redraw calls, and without letting the developer unintentionally bleed out of the MVC pattern.
Note also that, despite having a bigger scope, Mithril has a smaller file size than React."
Re: State of the Art JavaScript in 2016
#85I agree with 90% of this. React, Redux, ESLint with airbnb config, npm, webpack, lodash, ramda, fetch, css modules...absolutely. I disagree with the breezy assertion that types don't matter, and the offhand dismisal of TypeScript. And saying that "TypeScript tries too hard to make JavaScript like C# or Java" reveals, in my view, a fundamental failure to understand what TypeScript does. I also think the author is a bi…
Although the article covers a lot of things and provides some arguments (credit where it's due), the fashion in which the choices are made suffers from a kind of tunnel-vision favoritism. Claims like, "Everyone should use React. Period. Now!" just make me question the merits of its proponents. The JavaScript community is really infamous for this...
When things align, and the abstraction suddenly makes everything simpler, you start to see the wisdom of it. It's less about "proponents," more about people who understand it and how it affects the reality of frontend engineering.
Re: State of the Art JavaScript in 2016
#86> 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…
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.
Re: State of the Art JavaScript in 2016
#87Ember 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.
What the author failed to mention is how much work it is to get all of these ad-hoc projects working together.
Ember is a pretty cozy ecosystem in comparison. You get Babel, JSHint, npm and QUnit - out of the box. Most of which can be swapped out for your preferred libraries.
Re: State of the Art JavaScript in 2016
#88The 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…
I'm not completely on board with this argument. In particular, there may not be any patents on React in the first place, and the 'implicit grant' included in the BSD license is legally sketchy at best – AFAIK it has not been tested, which suggests that relying on any BSD licensed software exposes you to legal risk where you do not have an explicit patent license.
Re: State of the Art JavaScript in 2016
#89We 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.
I doubt this article offers any explanation of the bloat observed in many modern web pages. I suspect most web pages built using stacks like this will actually tend to be fairly economical on the client.
Re: State of the Art JavaScript in 2016
#90A 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.…
I disagree. I think React is a no brainer for any SPA. Try doing a full fledged SPA admin panel in pure javascript. It's madness. But with React you can separate everything else into components and it becomes clean and beautiful.