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

Why Vanilla JavaScript

guseyn.com

Post reply on HN
Print view View original

131–140 of 176 posts

Re: Why Vanilla JavaScript

#131

Post by root_axis »

austin-cheney wrote: post #128
root_axis wrote: post #125

Earlier quoted context omitted.

You write all your code in TS - great. You run node with the TS support - great. That doesn't explain how your front-end TS code is transformed into JS. You seem to be suggesting that node does it automatically, but it doesn't. The explanation of your setup isn't adding up.

> That doesn't explain how your front-end TS code is transformed into JS. Node will do that at run time. Its automatic. Functions do not have to execute to receive this benefit. They just have to be imported. Ensure you are using a very recent version of Node.

Yes, but how does your http server deliver the imported code to the front-end? Are you using some type of streaming bundler that does real time builds? Something isn't making sense here.

Re: Why Vanilla JavaScript

#132

Post by andrew-dc »

pikeangler wrote: post #83

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.

My experience with Svelte has been similar. Svelte struck the right DX balance for me between helpful framework tools and features, but not far removed from vanilla JS, HTML, and CSS.

And sure, there is a build step. I have never felt like this was a problem with Svelte, but then I don't have experience working on a colossal Svelte app. Does it become one?

Re: Why Vanilla JavaScript

#133

Post by vsgherzi »

I can offer a slightly alternate prospective. At my current company we’re a small team that needs the frontend to stay stable with little changes for long periods of time. Our major react site has rotted due to us not keeping up with the Churn of the ecosystem. We don’t have a complex ui. We just need stability. Keeping up and managing a framework has been too much when we don’t have a dedicated frontend team.

Re: Why Vanilla JavaScript

#134

Post by austin-cheney »

root_axis wrote: post #131
austin-cheney wrote: post #128

Earlier quoted context omitted.

> That doesn't explain how your front-end TS code is transformed into JS. Node will do that at run time. Its automatic. Functions do not have to execute to receive this benefit. They just have to be imported. Ensure you are using a very recent version of Node.

Yes, but how does your http server deliver the imported code to the front-end? Are you using some type of streaming bundler that does real time builds? Something isn't making sense here.

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.

Re: Why Vanilla JavaScript

#135

Post by inigyou »

dsego wrote: post #115
not-a-llm wrote: post #106

Earlier quoted context omitted.

it can be faster, but is it correct? React was invented because jQuery style state management collapsed into unmanageable code past a certain size

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.

Re: Why Vanilla JavaScript

#136

Post by bluegatty »

chabska wrote: post #9
bluegatty wrote: post #3

Earlier quoted context omitted.

You can say that without being demeaning. These are random people acting in good faith. Also - sometimes it is actually useful to make a mini-thing instead of bringing in enterprise messes.

These people are perfectly fine with depicting React developers as corporate zombies that can't think for themselves. Good faith is bidirectional.

We can try to be a big magnanimous and rise above a tiny bit of 'English on the ball', let the small stuff slide.

Re: Why Vanilla JavaScript

#137

Post by jagged-chisel »

austin-cheney wrote: post #42
jagged-chisel wrote: post #16

What’s the Idiomatic Vanilla JavaScript way to bind data and UI in a web browser?

What are you really asking? You use data to populate content or inform your logic.

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?

Re: Why Vanilla JavaScript

#138

Post by RetroTechie »

swatcoder wrote: post #4
benoau wrote: post #2

Some good history of the JS ecosystem here but the underlying message is all the same, frameworks scale and provide structure but you don't need them. Very easy to agree up to this point. Author then elaborates in the absence of using a common-knowledge framework you can create some tighter solution that achieves just the part you need. This is "fun" programming, and the author is suitably impressed with themselves f…

We practice engineering. As engineers, we need to understand the realities of each project we take on. Those realities are not limited to the marketing bullet points we might apply to the imagined product someday, which is what early career folk might naively call "the requirements". Among the most critical realities to consider exist outside the product definition entirely, and have to do with the environment in whi…

> Sometimes (in fact: often), just doing the thing well with simple, clear, stable tools -- and nothing more -- is the right choice.

Stronger: that should be standard operating procedure. Unless there's a pressing need (if not absolute necessity) to do otherwise.

Re: Why Vanilla JavaScript

#139

Post by austin-cheney »

jagged-chisel wrote: post #137
austin-cheney wrote: post #42

Earlier quoted context omitted.

What are you really asking? You use data to populate content or inform your logic.

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.

Re: Why Vanilla JavaScript

#140

Post by root_axis »

austin-cheney wrote: post #134
root_axis wrote: post #131

Earlier quoted context omitted.

Yes, but how does your http server deliver the imported code to the front-end? Are you using some type of streaming bundler that does real time builds? Something isn't making sense here.

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.

Post reply on HN