How I built a fast JavaScript framework • Hacker News Board

Re: How I built a fast JavaScript framework

#31

Post by ng12 » Wed, Mar 07, 2018, 5:30 PM UTC

murukesh_s wrote: post #11

ng12 wrote: post #7

Earlier quoted context omitted.

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 deprec…

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

I wouldn't frame it as excess complexity, I would frame it as power. My problem is not writing simple hello world apps, it's writing and maintaining very large production applications with 5 other developers. Two years ago I took a week to really learn the tooling stack and it's paid dividends ever since.

Re: How I built a fast JavaScript framework

#32

Post by Froyoh » Wed, Mar 07, 2018, 5:47 PM UTC

evmar wrote: post #16

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/rad…

Looks like the regex is only used to strip comments?

Re: How I built a fast JavaScript framework

#33

Post by olavgg » Wed, Mar 07, 2018, 5:54 PM UTC

ng12 wrote: post #31

murukesh_s wrote: post #11

Earlier quoted context omitted.

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 deprec…

> 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. I wouldn't frame it as excess complexity, I would frame it as power. My problem is not writing simple hello world apps, it's writing and maintaining very large production applications with 5 ot…

We are 10 developers just using vanilla Javascript here. No mess, and a joy to work with. We use good old design patterns like observer, proxy, composite and so on. We also use inheritance and template literals a lot.

The key is good documentation, having an onboard plan for new developers, keeping things stupid simple and stop being bleeding edge. We want our code base to just work, so we can focus more on new features and less on maintenance.

I'm planning on writing a deeper blog post this year about why and how we feel is a good structured simple way to do frontend development. I believe there are several frustrated frontend developers out there that just want to make their life easier but currently all the arguments they find just favor 'React'....

Our whole Javascript codebase is 50k + lines. But the clients only fetch what is needed.

Re: How I built a fast JavaScript framework

#34

Post by evmar » Wed, Mar 07, 2018, 6:08 PM UTC

Froyoh wrote: post #32

evmar wrote: post #16

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/rad…

Looks like the regex is only used to strip comments?

The line I linked to, sure. But under what conceptual model would a framework need logic to strip comments (an aspect of source text) at runtime? Follow it to its conclusion.

Re: How I built a fast JavaScript framework

#35

Post by iamleppert » Wed, Mar 07, 2018, 6:27 PM UTC

I recently did a project with morphdom (https://github.com/patrick-steele-idem/morphdom) using only ES6 template strings and a render loop that checked for changes to a global state object and patched a re-computed DOM string using morphdom. Couldn’t have been an easier and more pleasurable experience.

Re: How I built a fast JavaScript framework

#36

Post by pygy_ » Wed, Mar 07, 2018, 6:42 PM UTC

Froyoh wrote: post #32

evmar wrote: post #16

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/rad…

Looks like the regex is only used to strip comments?

https://github.com/radi-js/radi/blob/eace84e9b74c944b233f631...

It parses the source code of the view function at run time, matching parentheses, but ignoring whether those are present in strings or regexes. Likewise, the comment stripper will turn

    "/*whoops*/"

into the empty string...

In other words, the parser is buggy :-/

Re: How I built a fast JavaScript framework

#37

Post by [deleted] » Wed, Mar 07, 2018, 6:43 PM UTC

Whitespace wrote: post #17

They compared Radi to React Stack, not React Fiber. That's being sneaky. If you run the React Fiber demo, you'll see it's just as fast: https://claudiopro.github.io/react-fiber-vs-stack-demo/fiber...

[deleted]

Re: How I built a fast JavaScript framework

#38

Post by ng12 » Wed, Mar 07, 2018, 6:45 PM UTC

olavgg wrote: post #33

ng12 wrote: post #31

Earlier quoted context omitted.

> 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. I wouldn't frame it as excess complexity, I would frame it as power. My problem is not writing simple hello world apps, it's writing and maintaining very large production applications with 5 ot…

We are 10 developers just using vanilla Javascript here. No mess, and a joy to work with. We use good old design patterns like observer, proxy, composite and so on. We also use inheritance and template literals a lot. The key is good documentation, having an onboard plan for new developers, keeping things stupid simple and stop being bleeding edge. We want our code base to just work, so we can focus more on new featu…

> joy to work with

Color me skeptical. React is quite literally the only framework I've ever found to be enjoyable (and maintainable).

Re: How I built a fast JavaScript framework

#39

Post by exogen » Wed, Mar 07, 2018, 7:00 PM UTC

expertentipp wrote: post #20

RobLach wrote: post #12

Earlier quoted context omitted.

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.

CSS Grid does the opposite of what you claim – it fixes the mixing of concepts that previously tied HTML elements to their layout, not make it worse.

Re: How I built a fast JavaScript framework

#40

Post by amelius » Wed, Mar 07, 2018, 7:30 PM UTC

lhorie wrote: post #24

amelius wrote: post #21

Earlier quoted context omitted.

The problem with not using a virtual DOM is that you can't merge in changes to stateful DOM elements. For example, an INPUT field has state (its value, plus its scroll position). If you regenerate the INPUT field from scratch, you risk losing the state. In contrast, if you use a virtual DOM, the vdom mechanism can merge in any changes for you (the INPUT field will stay the object!) Of course, you can recreate DOM ele…

This isn't quite correct. Modern rendering libraries aren't going to recreate an input from scratch unless they absolutely have to, vdom or not. What's tricky about reconciling app state changes and dom state is dealing with things like cursor position if e.g. the input value change comes from a socket and the user had the input focused and the cursor in the middle of the text. But this has nothing to do with vdom

To prove you wrong, consider how DOM elements are created (remember in Surplus there are no virtual elements). Ignoring all dependency tracking, the code to show some text has to be (eventually) of the form

    x = document.createTextNode(v);

Now, consider the dependency v changes. The only option is to run the code above again, in its entirety. And thus, the DOM node corresponding to the text is new.

Of course, a smart library will ensure that the amount of nodes that has to be visited is at a minimum. But that doesn't mean DOM nodes don't get rebuilt from scratch.