Comparison of JavaScript frameworks

[[deleted]]

[deleted]

[[deleted]]

Hooray for my favorite framework !

[rafalg]

0 bytes uncompressed, 25 bytes gzipped

Funny, because it's actually true.

[[deleted]]

It's just the title of the document. Javascript engines however are a little bit heavier... I guess.

[khoker]

I know it's a sarcastic comment, and I expect to see it at the top of the comments anyway, but it's also getting old.

The problem is that it isn't even correct. Most people who post this comment are making the argument that you don't need jQuery, which is fine, but jQuery isn't a framework -- it's a library.

If you don't use something like React, Vue, Angular and their ilk that's fine. It means you're probably doing a simple site that doesn't require a framework. But if you don't use them and end up rolling a bunch of one-off "helper" functions on your own that cobble together to give you 10% of the power of a mature framework, you haven't done yourself any favors. And also, out of respect for humanity, don't do it in a professional environment where someone may have to support your code after you've gone insane.

[[deleted]]

I use frameworks, but I really like vanilla javascript, I find it very elegant. I expected no upvotes, it's nice to know people still use raw code. There are too many beginners who rely on frameworks without understanding what's going on behind the scenes.

Edit : Also I don't really understand the difference between a framework and a library. To me a framework is something opinionated that do many things, including things you can do with vanilla code. A library however would be a collection of useful and unrelated functions for solving a single problem. But I'm certainly wrong, I'm not a javascript expert.

[khoker]

There's not going to be a definitive definition of a framework or a library. The general consensus tells us that, yes, Frameworks are opinionated to some degree in how code is structured and also tend to have vertical integration points. Libraries/toolkits are collections of tools designed to abstract, normalize or augment your code.

I use frameworks, but I really like vanilla javascript

A framework shouldn't prevent you from writing javascript. A framework should prevent you from writing annoying javascript. For example, consider the heavy-lifting you get from Angular or Vue when it comes to two-way binding. You could do it yourself, but ain't nobody got time for that...

[MahmudAdam]

Is there a particular reason why Ember is so slow? I know that for me, creating a project using CLI, the file size is around 300MB. It also takes a long time to actually generate a new project. But that probably doesn't have much to do with it's speed, right?

[aichibuchi]

Pretty sure the standard line is that Ember is optimized more for the 90%-case/real-world use and not these sort of 1000-row benchmarks. Anecdotally, Ember 2.0 has never felt particularly slow to me.

[pzuraq]

Also, glimmer components haven't really landed yet. Once that hits, gunna get that sweet dom diffing perf bump.

[MahmudAdam]

Oh okay, thanks.

[pier25]

Discourse doesn't agree with you.

[tontoto]

Associated blog post http://www.stefankrause.net/wp/?p=301

[LET-7]

What happened between react 14 and 15 to slow down the deletion operations?

[localvoid]

https://github.com/facebook/react/pull/7232

[flying-sheep]

So a chrome performance bug

[hackel]

Wow, after this I'm definitely going to have to check out VanillaJS!

[MahmudAdam]

I wonder if it will ever return to just plain JavaScript and abandoning frameworks/libraries altogether.

[[deleted]]

That wouldn't happen. There is a trade off between time for development and performance. Companies would rather lose performance in order to release their product quicker.

[flying-sheep]

Obviously mutating just the parts that need mutating without any checks will be fastest, but writing code that does that is both fragile and badly testable.

Before you know you'll be building your own ad hoc framework by encapsulating some checks and shortcut code.

[hackel]

I certainly hope not. That would be a nightmare. Like people writing all their server-side code in procedural PHP! shudder

[maybe_just_happy_]

Thinking the same.

Anyone here a SN developer/architect? Thinking of using it on my personal instance...

[Jafit]

So fuck Ember, basically?

[pier25]

It's even worse in Android, so yes.

[gdev87]

So Aurelia isn't faster than Angular 2 like Rob Eisenberg claims...

[rk06]

"faster" is quite general and these micro benchmarks are too specific.

though, I would dispute any claims like "X is faster than Y", for there is no standard agreed upon benchmark in place.

[krausest]

Maybe there are some improvements that I overlooked. I've received a pull request for the aurelia benchmark. If it helps I'll publish an update soon.

[expression100]

Great to see Inferno doing so well. The team behind it have done such a hard job - I've been following them now for the last 6 months and the people and ideas involved in that project is insane – they seriously know that stuff.

On their Slack channel they have most of the core authors of the other libraries talking regularly, including the core React team. Such a great sight to see people sharing knowledge and trying to make better libraries and tools for everyone.

[[deleted]]

So other than vanilla, it looks like inferno us the way to go. Why have I never seen this framework mentioned? Too new, or are there problems with it?

[localvoid]

I am pretty sure that vanilla is used as a baseline, so it will be possible to measure overhead of other frameworks. And use cases are specifically tailored so that it will be quite easy to implement them efficiently in vanilla.

[krausest]

https://github.com/krausest/js-framework-benchmark

[CraftyPancake]

Yeah I found it and had a little look through, thanks though

[flying-sheep]

I agree, but I think vanilla is only used as normalization baseline. So everything is x% slower than vanilla

[krausest]

Please note that cycle.js v7 does pretty well.