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

Mini projects built with VanillaJS. No frameworks or libraries

github.com

Post reply on HN
Print view View original

151–160 of 171 posts

Re: Mini projects built with VanillaJS. No frameworks or libraries

#151

Post by arexxbifs »

errantspark wrote: post #150
arexxbifs wrote: post #48

Earlier quoted context omitted.

It creates a function returning a function, where the argument to the first (which is a template) is used as a closure in the second (which takes a dict of values). The last function called in turn creates a function using the Function constructor, which, since it takes a string argument as the function body, allows the expansion of the values dict into variables and thus the population of the template string: applyT…

You did a better job of explaining my code than I would have done! Thank you.

Thanks! My pleasure :-)

Re: Mini projects built with VanillaJS. No frameworks or libraries

#152

Post by t0astbread »

austincheney wrote: post #101
t0astbread wrote: post #9

Earlier quoted context omitted.

Until we rediscover that manually keeping the DOM up-to-date is tedious and error prone for almost any project and switch to a good middle ground such as Preact or React without a build step

It’s not that tedious. Learning to do it properly takes less effort than learning a major framework. You would actually have to do it and learn it for this to make any sense though.

I tried both approaches on a recent project and in my experience it gets tedious once my application (and with it, its rendering logic) got more complicated. Manually juggling around listeners and mutable state all over the place just leaves a lot of room for error. (As opposed to leaving all that to some DOM reconciler that I don't have to, essentially, implement myself for every problem.)

Initially learning a new paradigm (declarative over imperative in this case) is hard, of course, but it can be worthwhile. Whatever works for you though.

Re: Mini projects built with VanillaJS. No frameworks or libraries

#153

Post by abraxas »

duderific wrote: post #138
rajangdavis wrote: post #21

Earlier quoted context omitted.

It depends. You can do quite a fair bit with vanilla JS, HTML, and CSS. Things get a little tricky when you start having to maintain a lot of state that multiple elements need to be aware of. It's not impossible to do this with vanilla JS, but the mental model can be a bit difficult and this gets amplified across teams. What crap.js frameworks do well is provide a contract for how state can be organized and how compo…

Thanks for stating this so succinctly. This is a vanilla JS thread, but the "frameworks are crap" groupthink is also getting a bit out of hand. If you are building complex dashboards where multiple components are sharing and updating state, using a declarative framework like React or Vue and state management like Redux keeps things manageable as requirements change.

Isn't the DOM your true state anyway? Why does it have to be kept someplace else? I'm genuinely curious because I don't do any front end work.

Re: Mini projects built with VanillaJS. No frameworks or libraries

#154

Post by [deleted] »

baxuz wrote: post #86
erikbye wrote: post #84

Earlier quoted context omitted.

Heads up: I'm using Firefox, and the posts do not appear until I move the mouse cursor.

Works here on Firefox Dev. Try refreshing, there was a bug I missed with the api returning 200 for a post, but the content was `null`. Fixed it, but you still might have the old cached JS due to the service workers.

[deleted]

Re: Mini projects built with VanillaJS. No frameworks or libraries

#155

Post by dentemple »

wackget wrote: post #125
baxuz wrote: post #34

Here's one I did as an assignment for a job interview: https://github.com/ivancuric/hn-scroll You can see it in action here: https://hn-scroll.netlify.com/ The task was to build an offline capable site which displayed the latest Hacker News posts, and loaded more lazily when scrolling. I had to use the official HN API, and I couldn't have any middleware or caching. Everything had to be done client-side. The app ended…

There's an irony about posting in a topic about simple, vanilla, no-framework scripting and then linking to a repository with the following unnecessary ancillary files: .gitignore .prettierrc README.md REQUIREMENTS.md manifest.webmanifest package.json tsconfig.json yarn.lock Plus the actual source code is spread over four TypeScript files, JavaScript, CSS, and HTML. This isn't meant as criticism of your code specific…

Most ancillary files aren't getting shipped to the user, so what's the point in complaining?

Unless you're seriously arguing that extra documentation is a bad thing?

Re: Mini projects built with VanillaJS. No frameworks or libraries

#156

Post by rajangdavis »

abraxas wrote: post #153
duderific wrote: post #138

Earlier quoted context omitted.

Thanks for stating this so succinctly. This is a vanilla JS thread, but the "frameworks are crap" groupthink is also getting a bit out of hand. If you are building complex dashboards where multiple components are sharing and updating state, using a declarative framework like React or Vue and state management like Redux keeps things manageable as requirements change.

Isn't the DOM your true state anyway? Why does it have to be kept someplace else? I'm genuinely curious because I don't do any front end work.

When you start tracking state in the DOM, you start having to be very imperative on what gets updated as state changes.

For example, if you have a search application and you want to paginate results, you can get pretty far with vanilla js, but you have to evoke changes based on events which is hard to scale beyond one person rolling their own code.

This is a lot nicer with frameworks because you can be less explicit on which elements get updated and rather describe changes in state with elements "subscribing" to these state changes. Furthermore, these frameworks have conventions to follow that makes things consistent which is nice for teams.

I tend to use jQuery for things that require basic JS interactions, but when there are things that require very scoped JS state with a complex set of interactions, I will defer to Vue.js.

Re: Mini projects built with VanillaJS. No frameworks or libraries

#157

Post by flukus »

ng12 wrote: post #18
abraxas wrote: post #16

Interesting. As a developer who's done no front end work since the nineties and has had little appetite for getting back into it (after having seen what modern front end devs seem to contend with) I surmise that all those crap.js frameworks of the month don't do a whole lot of useful stuf after all. I suspected as much but was always too timid to speak up when I observed how much noise and fury in the office produced…

I always find it interesting that the people who unabashedly admit they have minimal front-end experience usually have the strongest condemnation of the current tools.

I've built UI's with Qt, Gtk, swing, VBA, Access, winforms, WPF, TK, html/css and more I can't remember and I stay away from front end webdev these days because the tools are such a tyre fire and way less productive than what we were using > 20 years ago.

I find the people that like most of the current tooling grew up with it, don't know any better and don't want to learn.

Re: Mini projects built with VanillaJS. No frameworks or libraries

#158

Post by bArray »

SahAssar wrote: post #146
rypskar wrote: post #56

Earlier quoted context omitted.

True when using a normal monitor, but could be a problem if using a 120Hz monitor or if the previous call didn't finish fast enough. The best is to use the timestamp requestAnimationFrame sends in to the callback to find time-delta since last call >> The number of callbacks is usually 60 times per second, but will generally match the display refresh rate in most web browsers as per W3C recommendation.

I thought basically all browsers still capped FPS at 60HZ?

Yeah I think it typically only gets slower, not faster. But it's a good point - if you're going to run your physics loop in the update loop (not ideal) then your movements should be time based.

Re: Mini projects built with VanillaJS. No frameworks or libraries

#159

Post by baxuz »

wackget wrote: post #125
baxuz wrote: post #34

Here's one I did as an assignment for a job interview: https://github.com/ivancuric/hn-scroll You can see it in action here: https://hn-scroll.netlify.com/ The task was to build an offline capable site which displayed the latest Hacker News posts, and loaded more lazily when scrolling. I had to use the official HN API, and I couldn't have any middleware or caching. Everything had to be done client-side. The app ended…

There's an irony about posting in a topic about simple, vanilla, no-framework scripting and then linking to a repository with the following unnecessary ancillary files: .gitignore .prettierrc README.md REQUIREMENTS.md manifest.webmanifest package.json tsconfig.json yarn.lock Plus the actual source code is spread over four TypeScript files, JavaScript, CSS, and HTML. This isn't meant as criticism of your code specific…

I really don't like posting in this passive-aggressive quote-answer format, but I feel that I need to address each point specifically.

> no-framework scripting

This isn't a script. It's a project for a mini app.

> My point is your app could have been a single HTML file (or HTML, JavaScript, and CSS if you want to split hairs)

The app has no bundled deps and no framework.

I actually just went on CodeSandbox, started a vanilla TS project (could've just as easily be JS + jsdoc since both CodeSandbox and VScode are using Monaco, but why would I?). 2 clicks. It uses parcel but I could've just used vanilla JS imports. That's what a few of the other artifacts are from.

Lastly, the app was built as a monolith initially and then I split out a few things to make it more readable.

> .gitignore

bruh.

> README.md

BRUH.

> REQUIREMENTS.md

It's there for the people who need more context

> manifest.webmanifest

It needs offline support. That's how the platform works. Same goes for sw.js

You're being a bit dishonest and writing in bad faith. If you work in web development, you know that the times of inline JS and styles in an HTML file, uploaded via FTP to a LAMP server are long gone. Like, 10+ years gone. If you are still romanticizing that, you may have an advanced case of Old Guard™.

If you are a non-web developer, then I hope you don't apply the same reasoning in your everyday work, for your colleagues' sakes.

Re: Mini projects built with VanillaJS. No frameworks or libraries

#160

Post by baxuz »

wackget wrote: post #127
baxuz wrote: post #47

Earlier quoted context omitted.

Thanks! I really appreciate that! I think I can post the evaluation criteria: 1) App performance. We will be looking at the wait times for reader to see the content — the shorter, the better. 2) We will evaluate your code’s quality. Does your code have good modular design and testability? Is it easy to read? 3) We prefer the project to be lightweight, and all dependencies should be well justified. I was focusing on #…

Too tightly coupled? Fuck me. I'd have given them a single .js file. There's a point where decoupling everything is just a complete waste of time. Sounds like the company was run by idealistic developers who have never had to work under real-world deadlines.

Initially it was a single TS file. I did this since one of the requirements was for it to be modular and testable.
Post reply on HN