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

JavaScript Views, the Hard Way – A Pattern for Writing UI

github.com

Post reply on HN
Print view View original

101–110 of 141 posts

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#101

Post by atum47 »

hu3 wrote: post #59
atum47 wrote: post #4

On my first official job after college I was working on making a web version of a Delphi software. The team was already on their third rewrite of the front end cause they had to change frameworks. I made the cass that we should write our own framework, so I prototyped FOS (the components I use on my website) to prove my point. The team (a bunch of mostly Delphi programmers) did not like my suggestion. Anyways, soon a…

You might want to look at something like morph Dom to keep input focus when you have to re-render the form, for example.

Since the user decides what happens when the state gets updated its up to them to address that. For me, I usually avoid re-renders when possible, I rather update the property associated with the state.

Have you faced any scenarios where that's needed? I'm curious.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#102

Post by efortis »

I use a helper similar to React.createElement.

  const state = { count: 0 }

  const init = () => document.body.replaceChildren(App())
  init()
  
  function App() {
    return (
      h('div', null,
        h('output', null,  `Counter: ${state.count}`),
        h(IncrementButton, { incrementBy: 2 })))
  }
  
  function IncrementButton({ incrementBy }) {
    return (
      h('button', {
        className: 'IncrementButton',
        onClick() { 
          state.count += incrementBy
          init()
        }
      }, 'Increment'))
  }
  

  function h(elem, props = null, ...children) {
    if (typeof elem === 'function')
      return elem(props)
  
    const node = document.createElement(elem)
    if (props)
      for (const [key, value] of Object.entries(props))
        if (key === 'ref')
          value.current = node
    else if (key.startsWith('on'))
      node.addEventListener(key.replace(/^on/, '').toLowerCase(), value)
    else if (key === 'style')
      Object.assign(node.style, value)
    else if (key in node)
      node[key] = value
    else
      node.setAttribute(key, value)
    node.append(...children.flat().filter(Boolean))
    return node
  }
Working example of a dashboard for a mock server: https://github.com/ericfortis/mockaton/blob/main/src/Dashboa...

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#103

Post by atum47 »

npodbielski wrote: post #58
atum47 wrote: post #4

On my first official job after college I was working on making a web version of a Delphi software. The team was already on their third rewrite of the front end cause they had to change frameworks. I made the cass that we should write our own framework, so I prototyped FOS (the components I use on my website) to prove my point. The team (a bunch of mostly Delphi programmers) did not like my suggestion. Anyways, soon a…

I dont know... I kind of like diffrent look of HTML and JS. At least you know what is what. In tiny evrything looks like JS and you actually have to read it to know what is what. Also what if someone will define span variable? Does it override the span HTML component function? Otherwise looks like nice.

    In tiny evrything looks like JS and you actually have to read it to know what is what
You don't, actually. If in HTML you write in tiny you write select(option())

    Also what if someone will define span variable?
I'm guilty of that myself. Tried to name a variable input when there's already a function with that name. It forces me to come up with better descriptive names. I could've wrapped those functions inside namespace like tiny.input() but I like the simplicity of it as is.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#104

Post by simonw »

efortis wrote: post #102

I use a helper similar to React.createElement. const state = { count: 0 } const init = () => document.body.replaceChildren(App()) init() function App() { return ( h('div', null, h('output', null, `Counter: ${state.count}`), h(IncrementButton, { incrementBy: 2 }))) } function IncrementButton({ incrementBy }) { return ( h('button', { className: 'IncrementButton', onClick() { state.count += incrementBy init() } }, 'Incr…

That looks like it replaces the entire document every time state changes. How's the performance of that?

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#105

Post by WickyNilliams »

simonw wrote: post #104
efortis wrote: post #102

I use a helper similar to React.createElement. const state = { count: 0 } const init = () => document.body.replaceChildren(App()) init() function App() { return ( h('div', null, h('output', null, `Counter: ${state.count}`), h(IncrementButton, { incrementBy: 2 }))) } function IncrementButton({ incrementBy }) { return ( h('button', { className: 'IncrementButton', onClick() { state.count += incrementBy init() } }, 'Incr…

That looks like it replaces the entire document every time state changes. How's the performance of that?

Even if performance is fine, the big usability issue is that it will blow away focus, cursor position etc every render. Gets very painful for keyboard use, and of course is a fatal accessibility flaw

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#106

Post by efortis »

WickyNilliams wrote: post #105
simonw wrote: post #104

Earlier quoted context omitted.

That looks like it replaces the entire document every time state changes. How's the performance of that?

Even if performance is fine, the big usability issue is that it will blow away focus, cursor position etc every render. Gets very painful for keyboard use, and of course is a fatal accessibility flaw

yes, that’s the downside, focus is lost on init()

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#107

Post by edflsafoiewq »

atoav wrote: post #39

I program for roughly two decades now and I never got warm with frontend frameworks. Maybe I am just a backend guy, but that can't be it since I am better in vanilla JS, CSS and HTML than most frontend people I have ever met. I just never understood why the overhead of those frameworks was worth it. Maybe that is because I am so strong with backends that I think most security-relevant interactions have to go through…

The basic problem is when some piece of state changes, all the UI that depends on that state needs to be updated. The simple solution presented in the link is to write update functions that do the correct update for everything, but as the dependency graph becomes large and keeps changing during development, these becomes very hard to maintain or even check for correctness. Also the amount of code grows with the number of possible updates.

Reactive view libraries basically generate the updates for you (either from VDOM diffing, or observables/dependency tracking). This removes the entire problem of incorrect update functions and the code size for updates is now constant (just the size of the library).

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#108

Post by WickyNilliams »

efortis wrote: post #106
WickyNilliams wrote: post #105

Earlier quoted context omitted.

Even if performance is fine, the big usability issue is that it will blow away focus, cursor position etc every render. Gets very painful for keyboard use, and of course is a fatal accessibility flaw

yes, that’s the downside, focus is lost on init()

Really wish the browser gave us better APIs for updating the DOM. Creation is extremely easy, but after that you either have to invent some reconciliation system or stick with imperative updates

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#109

Post by _heimdall »

nonethewiser wrote: post #100
_heimdall wrote: post #71

Earlier quoted context omitted.

Any code base lives or dies by how well it defines and then sticks to conventions. We can enforce it in different ways, or outsource the defining of convention to other tools and libraries, but we still have to use them consistently in the codebase. I think the OP here is basically proposing that the developer should be directly responsible for the conventions used. IMO that's not a bad thing, yes it means developers…

Using a framework like react constrains developers in a different way. React isnt simply a convention like the linked example.

I see it differently there, react (any framework) is simply convention built into shared libraries and enforced through tooling.

React is a particularly interesting one because it is still flexible enough that there is still a lot of reliance on developers actively sticking to the conventions recommended.

Re: JavaScript Views, the Hard Way – A Pattern for Writing UI

#110

Post by only-one1701 »

epolanski wrote: post #73

I have been writing recently an application in plain "vanilla" TypeScript with vite, no rendering libraries, just old-style DOM manipulation and I have to say I more and more question front end "best" practices. I can't conclude it scales, whatever it means, but I can conclude that there are huge benefits performance-wise, it's fun, teaches you a lot, debugging is simple, understanding the architecture is trivial, yo…

I get what you’re saying but people still write SPAs
Post reply on HN