Live data from Hacker News

Why Vanilla JavaScript

guseyn.com

141–150 of 176 posts

Re: Why Vanilla JavaScript

#141

Earlier quoted context omitted.

On application startup I assemble together the various front end files I need and store this in memory as a string. When the server sees a request for the desired page I respond with the desired string. Since I am not handcuffed by some giant framework I have maximum flexibility to do what makes sense.

> On application startup I assemble together the various front end files I need and store this in memory as a string. So in other words, you created your own bundler? Node isn't actually doing the work for you on the front-end.

Again, I never said Node is did anything for the front end.

Re: Why Vanilla JavaScript

#142
post #72
post #67

Earlier quoted context omitted.

Not everyone is building complex UIs like google sheets. Most people are building static pages with a sprinkle of interactivity, or maybe form pages for doing CRUD.

It starts as simple crud, but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere. O, but not when this checked, etc. Having a reactive framework when this happens is very much needed to keep all these effects working without a lot of vanilla JS. This can be solved later, but is a lot harder when you have an entire application that needs to bee kept wo…

> but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere

  function initWidget(root){
    // Or a bunch of calls to document.createElement, whatever you want.
    const inp = root.querySelector('.input');
    const check = root.querySelector('.check');

    function update(){
      inp.style.display = check.checked ? 'none' : 'block';
    }
    check.onchange = update;
  }
> O, but not when this checked, etc.

  function initWidget(root){
    // Or a bunch of calls to document.createElement, whatever you want.
    const inp = root.querySelector('.input');
    const check = root.querySelector('.check');
    const check2 = root.querySelector('.check2');

    function update(){
      inp.style.display = check.checked && !check2.checked ? 'none' : 'block';
    }
    check.onchange = update;
    check2.onchange = update;
  }
Compare to React:

  function Widget(){
    const [check1, setCheck1] = useState(false);
    const [check2, setCheck2] = useState(false);

    return 
       setCheck1(e.target.checked)}/>
       setCheck2(e.target.checked)}/>
      {check1 && !check2 && }
    ;
  }
