Comment by tgflynn | Hacker News Reader

Comment by tgflynn | Hacker News Reader

Parent Full thread

> Ok, but surely you see the difference between this very simple/straightforward "demo app" and a real webapp? Something like Zillow, Facebook, Doordash, Spotify, etc.

Yes and no. What are those apps really doing that's fundamentally so much more complicated ? Obviously there's a lot more to their UI's and you'd need to be careful about doing full re-renders. I suspect anything that affects global page layout could become problematic. But I think it should be possible to predetermine the page layout (unless the viewport size changes, then you'd need to re-render everything, but that should be uncommon) and only re-render within div's of preset size.

> I looked at your code and you had to write your own render loop to accomplish this which would break down if you had interactive stuff that you were rendering out

You mean like generating forms/controls ?

I have some other code I'm working on that does that and also doesn't seem particularly hard. For example I'm working on a chrome extension with an options page that updates another page and the local storage as soon as a user changes an option setting.

> Yes and no. What are those apps really doing that's fundamentally so much more complicated ?

They have more views, more data, more data that needs to be kept in sync across multiple views. You cannot rerender (and inject/replace) every time the underlying data changes. It works up to a point but once you cross that rubicon it because very painful. I don't know how better to say this or explain it. I write webapps professionally and for side-projects, maintaining any of them in vanilla js would be a non-starter. I have even tried that for "smaller" webapps that "don't need a build step", it doesn't work. SCSS is vastly superior to CSS, TS is superior to JS, and templates that support things like `v-for="item of items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates with event handlers, loops spitting out html, and conditional rendering of blocks.

> You mean like generating forms/controls ?

Yes. Those things make this all more complicated. I've built exactly what you have in the past and at a certain point it falls down hard. There is a noticeable lag when you change data and go to re-render. If the user is focused on an input and you re-render they lose focus unless you make sure to reset the focus after the render. If you wanted to do something like "As the user types re-render an element to show what they typed" (think example/preview, or even something like putting the name you are typing into the UI as a header) it gets really gross really fast. So you might start having smaller render areas "I'll just re-render this 1 part" but that also gets complicated very quickly and at the end of the day you are just building a worse framework without the benefit of the community.

> You cannot rerender (and inject/replace) every time the underlying data changes.

OK, so how do the frameworks do it then ?

This is a good start:

https://reactjs.org/docs/faq-internals.html

https://reactjs.org/docs/reconciliation.html

Thanks.

They do pathing/differential rendering. They don't all do it the same way but one example is they build the DOM "in memory", render it out, and then when they re-render they compare they old/new html and inject only the diff. They also have built in things to make sure you don't lose focus when you add an attribute to the input (or change it in some way).

There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date.

Thanks for the insights though, I wasn't aware they were doing all of that.

> I prefer working with my own code... Every programmer prefers to work with their own code. This is the biggest dilemma, it boils down to a lot of "make/buy" decisions. Rule of thumb after 20+ years of experience : do not reinvent frameworks. The framework you are thinking of already exists, and, even when not perfect, solves a lot of problems you hadn't even thought of.

I disagree vehemently. Every time I reach for a JS framework, my fans spin and I get concerned that my notebook is going to take off to the moon.

Writing my own, or better yet, staying away from JS altogether, has resulted in more stable, maintainable and profitable software.

Then you exist as a very skilled and rare software developer. Or what's more likely is that your lens of software development and software maintenance is quite different to the majority of web developers.

Think about it, are you the one that maintains said code? If so, can you really call that maintainable (as in, reusable, expandable by others while you are on vacation)? If not, you are a very skilled framework maker. Then other people are using your framework and hence, not reinventing the wheel, which is my point.

> Mainly because I prefer working with my own code to working with other people's. Another advantage is reducing the amount of new information I have to learn (which with the whole vanilla HTML5 stack is already vast), but maybe I'm hopelessly out of date.

The problem here is - if you need to bring in other developers. Finding react/vue devs, or devs w/ htmx, alpinejs, etc - it's going to be super easy to onboard, a custom framework you built yourself - not so much. Maybe it's easy, maybe it isn't but you will have to train new devs who work on your stuff, where otherwise you could save time/money by not having to train on things, plus is your framework well tested using jest or other testing frameworks? There could be lots of bugs that some of the bigger more established frameworks have already worked out, and especially security issues.

Right now my favorite stack is laravel + alpinejs + livewire + filamentphp (admin dashboard) -- i can prottype in a week what used to take 3 months.

> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

You can even avoid a shadow DOM or vDOM entirely and differentially render using the DOM itself:

https://github.com/WebReflection/domdiff

https://github.com/WebReflection/uhtml

The JS framework benchmark shows these two are among the top performers.

I remember trying to do this with jQuery and localstorage, and was amazed it work, but so frustrated the many times it broke or caused issues. Built an entire shopping cart w/ a team in jQuery and localStorage as the store with some handlebar templates. In retrospect it was horrible code. This was in 2015 though, so react/vue were less wide spread and I was much more junior.

Now it's so much better/easier to use Vue, or react or even Svelte or the smaller similar stacks like alpine, htmx, etc that at least make state management easier than it ever was dealing with jQuery. the only thing jQuery had going for it was the ease of using selectors, honestly I think a jquery lite package that just has all the selector stuff would be nice, I sometimes forget all the document.getElementById stuff, but $('#id') is a much (imho) better syntax anyways. There probably already exists something like that - haven't looked but maybe I will later now that my interest is piqued.

I never used jquery since I never got very seriously into web development until recently but document.querySelector() seems to be about a nice a function for querying DOM elements as you could want.

> items"` or `v-if="condition"` or `@click="doTheThing"` are superior to HTML templates

The html syntax as a matter of taste is horrible, but that doesn't need a whole turing complete language to fix

I suspect some of the JS frameworks started with a set of JS functions, etc. to do things dynamically on a page. And it grew. And then someone comes by and says "hey we're building a new app, mind if we use that?". And it was cloned and morphed. And it grew. Maybe that repeated a bit, and then someone created a framework of generic tools.

Then this happened in multiple places. Or hackers didn't like how something worked so they came up with their own spin. I believe React came out of or is strongly influenced by FB, which makes sense - a Single Page App is the design and progressively loading more ads, ahh I mean content.

And here we are building client/server apps with a technology invented for document sharing.

There are 2 frameworks solving the "keep track of state" problem on the server and allowing for dynamic/reactive UI via web sockets instead of XHR: Ruby/Rails 7 and Elixir/Phoenix LiveView. They still use JS but you can limit it to client-side things and maintain state and validations on server.

Reply on news.ycombinator.com