Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I built a fast JavaScript framework

medium.com

Post reply on HN
Print view View original

11–20 of 68 posts

Re: How I built a fast JavaScript framework

#11

Post by murukesh_s »

ng12 wrote: post #7
dgllghr wrote: post #2

I'm not primarily a Javascript developer, but I seem to remember that attaching event listeners to Object fields and modifying the DOM in event handlers is how Javascript development was done 5-10 years ago. Am I missing something? Are we going full circle?

Yup. I find that most cases of "JavaScript fatigue" are really cases of "I want tools custom tailored to my use case, but don't want to do the legwork to figure out what they are". The only thing wrong with jQuery is that it's perfectly fine until it isn't. Conversely, if you'll never need React's power you don't need it's complexity either.

React's (or other SPA frameworks like Vue's) complexity is much higher than it should have is probably because of the tooling (Babel, Webpack, NPM etc) and additional build process required even for a simple hello world app. That coupled with the rapid revision of the underlying ECMAScript standard and the race by developers and framework authors to adopt them causing further chaos.

Another issue was the rapid deprecation of age old JQuery plugins and the lack of equivalent plugins in the React landscape causing confusion whether you should build it yourself or not etc. I had hoped WebComponents somehow got standardized as the underlying architecture for SPAs, just so that the plugin/widgets wont get fragmented further, but it looks like it wont be happening anytime soon.

Re: How I built a fast JavaScript framework

#12

Post by RobLach »

meuk wrote: post #5
dgllghr wrote: post #2

I'm not primarily a Javascript developer, but I seem to remember that attaching event listeners to Object fields and modifying the DOM in event handlers is how Javascript development was done 5-10 years ago. Am I missing something? Are we going full circle?

Dunno, but it wouldn't surprise me. The resemblence between tables and flexboxes is also quite funny. We took 20 years from declaring the structure of table-like markup in a table to declaring it in CSS with a flexbox. Cool, but things like this have a marginal positive effect for developers, at the cost of having to learn yet another thing, and making it harder and harder to make a reasonable webpage.

Wait till you take a look at CSS grid

https://css-tricks.com/snippets/css/complete-guide-grid/

Re: How I built a fast JavaScript framework

#13

Post by [deleted] »

dgllghr wrote: post #2

I'm not primarily a Javascript developer, but I seem to remember that attaching event listeners to Object fields and modifying the DOM in event handlers is how Javascript development was done 5-10 years ago. Am I missing something? Are we going full circle?

[deleted]

Re: How I built a fast JavaScript framework

#15

Post by philipodonnell »

ng12 wrote: post #7
dgllghr wrote: post #2

I'm not primarily a Javascript developer, but I seem to remember that attaching event listeners to Object fields and modifying the DOM in event handlers is how Javascript development was done 5-10 years ago. Am I missing something? Are we going full circle?

Yup. I find that most cases of "JavaScript fatigue" are really cases of "I want tools custom tailored to my use case, but don't want to do the legwork to figure out what they are". The only thing wrong with jQuery is that it's perfectly fine until it isn't. Conversely, if you'll never need React's power you don't need it's complexity either.

> "I want tools custom tailored to my use case, but don't want to do the legwork to figure out what they are"

I feel this quite often. It doesn't help that the tools move so quickly that once you develop a kind of gut feel for what frameworks work in what situations its already changed and you get a bunch of "lol [X] was 2 years ago we're all on [Y] now".

Re: How I built a fast JavaScript framework

#16

Post by evmar »

I am often frustrated in this ecosystem by how people build things without any clear conceptual model, and then they document them by saying "it is so fast, it just works like magic". It is impossible to compare two approaches because there are no facts available to compare them on.

Like for this one from a peek at the source code it appears to try to parse JavaScript at runtime using regexes (https://github.com/radi-js/radi/blob/master/src/index.js#L4) which is great for demoware and not at all something I'd want to use in production, but that is not mentioned anywhere in the site or blog post.

I don't mean to just dump on this project in particular, which could just be a fun toy side project for the author, because this problem is endemic. (But then why go to all the effort to make all the marketing materials for it without actually writing any docs?)

Re: How I built a fast JavaScript framework

#18

Post by fwilliams »

I'm not a frontend developer and don't know really know JavaScript frameworks. That said, it seems like something very well established like React would choose to have a virtual DOM for a good reason.

Surely there must be some tradeoffs that the author makes for his design to get better performance. Could somebody explain the cost/benefit of doing things one way versus the other?

Re: How I built a fast JavaScript framework

#19

Post by joebo »

This looks similar in many ways to mithril[1] -- somewhat similar api - mount, view, r("input") vs m("input"). The counter example[2] looks similar[3] I'd be interested in seeing comparisons between the two.

[1] https://mithril.js.org/

[2] https://github.com/MithrilJS/mithril.js/blob/5956314e3655a3c...

[3] https://github.com/radi-js/radi/blob/master/examples/counter...

Re: How I built a fast JavaScript framework

#20

Post by expertentipp »

RobLach wrote: post #12
meuk wrote: post #5

Earlier quoted context omitted.

Dunno, but it wouldn't surprise me. The resemblence between tables and flexboxes is also quite funny. We took 20 years from declaring the structure of table-like markup in a table to declaring it in CSS with a flexbox. Cool, but things like this have a marginal positive effect for developers, at the cost of having to learn yet another thing, and making it harder and harder to make a reasonable webpage.

Wait till you take a look at CSS grid https://css-tricks.com/snippets/css/complete-guide-grid/

Basically a table but instead of HTML elements, using CSS properties? I loathe how "let's move the concept from one separation layer into another one, or better yet - let's mix the concepts together in the same separation layer" is becoming the next big thing recently.
Post reply on HN