The title is pretty ridiculous. There are legitimate reasons why people use frameworks like React and Angular. Things like Zam and jQuery could be fine for small projects, but there's no way this is a replacement for frameworks that have build systems, virtual DOMs, etc. Maybe I'm taking the cheeky headline too seriously?
Ditch React. Ditch Angular. Go Vanilla with Zam
11–20 of 29 posts
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#12I'd recommend reading the code[0], it's pretty short, and can help as a good introduction if you want to get a bit more into VanillaJS.
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#13Genuine question: in 2017, why would you create a JS framework that didn't use futures? eg in the documentation, ".fadeIn(selector, time)" - "Returns nothing". Why not return a future that resolves when the fade completes?
From a performance stand point -- does it really matter? You are right. fadeIn and fadeOut should have some optional callback for completion.
Yes, it absolutely does matter. Chaining promises together, running them in parallel with Promise.all, and the abortable-promise pattern, make developing (and especially debugging!) much much easier than having to deal with callback hell.
zam.fadeIn(el, duration)
.then(zam.ajax(url))
.then(response => response.json())
.then(json => el.innerHTML = json.results[2].message)
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#14The title is pretty ridiculous. There are legitimate reasons why people use frameworks like React and Angular. Things like Zam and jQuery could be fine for small projects, but there's no way this is a replacement for frameworks that have build systems, virtual DOMs, etc. Maybe I'm taking the cheeky headline too seriously?
I totally agree with you.
I think this guy states it pretty well when it comes to React vs. VanillaJS.
There is no doubt that React.js is a great approach towards managing state in the view layer of a browser application. However, from my own limited experience as well as just comparing raw numbers from time spent in rendering to the amount of memory consumed, there is a clear price to pay in any convenience gained from a library like React. From a pure performance perspective it does appear there may be some merit in evaluating a pure JS DOM approach to a given problem. However, from the perspective of managing a team of developers who want to deliver a large amount of maintainable code, there can be a clear advantage to leveraging libraries and frameworks such as React, Polymer, Angular, etc.
https://objectpartners.com/2015/11/19/comparing-react-js-per...
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#15Good work. It seems like a working library. And it's fast at the things it chooses to do. But ...
1. Ditching React and Angular for this is like ditching Photoshop for MS Paint.
2. Someone using Zam isn't "going vanilla JS", they are going Zam JS.
3. Going into a performance arms race with jQuery is not a one man job. It would be nice to know how you achieve such performance gains. What tradeoffs are involved? Like, is it faster because it uses native dom selection functions? If so, then this is just an extra layer of indirection with no added value over something like a polyfill. If that's not the case, what kind of groundbreaking work did you do here to achieve the impressive looking benchmarks on the Github page?
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#16Earlier quoted context omitted.
From a performance stand point -- does it really matter? You are right. fadeIn and fadeOut should have some optional callback for completion.
Yes, it absolutely does matter. Chaining promises together, running them in parallel with Promise.all, and the abortable-promise pattern, make developing (and especially debugging!) much much easier than having to deal with callback hell. zam.fadeIn(el, duration) .then(zam.ajax(url)) .then(response => response.json()) .then(json => el.innerHTML = json.results[2].message) This code is nearly self-documenting, is easie…
I saw this "then-heavy" style in many places, but I never really understood: I find perfectly fine to make "fadeIn" return a promise, or an ajax call, and find "the right way" to join them with then / when / Promise.all etc.
But what is the meaning to add a lambda function as "response => response.json()" in a then? why a different lambda "json => el.innerHTML = json.results[2].message" ?
isn't it a "gratuitous" use of a then-able object? I found more readable to have a (sincronous, debuggable, "old-style") function without the need to split in one thousand one line lambdas.
moreover, my python background makes me looks as "ugly" the last one, as it's a lambda function with an assignement, and not a simple expression.
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#17The title is pretty ridiculous. There are legitimate reasons why people use frameworks like React and Angular. Things like Zam and jQuery could be fine for small projects, but there's no way this is a replacement for frameworks that have build systems, virtual DOMs, etc. Maybe I'm taking the cheeky headline too seriously?
I came precisely to post this. Not only are projects like React necessary, but I'd argue they are handicapped by their very language. ScalaJS and State Monads ftw.
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#18The title is pretty ridiculous. There are legitimate reasons why people use frameworks like React and Angular. Things like Zam and jQuery could be fine for small projects, but there's no way this is a replacement for frameworks that have build systems, virtual DOMs, etc. Maybe I'm taking the cheeky headline too seriously?
[deleted]
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#19Earlier quoted context omitted.
Yes, it absolutely does matter. Chaining promises together, running them in parallel with Promise.all, and the abortable-promise pattern, make developing (and especially debugging!) much much easier than having to deal with callback hell. zam.fadeIn(el, duration) .then(zam.ajax(url)) .then(response => response.json()) .then(json => el.innerHTML = json.results[2].message) This code is nearly self-documenting, is easie…
I saw this "then-heavy" style in many places, but I never really understood: I find perfectly fine to make "fadeIn" return a promise, or an ajax call, and find "the right way" to join them with then / when / Promise.all etc. But what is the meaning to add a lambda function as "response => response.json()" in a then? why a different lambda "json => el.innerHTML = json.results[2].message" ? isn't it a "gratuitous" use…
Not sure what you mean but response.json() is promise that can fail with parse/read error. It's where error handling should happen making it imperative doesn't solve anything
Re: Ditch React. Ditch Angular. Go Vanilla with Zam
#20A new JS framework! Finally!
Seriously though, this looks interesting, but the "ditch React/Angular" claims are silly, there's gotta be a better way to differentiate yourself and convey your value prop.