_uhtu

"but presumably they've stripped out many of the things that make React enjoyable to use in order to satisfy some arbitrary file size metric"

Why make this claim without looking yourself? You could validate that "presumably" by just looking at the docs, but instead you get sassy about it.

If you look at the docs, you'll see that the API is almost exactly the same. You really don't lose any features from switching to Inferno from React, what you lose is the React community.

I say this as an avid React user. Don't discredit something until after you've dove into it a bit.

I use React currently and yes, this is an important argument.

Faster load times are better. And if Inferno accomplishes better rendering speed while also being smaller, it is basically universally more performant than React.

I evaluated both thoroughly and chose React over Inferno because of the massive community around React, but numbers like this are intriguing.

"Silently fail with no warnings" is like the angular motto... At least in Angular 1 if something failed usually angular would just show an empty string on the screen.

Debugging is just a cold dark hell where very very few resources can help you find what went wrong, you basically just need to litter everything with console logs (Except the template html syntax, which you can't just write JS log statements in since... it's not javascript, its it's own language.

I've become much more productive and comfortable in all the JS vdom frameworks which have no template language, just javascript.

The majority of comments in this thread so far are along the lines of "How is financial help defined in this context???" yet it's described in the article:

"The type of financial support varies substantially. Nearly 30 percent of those receiving help accept health insurance and approximately the same percentage welcome assistance with purchasing a home or renting. Auto insurance was another big contributor, with 26 percent of young people receiving help to pay for it, and 23 percent getting help with utilities."

Come on people, don't start typing out a response if you haven't even looked at the link. Especially considering it's like 10 sentences total and anyone could skim it in a minute flat.

Pretty much yeah, just avoids tampering with the Object/Array prototype and gives you a chance to write the functions themselves.

They are all just a few lines, so they make for great practice to write yourself.

I considered ImmutableJS a little while back. It's a great library but it makes you to a lot of work to go back and forth between native JS objects, and just abstracts you from the real objects underneath.

Instead I ended up just deepFreezing my data (only in development) and wrote a bunch of pure functions which perform all the important array/object functions but return a new array/object instead of mutating. It was a really great exercise in functional programming and I'd recommend it to anyone wanting immutable data and to understand immutable programming styles.

I'm not the author but I'd guess almost nothing. Basically you just need to calculate the result of the function and index it by the result, should be almost completely unnoticeable.

Does anyone out there use MobX in production on a large app and have any comments on how the experience is? Especially how it scales beyond simple todo list apps.

That's not what I said at all. And I think you're really misconstruing my words with the goal of declaring that NoSQL, an extremely large category of databases, is bad, which is a dangerous generalization. I never said anything about difficulity getting NoSQL databases to work, i talked about how they are put to use in problems that don't warrant them as a solution.

The problems that I said are as follows: 1. One of the most popular NoSQL databases early on (MongoDB), is imperfect, but a lot of people decided to use it without really reading into what it does and the flaws it as because:

2. people got so hung up on hype for NoSQL that they did not think about what makes it great for certain use cases. Key-value stores offer unrivaled scalability, allowing you to store extreme amounts of data and cluster it efficiently, something that is simply not possible in relational databases. However, they do not offer the relational capabilities of SQL (and i'd say for most apps and services these days the vast majority of data is relational). The nice part about document stores, which are really what got the hype going about NoSQL, is that they offer the extreme scaling potential of key-value stores and offer some relational capabilities. Thus they are great for high volume nested data which will be looked up almost always by it's primary key. People ignored that this was the optimal use case and just used Mongo it when it seemed convenient and cool, which led to problems down the line when the realized they didn't have relational capabilities and they didn't have a schema to keep things organized.

I use a key-value store (NoSQL) and a document store (NoSQL) every day as well as a relational store (SQL). You just need to pick the right DB for the situation. No database is a jack of all trades.

I think a lot of the hate for NoSQL comes from 2 places:

1. Imperfect implementations. For example Mongo with it's lack of transactional safety (if that's still an issue, haven't worked with Mongo in a long time). Since then several different ideas and implementations have come forward and if you're looking for NoSQL right now and you have a good use case for it, you will almost certainly find a product that does just what you need.

and 2. People not understanding what NoSQL is good for and when to use it over relational. If you try to use a document store to store heavily relational data you're going to quickly give yourself a headache. The real use case of document stores is that they let you have the immense scalability of key-value stores (due to the nature of key-value stores) while also giving you some nested data and basic relational abilities.

In our stack we use a combination of SQL (Postgres), key-value store (Redis), and document store (DynamoDB), each picked to solve a certain problem and not go out of the bounds of what it's good for.

This isn't correct.

The users/1 doesn't take you to the user with id=1, it takes you to the user with username=1, which is very different. For example you can see my github profile on this api by doing

https://api.github.com/users/cvoege

The link you gave there is to the person with the username 1.

Second of all you can't see my email since it's not publicly available on github, and most people's aren't as far as I know.

Third of all incremental integer ids isn't the "rails way", this would be decided by the database and has nothing to do really with rails or whatever framework you use.

Isn't that part of the React mantra? Everything is completely unopinionated except for rendering HTML based on data? Like it makes no opinion on how you should do state or HTTP requests as well as no opinion for styling, which is something I love since it avoids duplicating code or incompatibilities with standalone libraries.

I've been doing SPA's in react for a while and have had 0 problems whatsoever with styling. As long as you stick to good standards and naming conventions and use SASS or Stylus or something to keep things organized.

What tends to give people so much trouble with styling?

Not sure why you spent 4 hours on that, in addition to the other response there's also this method, which lets you call map on it and also call all the methods available to NodeList (you'd lose access to those if you converted it to an array)

  var classNames = [].map.call(nodeList, (entry) => entry.className)

The 'call' function in java script allows you to specify the "this" in the calling of the function. So we grab the map function from an empty array, and call it with nodeList as "this". You can find out more here: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

You could also use that to make a super simple method to allow you to call map on any array like object, then you can import this into your other files:

  function map(arr, callback) {
    return Array.prototype.map.call(arr, callback);
  }

Then call it like

  var classNames = map(nodeList, (node) => node.className);

I disagree because I do find JavaScript to be the best tool for client side development. You get full access to the DOM without worrying about your transpilers abstractions. Also I think JavaScript is a pretty wonderful language to code in once you apply a strict linter + Babel.

I see a lot of people working really hard to use the same language on client and server, but I've never had any difficulty working with multiple languages nor have my teammates. The biggest advantage for using different languages for me is that it lets you get to choose the best tool for the job on both sides without compromising. Would anyone who holds the alternate view, that they have reaped significant advantages from using the same language on server and client, care to chime in?

If you had to explain that your party stands for in a simple comment, what would you say it is?

I've had similar success. The biggest benefit has been with memory in my experience, much much less RAM usage although i don't have specific numbers right now.

This title is not click bait at all. It presents a question and spends a brief article explaining the exact answer to the question. The answer is too long to fit in the title, and there's no click every paragraph to get to the next one bullcrap.

They should really mention that on the website for crystal. I think a lot of people are scared off by seeing the words alpha and breaking changes. Changing those to "beta" and "stable" on the site would help a lot IMO. At the very least calling it stable would be huge.

That's good! It's always frustrating trying to find a breaking change in an interpreted language, so I can imagine it would be much easier in Crystal.

Thanks for answering!

I feel like Crystal is one of the best projects out there but it's not getting much attention. What do you think it will take to get people to start writing projects and contributing?

IMO the number one thing will be to start getting as many articles like this out as possible, and go beyond that. TodoMVC/Yelp Clone tutorials would go a LONG way I think, especially since a lot of people will just fork those projects to mess around in them.

I was more just talking about how as language popularity goes up so does your likelihood of finding the solution to any given problem on the internet.

Yeah and that behavior of automatically switching has overhead, and should be taken into account when comparing languages.

My biggest concern if i were to try to use Crystal in production would be the lack of "googleability". I'm guessing your team is very familiar with the language, so it's not as much of a problem that you can't Google a problem when it happens. Do you feel that this is a major roadblock for people new to crystal, or are the majority of errors very intuitive? the second thing is that according to the site crystal is in alpha and making breaking changes sometimes. how often do you have to refactor after an update and how difficult has it been to spot and fix that something is broken by an upgrade? Very interested in using it myself but can't bring myself to commit an app to it.

i actually think it's a good example for just that reason. Ruby will automatically use those big number types on production applications as well as the fibonacci application, so it's demonstrating that difference and the effect that it has.

Nothing in Javascript can ever be completely type safe right now. For example, you compile your TS code and it compiles without error, but you pull a JSON object from the server and pass it into a function which is expecting the argument to implement a certain interface. The problem is the interface is dropped in compilation and there's no type checking at run-time, so there's no way for Typescript to know that the program will be type safe at run-time.

Yeah I was just using createClass as an example of a feature that's not strictly necessary and could be removed to slim up the library. Thanks for responding! Any idea when you will be trimming stuff like that out? Do you think you will you ever remove mixins?

The "afraid of the security practices" was more of a joke than an actual serious jab. But I do still hold that site-wide TLS should be default by all major websites at this point in time.

Can I ask you why you say it would be too high for NYT to afford it, when many companies with significantly more traffic have site-wide TLS?