4 ms·

Ditch React. Ditch Angular. Go Vanilla with Zam

17 points by zamjs 9y ago

pspeter3 9y ago
Why are the methods you provide better than the existing document methods? Also why is the AJAX method better than fetch?
- zamjs 9y ago
  Zam's methods are overall document methods. For example: .each() and .addStyle() Things get a little more complex with some of the methods though. For example: .css() Fetch is only faster on certain browsers. I'm thinking about incorporating it in the future.
jarsin 9y ago
So this is vanilla jquery? :)
- bigdubs 9y ago
  Eventually everything in javascript will be reinvented by hipster hackers.
  - catacombs 9y ago
    Who are these hipster hackers?
- deleted 9y ago
  [deleted]
koube 9y ago
It seems like your examples page is broken on firefox quantum 57.0.1 (64-bit) for MacOS. It shows up halfway off the screen to the left side for me. https://i.imgur.com/v3IHIoV.png https://i.imgur.com/v3IHIoV.png
- zamjs 9y ago
  Thanks for the catch!! Fixed it. I had to explicitly set "left: 0"
mark242 9y ago
Genuine 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?
- zamjs 9y ago
  From a performance stand point -- does it really matter? You are right. fadeIn and fadeOut should have some optional callback for completion.
  - mark242 9y ago
    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 easier for a transpiler to handle, and doesn't scream "refactor me!" right after you've deployed your app.
    - _ZeD_ 9y ago
      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.
      - fleetfox 9y ago
        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
ravenstine 9y ago
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?
- fingerbibing 9y ago
  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-performance-vs-native-dom/ https://objectpartners.com/2015/11/19/comparing-react-js-per...
  - mercer 9y ago
    Have you looked into Preact? Aside from the convenience of being (almost) a drop-in replacement for React, I recall it was also supposed to be much more performant. While I'm sure pure JS DOM could eke out even better performance, it's possible that compared to Preact (or some other fast VDOM implementation like mithril), the benefits are not worth it anymore. (I'm not sure of any of this though, so I'd love to hear others, who have kicked the tires, weigh in.
- vippy 9y ago
  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.
- deleted 9y ago
Zyst 9y ago
I'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. 0: https://github.com/roecrew/zam/blob/master/zam.js https://github.com/roecrew/zam/blob/master/zam.js
lopatin 9y ago
Good 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?
- zamjs 9y ago
  I see your points. "Like, is it faster because it uses native dom selection functions?" Yes, this library is fast because it's based around native dom functions. "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?" I'm not claiming there's anything "groundbreaking" about this library. I made it to encourage vanillajs development, which I believe to be important.
rayalez 9y ago
A 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.
borplk 9y ago
Silly title.
api_or_ipa 9y ago
When writing a framework, I always ask myself what is this doing that cannot easily be done with the native APIs?. Answering this question is easy for both Angular and React: in both cases they enforce conventions that make certain flavours of software development easier. What advantage does Zam have over using the regular DOM api? AFAICT, Zam doesn't introduce significant changes to the underlying paradigms so by Occham's Razor I have a hard time believing this additional framework will help me. On a side note, I'm not sure why everyone attacks React and Angular so much. Believe it or not, they work very well for their intended purpose. There will always be hacks in every community who chose bazookas to catch butterflies but it's a fallacy to attribute that to the framework itself. Both React and Angular, IMO, enforce concerns that scale super-linearly w.r.t. to project size: e.g. mutating a DOM element is fine if you're the only actor on the document but definitely doesn't work when n actors all depend on the same DOM node to broker a shared state.

17 points by zamjs 9y ago

Why are the methods you provide better than the existing document methods? Also why is the AJAX method better than fetch?

zamjs 9y ago
Zam's methods are overall document methods. For example: .each() and .addStyle() Things get a little more complex with some of the methods though. For example: .css() Fetch is only faster on certain browsers. I'm thinking about incorporating it in the future.

jarsin 9y ago

So this is vanilla jquery? :)

bigdubs 9y ago
Eventually everything in javascript will be reinvented by hipster hackers.
- catacombs 9y ago
  Who are these hipster hackers?
deleted 9y ago
[deleted]

koube 9y ago

It seems like your examples page is broken on firefox quantum 57.0.1 (64-bit) for MacOS. It shows up halfway off the screen to the left side for me. https://i.imgur.com/v3IHIoV.png https://i.imgur.com/v3IHIoV.png

zamjs 9y ago
Thanks for the catch!! Fixed it. I had to explicitly set "left: 0"

mark242 9y ago

Genuine 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?

zamjs 9y ago
From a performance stand point -- does it really matter? You are right. fadeIn and fadeOut should have some optional callback for completion.
- mark242 9y ago
  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 easier for a transpiler to handle, and doesn't scream "refactor me!" right after you've deployed your app.
  - _ZeD_ 9y ago
    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.
    - fleetfox 9y ago
      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

ravenstine 9y ago

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?

fingerbibing 9y ago
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-performance-vs-native-dom/ https://objectpartners.com/2015/11/19/comparing-react-js-per...
- mercer 9y ago
  Have you looked into Preact? Aside from the convenience of being (almost) a drop-in replacement for React, I recall it was also supposed to be much more performant. While I'm sure pure JS DOM could eke out even better performance, it's possible that compared to Preact (or some other fast VDOM implementation like mithril), the benefits are not worth it anymore. (I'm not sure of any of this though, so I'd love to hear others, who have kicked the tires, weigh in.
vippy 9y ago
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.
deleted 9y ago

Zyst 9y ago

I'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. 0: https://github.com/roecrew/zam/blob/master/zam.js https://github.com/roecrew/zam/blob/master/zam.js

lopatin 9y ago

Good 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?

zamjs 9y ago
I see your points. "Like, is it faster because it uses native dom selection functions?" Yes, this library is fast because it's based around native dom functions. "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?" I'm not claiming there's anything "groundbreaking" about this library. I made it to encourage vanillajs development, which I believe to be important.

rayalez 9y ago

A 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.

borplk 9y ago

Silly title.

api_or_ipa 9y ago

When writing a framework, I always ask myself what is this doing that cannot easily be done with the native APIs?. Answering this question is easy for both Angular and React: in both cases they enforce conventions that make certain flavours of software development easier. What advantage does Zam have over using the regular DOM api? AFAICT, Zam doesn't introduce significant changes to the underlying paradigms so by Occham's Razor I have a hard time believing this additional framework will help me. On a side note, I'm not sure why everyone attacks React and Angular so much. Believe it or not, they work very well for their intended purpose. There will always be hacks in every community who chose bazookas to catch butterflies but it's a fallacy to attribute that to the framework itself. Both React and Angular, IMO, enforce concerns that scale super-linearly w.r.t. to project size: e.g. mutating a DOM element is fine if you're the only actor on the document but definitely doesn't work when n actors all depend on the same DOM node to broker a shared state.