Compare to Svelte:

  
    let check1 = $state(false);
    let check2 = $state(false);
  

  
  
  {#if check1 && !check2}
    
  {/if}
IME almost none of the complexity in any of the web applications I've worked with has been mitigated by the front-end framework in use. You still need to write the code to do the thing, whatever that thing is. You might as well write it in the framework that gives you the smallest bundle size and the best possible backwards compatibility, and that's vanilla JS + the standard web APIs.

Re: Why Vanilla JavaScript

#143
post #72

Earlier quoted context omitted.

It starts as simple crud, but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere. O, but not when this checked, etc. Having a reactive framework when this happens is very much needed to keep all these effects working without a lot of vanilla JS. This can be solved later, but is a lot harder when you have an entire application that needs to bee kept wo…

> but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere function initWidget(root){ // Or a bunch of calls to document.createElement, whatever you want. const inp = root.querySelector('.input'); const check = root.querySelector('.check'); function update(){ inp.style.display = check.checked ? 'none' : 'block'; } check.onchange = update; } > O, but not…

I'm not reading the code on HN but I do second this. After implementing a enterprise level production app by myself months ago with vanilla typescript, I find it's much easier to think the vanilla way than adapting to React or things similar. Before this project I work with React for years and never looked the other way. The reason I chose vanilla typescript over React is for performance as the app requires tons of resources and I want to keep it minimal without the performance punishment, but ended with a much better experience for UI development.

You don't need to remember how to properly line up useState/useEffect/useCallback and all.

You could just insert any simple state object and be ok with it, or insert a well-known state management library and it still works the same way.

For UI libraries they almost always have a vanilla option, and even better, if you are not working with google sheet level of stuff, vanilla element management is much much easier to work with.

And no need to talk about the style frameworks, they always work the vanilla way.

With some default vite configuration, nothing you need to worry anymore and the framework level stuff are simple and easy to understand and is totally manageable.

Re: Why Vanilla JavaScript

#144
post #68

Earlier quoted context omitted.

Presumably Node is the server (back end), and when the browser requests a TS file, Node is stripping the types before serving it to the browser.

That presumption is wrong, and doesn't quite make sense if you think about it.

Why doesn't it make sense? I actually do exactly this in my own setup, but with golang instead of Node.

Re: Why Vanilla JavaScript

#145

Earlier quoted context omitted.

> On application startup I assemble together the various front end files I need and store this in memory as a string. So in other words, you created your own bundler? Node isn't actually doing the work for you on the front-end.

Again, I never said Node is did anything for the front end.

Again, yes you explicitly did:

> I just write my code and then point node at the main file, and this even includes front-end code for the browser.

It sounds like you're just making stuff up.

Re: Why Vanilla JavaScript

#146

Earlier quoted context omitted.

When the user changes a value in the UI, the data must reflect the change. When a value changes in the data, the UI must reflect the change. That’s “binding.” What’s the idiomatic way to solve this automatically?

I use WebSockets. If the user changes a value you have to send that changed value forward. If the value changes outside the UI you have to send it into the UI.

What does the binding look like in source code?

Do we hand-code every UI field with the code that updates the local model and then transmits it to the backend?

Or is there a way to make the boilerplate as small as possible, relying on one bit of code to handle synchronization between UI, local model, and server?

“Using WebSockets” doesn’t bind an interface element to its source of truth; it’s just the chosen transport to move the data. I’ll be sticking with a RESTy interface. But that doesn’t matter because the question is how is the binding implemented so that fewer mistakes are made synchronizing the data?

Hand coding every field’s binding logic is going to be error-prone.

Re: Why Vanilla JavaScript

#147

I use Svelte 5 (without SvelteKit) for my SPA's, after doing my first SPA in vanilla JS. Then I discovered Svelte. Svelte is very close to the platform and still solves a lot of problems: for reactivity, modularity and CSS cascading (and in version 5 it is not too "magical"). A lot of the critique of frameworks in this article does not apply to Svelte.

Svelte needs a build step, and with the introduction of runes for reactive state it's not that different from the rest of the crop (solid, react, vue).

Re: Why Vanilla JavaScript

#148
post #115

Earlier quoted context omitted.

And it wasn't composable, state was kept in the DOM. Even with higher level libs like backbone we didn't have a component-oriented way like now. Each component had to manually manage all of its child components.

It composes to one level. Each is a component. Is that good enough for your application? For many, it is.

Really sorry to have to say this, but I feel like I'm getting underpaid for the work that I do if people make a living clobbering together input elements and calling it web development.

Re: Why Vanilla JavaScript

#149
post #60

Did I misunderstand or was that whole rant just to establish that, actually, we do need super tiny frameworks for the front end, but they're super tiny so it's not a big deal and they're not bad like React?

We don't need things taking control from us. Or dictating the terms for manipulating an already defined interface. If that means you have to make a small thing that is designed to do just the task at hand but to do it well, I am all for it. I think the only frameworks that I have encountered that I felt were worth using were server side things like express where they had a very specific task to do and could isolate a…

It's not terms, it's structure. You all seem to be fighting calculus and saying knowing addition and multiplication is enough. I'm reminded of friends refusing to learn chords on guitar and trying to invent their own musicality so they are not constrained by music theory.

Re: Why Vanilla JavaScript

#150
post #10

Did anyone else notice the pattern that ever since the LLMs got popular the "I hate javascript" kind of posts or comments have decreased? It could be attributed also to typescript dominance of course, since people don't use plain js anymore. As for the blog post, I agree, I also implemented my own js framework when I code in vanilla js and it works fine. The problem is not inventing frameworks, the problem is that ev…

I think the complaints attenuated in the last in the last 10-15 years because javascript itself became a much better language. Things really started to change with ES5. The introduction of let / const, modules, async, .?, template strings, etc. transformed it from an ugly kludge to a really capable language. Of course, if you use old syntax you still deal with weird scoping and casting, but you don't have to any more…

Everybody sort of settled on React and Node, or at least on the reactive/declarative component paradigm. React was introduced over 10 years ago now, it's a dinosaur.
Post reply on HN