I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.
It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on https://webpack.github.io/docs/shimming-modules.html
And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one.
That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...
Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.
But people should code for Webpack or JSPM or require JS or whatever. A good solution should just work no matter how the lib was coded, if it doesn't then the solution isn't worth the investment.
If you mean old jQuery plugins or libraries that aren't CommonJS compatable, Webpack even has your back on that via its various plugins.
I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way.
I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack?
I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure them. I just want the module that I need to function.
Most people don't need these things. And more and more companies have devops and infrastructure teams that can deal with that.
We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions.
That being said, dealing with legacy code always always suck.
I'd wager a bet that most people using JS today are nowhere close to having devops and infrastructure teams, but are still single people in their bedrooms copying and pasting stuff from Stack Overflow trying to make their online flower shops work.
For the life of me I cannot remember who it was, but somebody once essentially said that Javascript had the quality of allowing anybody to bring to life what's in their head, no matter their skill and experience level. You could almost mash the keyboard until it worked.
For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it.
I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a <script> tag. We're not moving in the right direction.
The reality is that these tools, eventually, are used by businesses trying to build stuff efficiently.
If we were to have a hackathon, and I could use the stack I have at work (which contains some of these tools, plus our own secret sauce), I'll trash anyone who's using script tags on a page.
Things like webpack, commonjs, npm, etc, are ways to bring that to everyone.
If you're making a little one off or a small project, then anything you're comfortable with will work. Heck, go and use a tool just because you like the logo. It won't make much of a difference.
It took me a while, but I'm now a big fan of React, Webpack, Babel, etc. That said, I had to make a little project yesterday, and I through 5 script tags on it, on of which was jQuery, and everything was fine. All of these new tools don't stop you from using what worked 3 years ago. I don't think allowing for more complicated set ups means it's less democratic. It just makes certain projects available to single developers, that would have in the past required a large team.
I agree though that the vibe is different. Newcomers feel less welcome. I think by the end of this year, we will see a layer of abstraction over a stack similar to the one described in this article, and that it will be the new jQuery, in terms of letting a novice developer make something surprisingly powerful. At least I hope so.
Agree we definitely need a stack that integrates all the best of breed tools for this stuff. There's some good boilerplates out there, which almost gets there, but it's not quite the same. I've considered building one. I think it would be especially interesting if it supported server side rendering out of the box and tightly integrated with aws lambda, aws api gateway, and the serverless framework.
I feel like if you are trying to make your online flower shop work, you probably shouldn't go near any where near any of these libraries. I think they are for experts who are working on large projects, probably 30,000+ lines. For the casual developer, use a script tag and go sell some flowers. I love that you can do that with Javascrpt, it's really easy to just write some code, so many fewer things to worry about for the beginner/intermediate than languages like Java and you can be so much more productive at the non-expert level.
Exactly, or better yet just use a saas ecommerce / blog /cms software package which gives you a lot of customizability without any programming like wordpress, wix, etc.
I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number".
Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your code is valid on some basic levels. I consider avoiding it to be a big waste of time. I've had a good experience getting the definitions files going for the libraries I use.
I also disagree with the statement that TypeScript is making JavaScript "like C# or Java". TypeScript lets you opt out of type checking all you want with minimal difficulty. It also will by default always emit JavaScript even if it detects type errors.
Thanks for posting your thoughts. I was leaning towards TypeScript myself (as opposed to ES6) for an Angular project that will be migrated to version 2.0. Angular 2 was actually written in TypeScript if I am not mistaken, and it's one of the three say, "supported" ways of writing A2 apps (along with ES5 and Dart).
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 sure that nothing else would break. Also during the rewrite, the compiler always pointed out at least one potential bug in each file, this was quite funny to see because we already considered our old js-code to have quite high quality.
The whole code browsing experience is just different, you can actually read partial sections of the code base and understand them, use code completion, "go to definition" and "find all usages" and it works reliably. Not using types is in my book professional misconduct.
His comparison with C#/Java is also very weird and shows he hasn't given it a proper try. The ducktyping nature of interfaces makes the code much less rigid than in java but still maintains most of the safety you need.
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:
> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types.
I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that would just be "int". (I'm sure you already know this, I'm just pointing this out for those who may not know or appreciate the subtleties.) Example:
data Maybe a = Nothing | Just a
In this example the "constructors" are Nothing and Just.
Of course, you can emulate first-order ADT sums using union types by just introducing artifical container classes and doing a union on those. While this works for simple cases, I believe (but cannot prove) that it's impossible to emulate GADTs using union types -- my intuition is that the presence of constructors to match on is an essential part of being able to "narrow" the types sufficiently to actually act upon what they "contain" (for each case).
However, and notwithstanding all of that... the use of union types in TypeScript is absolutely the best way to align with JavaScript since there's so much JS that just takes/returns values of type "whatever" (string | number | ...).
Btw, also agreed on the productivity boost. In the short term, it may not appear that you're getting faster, but once your application starts to grow beyond "trivial" you really start to notice the fact that you can refactor without fear.
That's interesting! I haven't paid much attention to Flow since trying out the initial release and finding it a bit lacking. (But then, I'm used to GHC/Haskell, so everything lacking!)
I truly feel that "disjoint unions" is one of those things you don't appreciate the true value of until you've used them for quite a while. The real eye-opener for me was implementing a state machine and finding that I could explicitly state exactly which bits of the state machine would propagate to $NEXT_STATE at every step... and have the compiler double-check for me that I got it right.
This is great. Seems less cumbersome than TypeScript's user defined type guards for distinguishing cases of a union. The sentinel value concept is something you could at least steal when creating user defined type guards to make them simpler, at least.
TypeScript union types and Flow tagged unions are nice to have, but to make them really useful you also have to provide a good way to pattern match on them. And there they both are still way behind Haskell.
This is really nice with a very good much to common JS patterns. Among other things it types the usage of string literals making possible to typecheck and refactor code that contains if (foo === 'bar').
Thanks for elaborating on the distinction. User defined type guards can get you some of the way there to distinguishing "int | int", but you don't get it for free-- the reality of being a superset of JavaScript.
https://gist.github.com/RikkiGibson/74fa3dbfdb1b2d7ab86d
The article isn't clear on this, but eslint and Babel works together to provide just enough typing to get you by, even checking symbol references across modules.
I was planning in giving TypeScript a go after having some problems a type system should be able to fix, but after having used just eslint for a while I don't really feel the need any more. Maybe something to reduce the syntax tax of Reacts propTypes would be nice, but then I'm set.
After all, ES is a heavily late bound, dynamically dispatched kind of thing. Which means a truly useful static type system supporting things like statically dispatched type classes and such, would force a completely different semantic on the language. I can't imagine that would be fun to debug in a live browser session.
Actually going back to C# now is a frustrating experience compared to ES6 in just how the type system limits you. Granted that has more to do with nominal typing vs structural, then static vs dynamic. I'm guessing TypeScript don't have the same issues.
I use all those tools daily, but this article feel patronising to me, I would feel inconfortable to say that whatever I use is the state of the art. Also the author is totally ignorant and bigoted about typescript.
I 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 bit too strongly in favour of `mocha`; I don't think `ava` should have been some easily dismissed, and I've recently run across a pretty nice framework called `painless`. And even if you do use `mocha`, I find `expect` to be a better assertion library than `chai`. I think a better answer here might be "use whatever works for you, so long as its not Jest". (The shoutout to `enzyme` was on point though; great library if you need to test React components.)
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.
React is a paradigm shift in UI development. If you've never tried it or a library inspired by it, that's why you're questioning the proponents. We're trying to spread the gospel that some folks found a better way to do things. Yes, I believe it is a mistake for any UI developer to delay learning React. It's fine to choose other tools later.
I come to HN regularly for advise. Should I be taking yours? I'm a web dev by proffession. React is a paradigm shift? Kind of like the paradigm shift 20 years ago where we said "separate your markup from your style, you'll be better off, promise"? Using css felt right, right from the start. I should really learn React? Mixing js and html in a react flavor does not give the the same sense of being on the right track.
dude, what are you talking about. I've used Backbone, Angular, and React extensively, and React is a significantly better paradigm for building stateful UI's than any of those other frameworks. It's not just a matter of stylistic preference, it's better in an objective way the same way git is better for source control than FTPing files to a server.
You should learn React for one simple reason: It's quite definitely going to be huge. Well, that's what I was saying a year ago - it's fair to say now that it is already huge and it's likely to stick around for a long time (at least in JS years).
If you're involved in the JS scene, learning React will give you a big advantage. At which point you can decide whether you like it or not.
As for mixing JS and HTML, I went to a talk at last year's React Europe that beautifully explained why this isn't a concern. I had the same reservations at first, but I was convinced then. Suffice to say, give it a shot and see how you feel about it after (besides, jsx is optional).
> separate your markup from your style, you'll be better off, promise
I think the benefits of this were undeniable but not quite for the reasons everyone thought. At that point html was such a mess that imposing ANY structure on it would have been an improvement. CSS saved us from nested image-table-slicing hell.
Separating markup from style is one way to structure a complex document but it's not the only way. However it's better than 'no way'. But don't cargo-cult it.
> Mixing js and html in a react flavor does not give the the same sense of being on the right track.
But you're not mixing js and html. JSX is not html, it's a DSL to express a tree-like structure. In that sense, it's like mixing js and...dom creation logic.
The reasons I'm aware of to avoid mixing html and js fall into roughly two categories - separation of concerns(don't mix business rules, state management, control flow etc with presentation) and concerns of encoding(building strings of html makes for poor development, debugging, brittle code, and so on).
Since React is just a view layer, it does not impose an entangling of concerns. You can do everything within React components, or separate things on your own or via some other framework.
Meanwhile, the gains from manipulating a DOM or a Virtual DOM are immediately obvious. Even the most popular libraries like jQuery advocate using a more structured approach than simply concatenating strings(e.g. jQuery's whole DOM creation and manipulation lib - although it does make tradeoffs and still allows plenty of html through). The (Virtual) DOM tree naturally allows for composition, compared to the complexities of composing strings of html together.
The paradigm shift from React isn't so much React itself, but the ecosystem it (subtly, or not so subtly) pushes alongside with it. Immutable state and pure rendering functions force you to think through the states and edge cases of your application that would otherwise remain as subtle bugs. Components with a clean life cycle(as opposed to angular 1 directives) allow for easy composition. The virtual dom allows you to divorce your framework from html and the browser, and transplant it to other devices.
By the way, the separation of markup and style was a fight for a semantic web. Web apps, which are React's primary use-case, generally sidestep that concern. The theoretical benefits of separating markup and style are still the same today, but the expectations placed on a web site have increased tremendously, and you must juggle those benefits with others.
One good (very good) thing about React is that you can learn it very quickly - at least all the basics. This is also because it only covers the "view" part of a framework.
In the past I tried many times to use some spare time to learn Angular, but it always felt too overengineered to me (also because it does much more than React) and I always stopped at the beginning. With React, just a few hours were enough to appreciate the concepts and get started.
Then of course you can add Redux and that will take more time, but you can almost just as well use React components with any state manager you like.
The author seems a bit conflicted on whether he likes or dislikes types.
First, to say that "Types are not nearly as critical to front end development as some will have you believe" misses the point of types. Every programming language has types, even dynamically typed languages. As a programmer, embracing that types underly the code's meaning affords much more power to write clean, correct, and elegant code. This argument stands regardless of the type of programming; types underly code.
On the other hand, there's his remark, "TypeScript tries too hard to make JavaScript like C# or Java." (You claim that this is an unfair complaint against TypeScript. Would you care to elaborate what you think TypeScript's purpose is?) Personally, I feel similarly when working in TypeScript. Sure, the compiler can catch a few things, and it's certainly a step above only runtime type checks, but the type system itself is fundamentally flawed.
The type systems of Java and TypeScript are actually quite similar, so I'm going to refer to them both here. Neither language has a really good idea of what a sum or union type looks like. Consider doing math, but you can only multiply. Sure, it's possible to hack around some things so that you get the same results, you're doing a huge song-and-dance just to say that what you really want is this plus that.
Type systems like those present in Java or TypeScript (or, as it turns out, most mainstream languages) that lack unions end up leaving this weird aftertaste.
So my takeaway here is that we can do better. Certainly writing Java or TypeScript eliminates classes of bugs that Python or JavaScript are susceptible to, but let's keep pushing. We owe it to ourselves to strive for much better more expressivity in our type systems.
I'll use TypeScript over JavaScript for now, but I'm always keeping an eye out for technologies that raise the bar.
mocha, ava, expect, chai, painless... honestly what the fuck is this. I'm not a javascript developer - is the ecosystem really so fragmented? What a nightmare.
It's not so bad. You just pick the most popular thing or use the recommendations in articles like this one. The ecosystem is harder to dive into than any other language I've used, but you only dive in fresh the first time (or after you've done something else for two years).
chai and expect aren't test runners, just libraries with assert helpers. I personnally stick to jasmine. Chai is what happens when Rubyists try to write some JS like they write some ruby.
The 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 React. You may think this is no worse than not having a patent rider at all. But that's not the case. If there is no patent rider then there is an implicit grant which cannot be revoked.
If you work for a software company and your company has patents then keep in mind that by using React you are giving Facebook a free license to your entire patent portfolio.
you are giving Facebook a free license to your entire patent portfolio.
It's bad, but it's not quite that bad. Theoretically, you could stop using React, then start the patent litigation. Then Facebook could not sue you for React because at the time litigation started you were not using the license. But that's definitely a high barrier to jump if you've built up react as a core part of web and/or native applications.
> You may think this is no worse than not having a patent rider at all. But that's not the case. If there is no patent rider then there is an implicit grant which cannot be revoked.
I believe a couple of lawyers have suggested that this could, maybe, arguably be true. However, no court has ever ruled as such, and the consensus among IP lawyers is that it's an unlikely outcome.
If you're worried about potential patent lawsuits, I would NOT suggest relying on the vague hope that someday a court might read an implicit patent grant into the BSD license, especially when you'll be facing off with Facebook's lawyers.
Or do you have some citation for the "implicit patent grant"? In particular, a court decision finding one?
if you make any sort of patent claim against Facebook
My understanding (and I'm asking for correction, if I'm wrong) is that last year FB changed this provision to only cover patents on technologies within React itself, not "any sort of patent claim against Facebook", which WAS the situation before they changed it.
So, the current state is a grant of "you are licensed to use our React patents at no cost as long as you don't try to make a legal claim that any of our React patents are not legally ours."
The old grant terminated if, among other things, you argued that any Facebook patent was invalid or unenforcable. This meant that if Facebook sued you over an unrelated patent, you couldn't defend yourself without the React patent grant terminating.
The new grant specifically exempts any counterclaims; you can't lose your patent grant just because you defend yourself. You can still lose it if you sue Facebook over unrelated patents.
The 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.
The obvious next question is: what patents are necessarily infringed in the first place, just because you used React? It's a useful tool, but even if Facebook have successfully acquired relevant US software patents, it's hard to believe there's anything significant in there that had no prior art. GUI programmers have been specifying presentation details declaratively, using templates, and bundling updates for performance since long before the existence of React (or Facebook, for that matter).
The obvious problem with this interpretation is that it doesn't matter if a patent contains anything significant. How much cash you have and how long you can endure the uncertaintities which come with a legal confrontation with facebooks lawyers are what matters.
Your "obvious" problem is based on the premise that whoever has the most money will win a lawsuit in the US. In that case, almost no-one using React needs to worry about this, because either Facebook is going to come after them and they will lose but that could happen regardless of how they act, or Facebook is going to decide they don't want to come after them and it doesn't matter.
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.
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...
But again, how is React any different in this respect to any other library or, for that matter, anything you develop in-house? Most of those libraries and anything you build in-house don't come with patent grants at all, and even if one other party grants you rights you still don't know whether some third party might also have a claim against you.
Patents, and particularly submarine patents, have been a risk in the software industry for a long time. This is particularly true in jurisdictions like the US, where both the everyone-pays legal system and the recognition of software patents are unfavourable to the little guy in most circumstances. No doubt many of us don't particularly agree with or support the current legal position, but there it is.
So that brings us back to my earlier question, which I notice you haven't actually answered: for this to make any difference in law, Facebook would need to have relevant patents that will apply if you use React, so what are they?
And if your argument is still that it doesn't matter because they can just sue you and keep pumping money in until you lose through attrition in court, then this is all irrelevant anyway, because in that case surely there would be any number of other grounds they could use to support an artificial, aggressive lawsuit like that without even mentioning anything about patents. I don't really believe even the US legal system is that distorted, by the way, I'm just playing along with your earlier argument to show why it wouldn't matter even if you were right.
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.
This 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.22 of Flow (released just a week ago) brought massive speed improvements that bring it decently on par with any other linter. I found I could finally re-enable it in Sublime Text after this release. It catches all kinds of things linters won't, and the upstart cost is relatively low. On the other hand, TS has the benefit of years of type files available for almost any library; don't underestimate how great that is.
Using React has been great as well. It's what I wish Backbone views had been from the beginning.
We certainly aren't wanting for choice. Between the dozens of Flux implementations, React alternatives like Mithril, interesting languages like ClojureScript (with Om if you want to keep using React) or Elm, multiple typing systems, and even WASM on the horizon - web development is an exciting field. It's also overwhelming, and I say that as someone who keeps his head in it over 12 hours a day.
---
Re: CSS, the story still feels incomplete. I want a way to write a library that will effortlessly import its own styles, so consumers can simply import the component and go to town. Most solutions are severely limited, slow, or both, mostly because they rely on inline styles. Nothing's wrong with inline styles, until you want to do :hover, :active, pseudo elements or the like.
See the React material-ui project for a very real example of how this can go wrong - note how every component has a dozen or more extension points for styles. I built a project with this recently and it was intensely frustrating that I couldn't simply add some CSS to the app to fix styles across the board - I needed to keep a giant file of extensions and be sure to apply them every time I used a component. And, of course, component authors can't possibly anticipate every possible use, so some of my selectors were ugly "div > div > ul > li:first-child" monstrosities.
CSJS (https://github.com/rtsao/csjs) is one of the few solutions I like. I would be very happy to see it, or something like it, go mainstream.
Polymer (https://www.polymer-project.org) is a solution for the styles problem. You can pack each component with its own styles, complete with all its functionality. This allows for a very clean separation of concerns among components. Better than all other libraries that I have tried. I hope that web components take off, because it is a great way to build apps. Currently they are only supported in Chrome.
Moving data between components in Polymer, can be done with data binding. The bad thing is that it could get messy for complex applications. Is not terribly bad, but it could be better. What Polymer needs is a better way to move data between components. If that problem is solved, Polymer would be an excellent alternative to create any kind of apps.
Yeah, I had good fun building a Polymer frontend for my weekend project, Secureshare. I got around some of the data binding shortfalls with polymer-signals.
It's been probably 2 years since I did it, so I'm sure there are better solutions - but I liked it as a dev environment. It's somewhat opaque, though.
Note that style scoping comes with Shadow DOM, so once browsers support that (it's happening now), you can get scoping with no libraries.
Polymer also adds a CSS custom properties polyfill and a CSS mixins (@apply) polyfill. Custom properties are implemented in FF and Chrome already, @apply is being worked on in Chrome.
Polymer always tries to be forward compatible with actual web standards, one of it's main benefits :) Eventually Polymer will mostly be just templating and convenience helpers on top of native standards.
Does all that really give you hope for the web as an application platform? I feel like there is an obvious kind of joke in so many discussions of front-end web programming tools. It is boarding on like a farce or satire of some kind ...
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.
It's happening, and yeah, it's not perfect. But almost nothing in tech is. If we can build the right abstractions to paper over the mess that is the web as a platform, it might be possible for us to easily build reliable / useful / safe applications again.
CSJS author here, thanks for the plug! I think CSJS fairly unique in comparison to the numerous alternatives in that it:
1) Can be used without any tooling whatsoever. It's just plain JS.
2) Doesn't reinvent the wheel. You can use regular CSS (normal syntax, pseudo classes, media queries) and regular JS (variables, modules) together, allowing you to use the best of both worlds.
I loved the ideas behind CSS Modules but wasn't sure about the complexity of re-implementing a new module/variable syntax into CSS. Why not just use what is already provided in JavaScript?
What's the story for tooling though? I haven't looked at CSJS much, just the readme, but it seems like the CSS bit essentially is a string, so you don't get the same kind of tooling you can from either CSS files or javascript objects, because it's all strings.
We 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 for distraction from getting real work done.
Build your app first. Then when you are unhappy, see if these tools make your life easier. But play with them first, don't make upfront commitments.
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.
Your view has merit but I think it is a minority one. Actually, I think the community is way beyond just webpack and babel. I think it's not exactly the "new Java," I think it's something we have not really see . It is kind of a stupendous over proliferation of many of these little kind of obscure projects.
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.
I would like to add that I've had an excellent experience with the Radium library for styles. Sass was a little better than CSS because you sort of get variables but being able to define styles in JS has fixed pretty much all of the remaining problems.
Wow, this is nearly our teams exact stack. One addition would be superagent instead of fetch. I really like Fetch, especially for react-native but superagent is just so simple and easy to use
I don't think this is a problem, I expect to wrap my HTTP calls inside of promise factories anyways. Promises solve the issue of callback piramids, there's no issue with a single rogue, well contained callback.
I'm making web apps/clients in the browser, servers using node.js and desktop "native" apps using nw.js. All in vanilla JavaScript, and I love it. If you need additional functionality, there's always a module for it (npmjs.com)
The interesting part is maybe that most apps look like this:
<html><body><canvas id="canvas"></body></html>
And the rest is JavaScript!
It does seem a bit stupid to load the browser just for the canvas element though, so if someone know a better solution, please post!
I've never had the chance to use a hiDPI display. But it will probably be upscaled and look the same as on a normal screen. It would be an easy fix to increase the canvas context scale though.
eslint also has auto-fix support to some extent. I don't know how far JSCS pushes it though.
The biggest thing is that whenever something new pops up, you can get an eslint plugin to lint it (eg: it took a wh ile for jshint to be able to take JSX or even just ES6 syntax, while ESLint got plugins for it pretty quick).
I think (don't quote me) that eslint is starting to have pretty cool Flow hooks, too.
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 starting with ClojureScript if you have a team not too familiar with the JS world is really rough.
I do really wish JS had native immutables with structural sharing, though.
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.
I'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].
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.
Mainly used angular and node.
Someone was telling me about ember.js, I wondered why I would use broccoli over browserify.
6 months later.
Was comparing browserify vs webpack.
1 month later.
At work we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything. It's been a huge boon.
PS Ramda it eats lo-dash and its imperative API for lunch. It's for power users, everything curried, higher levels of abstractions. Pick it up and learn it, it'll make you a better programmer.
Next stop Clojurescript. Om next is a library where you can get a feel for a Falcor + Relay stack in like 70 lines of code all without the specific tech bloat. David Nolen is a UI profit, just follow him.
> we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything
Would you mind elaborating what you mean by that? We also use Ember and I've been championing the use of Ramda. I'm curious how you fit immutable.js into Ember.
In a development world that is already rife with planned obsolescence, the Javascript world is the shining jewel. Reminds me of trying to construct the killer Yu Gi Oh deck. By the time you get all the cool cards, paying a small fortune for them of course, a new ban list comes out, new decks come out, and you have to start all over again. Is the game improved through all of this? Maybe it is, maybe it isn't, but I would say that this question becomes beside the point for many players...
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.
I'd place a small bet on the former, but I wouldn't go all in. I agree with you - those javascript folks are more ADHD than me. And that's saying a lot.
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.
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.
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).
Fully agree. Recently, I have discovered a new reason to use Ember. I have an Ember app I built, but only have a few hours a month to maintain it. Using the Ember stack makes it trivial for me to quickly (and almost painlessly) upgrade as needed, and focus the little time I have on building features. Reading this article made me cringe at the thought of using the proposed stack for this app, having to follow the development of each of these components separately, and fixing the glue between them when things go sour.
Ember gives me confidence, that I can keep maintaining the app with very low effort, especially now, that the Ember community is releasing a LTS version.
Hopefully it's improved since I used it two years ago, but back then the component api was terrible. Simple things like nesting components required undocumented apis and was much harder than it needed to be.
> 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 need Y and Z to replace X. It just works.
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 you actually need.
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.
Perhaps I'm naive, but shouldn't very many users already have jquery cached from several CDNs? So if you use a popular CDN for it, it should affect load times too much in most cases?
Odds are a single retina icon in your app is larger than jquery. Worrying about javascript code size is like worrying about the drag of a car bumper sticker.
jQuery is an 86kB static resource that almost certainly already exists in the browser's cache. You can choose to use it, or not, but you can't get stop it from being there!
So I'm unsure what kind of complexity you're adding by using it. Mental? Spiritual? Metaphysical?
Meh. I think a better reason to use something over $.ajax is the functionality and the API, not because "you don't need jQuery". $.ajax is very general purpose, whereas in most cases you simply need to be able to get and post json. Also, jQuery's promise implementation is one of the least-featured and most awkward to use, which drags down the $.ajax API.
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"
I think a good mindset for building modern javascript apps is that they are full featured desktop / mobile apps, just like a windows / mac / ios / android native app. By definition these types of apps are complex, and always have been, but they are highly valuable!
Looking at it from the lens of "web apps are just some html and css with a little jquery" is a mindset that can make building very ambitious web applications seem disproportionately difficult.
Hmm, I haven't found this to be true. I researched and chose nearly the same stack at work about six months ago, except I chose and we use immutable.js, es7 async functions, flow, and axios.
What seems to be about right is that javascript spa frameworks go on two year hype cycles if you look at backbone->angular->react.
I suspect react will buck this trend though because it's so heavily used in production consumer apps at facebook/instagram, because of react-native because it got components so right that it's almost hard to build ridiculously long "controllers" when using it, and that it's one way data flow make it a lot harder to write an app with state spread out all over the place rather than in a single client side data model. But who knows, time will tell :-)
A 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.
There is nothing today that typescript or even just raw javascript can't do perfectly fine on its own.
You still need some sort of templating library. You can use Handlebars or Mustache, but if you are using TypeScript there is now something better: https://github.com/wisercoder/uibuilder
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.
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.
I am currently building a large SPA in pure javascript (custom elements mostly) and it's wonderful. It's great to work with real components instead of React's hacked kinda-sorta-components.
It's always been a mess and the trend will likely continue :)
Every few months there is a new, up and coming framework everyone is saying that's better than the last popular one. And it's written in a dialect of JavaScript that isn't supported in most places so it has to be transpired first.
Good times /s
Honestly when I'm going into a new project I use a handful of utility type libraries and that's it. You can still develop very quickly this way. The DOM is awkward but very easy to use. I'm not convinced you need a framework.
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.
305 comments
[ 2.7 ms ] story [ 232 ms ] threadhttp://andrewhfarmer.com/aws-sdk-with-webpack/
Search google for webpack incompatible
And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one.
That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...
I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way.
Highly disagree.
I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure them. I just want the module that I need to function.
We're still in a world where every team is a snowflake (the closest things to breaching that was Rails and other server side MVC frameworks similar to it). Once the tech slows down a bit, you'll probably see better solutions.
That being said, dealing with legacy code always always suck.
For the life of me I cannot remember who it was, but somebody once essentially said that Javascript had the quality of allowing anybody to bring to life what's in their head, no matter their skill and experience level. You could almost mash the keyboard until it worked.
For me, this is a democratizing quality which is fundamental to the spirit of the web, and I would be more than happy to give up generators and class keywords for it.
I've recently spent over six hours trying to build and use a JS library, fighting with package managers, build systems and transpilers, whereas earlier all I would have need to do was download a file and include a <script> tag. We're not moving in the right direction.
If we were to have a hackathon, and I could use the stack I have at work (which contains some of these tools, plus our own secret sauce), I'll trash anyone who's using script tags on a page.
Things like webpack, commonjs, npm, etc, are ways to bring that to everyone.
If you're making a little one off or a small project, then anything you're comfortable with will work. Heck, go and use a tool just because you like the logo. It won't make much of a difference.
I agree though that the vibe is different. Newcomers feel less welcome. I think by the end of this year, we will see a layer of abstraction over a stack similar to the one described in this article, and that it will be the new jQuery, in terms of letting a novice developer make something surprisingly powerful. At least I hope so.
Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your code is valid on some basic levels. I consider avoiding it to be a big waste of time. I've had a good experience getting the definitions files going for the libraries I use.
I also disagree with the statement that TypeScript is making JavaScript "like C# or Java". TypeScript lets you opt out of type checking all you want with minimal difficulty. It also will by default always emit JavaScript even if it detects type errors.
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.
http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html
http://bit.ly/1LhA5id
The whole code browsing experience is just different, you can actually read partial sections of the code base and understand them, use code completion, "go to definition" and "find all usages" and it works reliably. Not using types is in my book professional misconduct.
His comparison with C#/Java is also very weird and shows he hasn't given it a proper try. The ducktyping nature of interfaces makes the code much less rigid than in java but still maintains most of the safety you need.
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)
I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that would just be "int". (I'm sure you already know this, I'm just pointing this out for those who may not know or appreciate the subtleties.) Example:
In this example the "constructors" are Nothing and Just.Of course, you can emulate first-order ADT sums using union types by just introducing artifical container classes and doing a union on those. While this works for simple cases, I believe (but cannot prove) that it's impossible to emulate GADTs using union types -- my intuition is that the presence of constructors to match on is an essential part of being able to "narrow" the types sufficiently to actually act upon what they "contain" (for each case).
However, and notwithstanding all of that... the use of union types in TypeScript is absolutely the best way to align with JavaScript since there's so much JS that just takes/returns values of type "whatever" (string | number | ...).
Btw, also agreed on the productivity boost. In the short term, it may not appear that you're getting faster, but once your application starts to grow beyond "trivial" you really start to notice the fact that you can refactor without fear.
http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html
I truly feel that "disjoint unions" is one of those things you don't appreciate the true value of until you've used them for quite a while. The real eye-opener for me was implementing a state machine and finding that I could explicitly state exactly which bits of the state machine would propagate to $NEXT_STATE at every step... and have the compiler double-check for me that I got it right.
EDIT: I accidentally a accidentally.
I was planning in giving TypeScript a go after having some problems a type system should be able to fix, but after having used just eslint for a while I don't really feel the need any more. Maybe something to reduce the syntax tax of Reacts propTypes would be nice, but then I'm set.
After all, ES is a heavily late bound, dynamically dispatched kind of thing. Which means a truly useful static type system supporting things like statically dispatched type classes and such, would force a completely different semantic on the language. I can't imagine that would be fun to debug in a live browser session.
Actually going back to C# now is a frustrating experience compared to ES6 in just how the type system limits you. Granted that has more to do with nominal typing vs structural, then static vs dynamic. I'm guessing TypeScript don't have the same issues.
By the way, can you extrapolate on eslint and babel working to check symbols across modules? I don't think I ever noticed that feature.
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 bit too strongly in favour of `mocha`; I don't think `ava` should have been some easily dismissed, and I've recently run across a pretty nice framework called `painless`. And even if you do use `mocha`, I find `expect` to be a better assertion library than `chai`. I think a better answer here might be "use whatever works for you, so long as its not Jest". (The shoutout to `enzyme` was on point though; great library if you need to test React components.)
If you're involved in the JS scene, learning React will give you a big advantage. At which point you can decide whether you like it or not.
As for mixing JS and HTML, I went to a talk at last year's React Europe that beautifully explained why this isn't a concern. I had the same reservations at first, but I was convinced then. Suffice to say, give it a shot and see how you feel about it after (besides, jsx is optional).
Start here: http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...
I think the benefits of this were undeniable but not quite for the reasons everyone thought. At that point html was such a mess that imposing ANY structure on it would have been an improvement. CSS saved us from nested image-table-slicing hell.
Separating markup from style is one way to structure a complex document but it's not the only way. However it's better than 'no way'. But don't cargo-cult it.
But you're not mixing js and html. JSX is not html, it's a DSL to express a tree-like structure. In that sense, it's like mixing js and...dom creation logic.
The reasons I'm aware of to avoid mixing html and js fall into roughly two categories - separation of concerns(don't mix business rules, state management, control flow etc with presentation) and concerns of encoding(building strings of html makes for poor development, debugging, brittle code, and so on).
Since React is just a view layer, it does not impose an entangling of concerns. You can do everything within React components, or separate things on your own or via some other framework.
Meanwhile, the gains from manipulating a DOM or a Virtual DOM are immediately obvious. Even the most popular libraries like jQuery advocate using a more structured approach than simply concatenating strings(e.g. jQuery's whole DOM creation and manipulation lib - although it does make tradeoffs and still allows plenty of html through). The (Virtual) DOM tree naturally allows for composition, compared to the complexities of composing strings of html together.
The paradigm shift from React isn't so much React itself, but the ecosystem it (subtly, or not so subtly) pushes alongside with it. Immutable state and pure rendering functions force you to think through the states and edge cases of your application that would otherwise remain as subtle bugs. Components with a clean life cycle(as opposed to angular 1 directives) allow for easy composition. The virtual dom allows you to divorce your framework from html and the browser, and transplant it to other devices.
By the way, the separation of markup and style was a fight for a semantic web. Web apps, which are React's primary use-case, generally sidestep that concern. The theoretical benefits of separating markup and style are still the same today, but the expectations placed on a web site have increased tremendously, and you must juggle those benefits with others.
In the past I tried many times to use some spare time to learn Angular, but it always felt too overengineered to me (also because it does much more than React) and I always stopped at the beginning. With React, just a few hours were enough to appreciate the concepts and get started.
Then of course you can add Redux and that will take more time, but you can almost just as well use React components with any state manager you like.
First, to say that "Types are not nearly as critical to front end development as some will have you believe" misses the point of types. Every programming language has types, even dynamically typed languages. As a programmer, embracing that types underly the code's meaning affords much more power to write clean, correct, and elegant code. This argument stands regardless of the type of programming; types underly code.
On the other hand, there's his remark, "TypeScript tries too hard to make JavaScript like C# or Java." (You claim that this is an unfair complaint against TypeScript. Would you care to elaborate what you think TypeScript's purpose is?) Personally, I feel similarly when working in TypeScript. Sure, the compiler can catch a few things, and it's certainly a step above only runtime type checks, but the type system itself is fundamentally flawed.
The type systems of Java and TypeScript are actually quite similar, so I'm going to refer to them both here. Neither language has a really good idea of what a sum or union type looks like. Consider doing math, but you can only multiply. Sure, it's possible to hack around some things so that you get the same results, you're doing a huge song-and-dance just to say that what you really want is this plus that.
Type systems like those present in Java or TypeScript (or, as it turns out, most mainstream languages) that lack unions end up leaving this weird aftertaste.
So my takeaway here is that we can do better. Certainly writing Java or TypeScript eliminates classes of bugs that Python or JavaScript are susceptible to, but let's keep pushing. We owe it to ourselves to strive for much better more expressivity in our type systems.
I'll use TypeScript over JavaScript for now, but I'm always keeping an eye out for technologies that raise the bar.
There is no one standard choice for anything (except possibly React and Redux as the author says). You get to choose your own stack, how you like it.
Yes, it's more effort to get something you like. But you end up with something you like more.
If you work for a software company and your company has patents then keep in mind that by using React you are giving Facebook a free license to your entire patent portfolio.
More info on weak vs strong retaliation clauses: http://www.rosenlaw.com/lj9.htm
It's bad, but it's not quite that bad. Theoretically, you could stop using React, then start the patent litigation. Then Facebook could not sue you for React because at the time litigation started you were not using the license. But that's definitely a high barrier to jump if you've built up react as a core part of web and/or native applications.
I believe a couple of lawyers have suggested that this could, maybe, arguably be true. However, no court has ever ruled as such, and the consensus among IP lawyers is that it's an unlikely outcome.
If you're worried about potential patent lawsuits, I would NOT suggest relying on the vague hope that someday a court might read an implicit patent grant into the BSD license, especially when you'll be facing off with Facebook's lawyers.
Or do you have some citation for the "implicit patent grant"? In particular, a court decision finding one?
My understanding (and I'm asking for correction, if I'm wrong) is that last year FB changed this provision to only cover patents on technologies within React itself, not "any sort of patent claim against Facebook", which WAS the situation before they changed it.
So, the current state is a grant of "you are licensed to use our React patents at no cost as long as you don't try to make a legal claim that any of our React patents are not legally ours."
The old grant terminated if, among other things, you argued that any Facebook patent was invalid or unenforcable. This meant that if Facebook sued you over an unrelated patent, you couldn't defend yourself without the React patent grant terminating.
The new grant specifically exempts any counterclaims; you can't lose your patent grant just because you defend yourself. You can still lose it if you sue Facebook over unrelated patents.
The obvious next question is: what patents are necessarily infringed in the first place, just because you used React? It's a useful tool, but even if Facebook have successfully acquired relevant US software patents, it's hard to believe there's anything significant in there that had no prior art. GUI programmers have been specifying presentation details declaratively, using templates, and bundling updates for performance since long before the existence of React (or Facebook, for that matter).
Patents, and particularly submarine patents, have been a risk in the software industry for a long time. This is particularly true in jurisdictions like the US, where both the everyone-pays legal system and the recognition of software patents are unfavourable to the little guy in most circumstances. No doubt many of us don't particularly agree with or support the current legal position, but there it is.
So that brings us back to my earlier question, which I notice you haven't actually answered: for this to make any difference in law, Facebook would need to have relevant patents that will apply if you use React, so what are they?
And if your argument is still that it doesn't matter because they can just sue you and keep pumping money in until you lose through attrition in court, then this is all irrelevant anyway, because in that case surely there would be any number of other grounds they could use to support an artificial, aggressive lawsuit like that without even mentioning anything about patents. I don't really believe even the US legal system is that distorted, by the way, I'm just playing along with your earlier argument to show why it wouldn't matter even if you were right.
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.22 of Flow (released just a week ago) brought massive speed improvements that bring it decently on par with any other linter. I found I could finally re-enable it in Sublime Text after this release. It catches all kinds of things linters won't, and the upstart cost is relatively low. On the other hand, TS has the benefit of years of type files available for almost any library; don't underestimate how great that is.
Using React has been great as well. It's what I wish Backbone views had been from the beginning.
We certainly aren't wanting for choice. Between the dozens of Flux implementations, React alternatives like Mithril, interesting languages like ClojureScript (with Om if you want to keep using React) or Elm, multiple typing systems, and even WASM on the horizon - web development is an exciting field. It's also overwhelming, and I say that as someone who keeps his head in it over 12 hours a day.
---
Re: CSS, the story still feels incomplete. I want a way to write a library that will effortlessly import its own styles, so consumers can simply import the component and go to town. Most solutions are severely limited, slow, or both, mostly because they rely on inline styles. Nothing's wrong with inline styles, until you want to do :hover, :active, pseudo elements or the like.
See the React material-ui project for a very real example of how this can go wrong - note how every component has a dozen or more extension points for styles. I built a project with this recently and it was intensely frustrating that I couldn't simply add some CSS to the app to fix styles across the board - I needed to keep a giant file of extensions and be sure to apply them every time I used a component. And, of course, component authors can't possibly anticipate every possible use, so some of my selectors were ugly "div > div > ul > li:first-child" monstrosities.
CSJS (https://github.com/rtsao/csjs) is one of the few solutions I like. I would be very happy to see it, or something like it, go mainstream.
Moving data between components in Polymer, can be done with data binding. The bad thing is that it could get messy for complex applications. Is not terribly bad, but it could be better. What Polymer needs is a better way to move data between components. If that problem is solved, Polymer would be an excellent alternative to create any kind of apps.
It's been probably 2 years since I did it, so I'm sure there are better solutions - but I liked it as a dev environment. It's somewhat opaque, though.
https://github.com/STRML/securesha.re-client/tree/master/pol...
Polymer also adds a CSS custom properties polyfill and a CSS mixins (@apply) polyfill. Custom properties are implemented in FF and Chrome already, @apply is being worked on in Chrome.
Polymer always tries to be forward compatible with actual web standards, one of it's main benefits :) Eventually Polymer will mostly be just templating and convenience helpers on top of native standards.
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.
It's happening, and yeah, it's not perfect. But almost nothing in tech is. If we can build the right abstractions to paper over the mess that is the web as a platform, it might be possible for us to easily build reliable / useful / safe applications again.
1) Can be used without any tooling whatsoever. It's just plain JS.
2) Doesn't reinvent the wheel. You can use regular CSS (normal syntax, pseudo classes, media queries) and regular JS (variables, modules) together, allowing you to use the best of both worlds.
I loved the ideas behind CSS Modules but wasn't sure about the complexity of re-implementing a new module/variable syntax into CSS. Why not just use what is already provided in JavaScript?
Am I just missing something obvious?
Build your app first. Then when you are unhappy, see if these tools make your life easier. But play with them first, don't make upfront commitments.
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.
The interesting part is maybe that most apps look like this:
And the rest is JavaScript!It does seem a bit stupid to load the browser just for the canvas element though, so if someone know a better solution, please post!
The biggest thing is that whenever something new pops up, you can get an eslint plugin to lint it (eg: it took a wh ile for jshint to be able to take JSX or even just ES6 syntax, while ESLint got plugins for it pretty quick).
I think (don't quote me) that eslint is starting to have pretty cool Flow hooks, too.
I do really wish JS had native immutables with structural sharing, though.
- 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.
[1] http://nodaljs.com/
[2] https://medium.com/@keithwhor/realtime-doesn-t-belong-everyw...
[3] http://graphql.nodaljs.com/
Go to terminal
ember new app
ember server
start writing code.
PS Ramda it eats lo-dash and its imperative API for lunch. It's for power users, everything curried, higher levels of abstractions. Pick it up and learn it, it'll make you a better programmer.
Next stop Clojurescript. Om next is a library where you can get a feel for a Falcor + Relay stack in like 70 lines of code all without the specific tech bloat. David Nolen is a UI profit, just follow him.
Would you mind elaborating what you mean by that? We also use Ember and I've been championing the use of Ramda. I'm curious how you fit immutable.js into Ember.
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.
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).
Ember gives me confidence, that I can keep maintaining the app with very low effort, especially now, that the Ember community is releasing a LTS version.
> 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 need Y and Z to replace X. It just works.
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 you actually need.
If the hammer and nails were actually better, then fine. But there's nothing actually wrong with $.ajax, that I can tell.
I'd happily include a 9kb (unminified) polyfill and work off the assumption that I can remove it a few years down the road.
$.Ajax is awesome and while XMLHttpRequest is awkward it's pretty straight forward.
And the whole point of TFA is that this is not the case. You can argue that it is, but not without getting into specifics.
Merely asking how can 2 things be simpler/smaller/better than 1 thing without taking into account what those 3 things are, makes absolutely no sense.
So I'm unsure what kind of complexity you're adding by using it. Mental? Spiritual? Metaphysical?
Looking at it from the lens of "web apps are just some html and css with a little jquery" is a mindset that can make building very ambitious web applications seem disproportionately difficult.
What seems to be about right is that javascript spa frameworks go on two year hype cycles if you look at backbone->angular->react.
I suspect react will buck this trend though because it's so heavily used in production consumer apps at facebook/instagram, because of react-native because it got components so right that it's almost hard to build ridiculously long "controllers" when using it, and that it's one way data flow make it a lot harder to write an app with state spread out all over the place rather than in a single client side data model. But who knows, time will tell :-)
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.
There is nothing today that typescript or even just raw javascript can't do perfectly fine on its own.
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.
Every few months there is a new, up and coming framework everyone is saying that's better than the last popular one. And it's written in a dialect of JavaScript that isn't supported in most places so it has to be transpired first.
Good times /s
Honestly when I'm going into a new project I use a handful of utility type libraries and that's it. You can still develop very quickly this way. The DOM is awkward but very easy to use. I'm not convinced you need a framework.