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

A little bit of plain JavaScript can do a lot

jvns.ca

Post reply on HN
Print view View original

101–110 of 206 posts

Re: A little bit of plain JavaScript can do a lot

#101

Post by wruza »

blackrock wrote: post #72
lawl wrote: post #63

Earlier quoted context omitted.

> Instead of HTML, can’t JavaScript just be used to paint the browser canvas? Yes it can. Qt when compiled to web-assembly does this. It just uses a canvas as a framebuffer basically. [0] Going off on a tangent here. This is something I've been thinking about a lot lately. I wanted to build a cross platform app that also works in the browser. Especially as single developer maintaining multiple codebases just sucks. S…

Interesting, this is more in line with what I was thinking of. But, JavaScript is such a poor language, that it’s a poor choice for rigorous software development. However, it is a good candidate for transpiling code to. I was thinking of bolting on an Lisp type of scripting language, which can transpile down to a rigorous subset of JavaScript, which then controls how the widgets behave in the browser. This way, the L…

There is a large semantic gap between those two. Transpiled languages are either very similar to the target, or lose important parts of functionality (or run in an in-target-written vm, which is not a viable option in general).

Re: A little bit of plain JavaScript can do a lot

#102

Post by tonyedgecombe »

bigiain wrote: post #52
triceratops wrote: post #31

Earlier quoted context omitted.

Pretty much this. I knew all of the things she wrote about but all I could think was "I can't imagine writing foo.classList.add and remove 100 times. That's going to create some major spaghetti code once that project grows beyond a couple of pages"

There;s some deep truth here, and I suspect it's about a fundamental difference between "writing a plain vanilla JavaScript application" and "I wanted to use the same HTML to generate both a PDF (with Prince) and to make an interactive version of the questions." Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility. At the same time, reachi…

>Reimplementing gmail or slack in html/css/vanilla-javascript, without an "application frameowrk is no doubt an exercise in futility.

I'm pretty sure gmail started out without a framework.

Re: A little bit of plain JavaScript can do a lot

#103

Post by stefano »

andrewstuart wrote: post #28

I'm an experienced React developer. I wanted to try out writing a plain vanilla JavaScript application - I enjoy plain JavaScript, it feels close to the metal. It wasn't long before I was craving an application framework that allowed me to cleanly organise and structure my application instead of it rapidly becoming a spaghetti. I also craved the ability to write small simple functions for making components. And I wan…

You can have a nicely organized JS project without using a framework, albeit you can expect a bit more boilerplate.

There are many approaches you can take. The following is an MVC approach I'm trying out in a personal project. It's organized as follows:

There's a subscribe/emit system, where you can link functions to run when an object sends an emit signal. This can be done in a couple dozen lines of code. Example: https://gist.github.com/stefano/32cbe9bef5a68ecb3286113369d8...

Models are JavaScript objects. They have methods to read their state and to update it. The methods that update the state need to call emit() so all subscribers are notified.

Views are functions. They return an object with 2 properties: a DOM node (the root of the view), and an update function. The update function takes a model instance, and updates the DOM structure accordingly. If a view supports user interaction, it'll take a delegate object as a parameter. The view will add event handlers which call the delegate object. Example of a text input with a label and optional validation error: https://gist.github.com/stefano/2135cc15470cceba4ac2d344fe2e...

The controller is a function or class. It returns an object with its root view and a function to run when the controller is destroyed for cleanup. It can either take a model as a parameter or instantiate it. It also instantiates the root view, passing itself (or another object) as the delegate. In the delegate methods, it calls the model update methods. The controller subscribes the view to model changes, and unsubscribes them when it's destroyed. Alternatively, the view can subscribe/unsubscribe itself.

With this approach, views can be composed by calling the view functions from inside another view, passing down a delegate and adding the root DOM node to the parent view DOM structure.

The controller and the model are completely independent of the DOM. The model can be tested independently. The controller can be tested with a mock view. The view can be tested by passing in a mock model.

Views only depend on their initial state and the state of the model passed to the update function.

Re: A little bit of plain JavaScript can do a lot

#104

Post by Tenemo »

andai wrote: post #82
anonytrary wrote: post #79

Here's what a "little bit" of JavaScript can't do: 1. Manage subtle browser differences 2. Store and manage reactive state 3. Manage declarative updates You can build a simplified version of React in under 100 lines of code, but that probably won't take care of subtle browser differences. A little bit of JavaScript can do a lot, but it can't do everything you need these days.

Does anyone know a 100 line react clone or tutorial? That sounds very educational.

This one is amazing: https://pomb.us/build-your-own-react/

Re: A little bit of plain JavaScript can do a lot

#106

Post by z3t4 »

stefano wrote: post #103
andrewstuart wrote: post #28

I'm an experienced React developer. I wanted to try out writing a plain vanilla JavaScript application - I enjoy plain JavaScript, it feels close to the metal. It wasn't long before I was craving an application framework that allowed me to cleanly organise and structure my application instead of it rapidly becoming a spaghetti. I also craved the ability to write small simple functions for making components. And I wan…

You can have a nicely organized JS project without using a framework, albeit you can expect a bit more boilerplate. There are many approaches you can take. The following is an MVC approach I'm trying out in a personal project. It's organized as follows: There's a subscribe/emit system, where you can link functions to run when an object sends an emit signal. This can be done in a couple dozen lines of code. Example: h…

The trick is to make as much as possible static. Just pure functions. Second trick is to have only one way direction, eg components only listen to events, they don't emit events, then they don't have to depend on each other, which in turn will lead to better reusability and less spaghetti.

Re: A little bit of plain JavaScript can do a lot

#108

Post by BigJono »

rimliu wrote: post #94
triceratops wrote: post #31

Earlier quoted context omitted.

Pretty much this. I knew all of the things she wrote about but all I could think was "I can't imagine writing foo.classList.add and remove 100 times. That's going to create some major spaghetti code once that project grows beyond a couple of pages"

And now we witness everyday spaghetti code written on the top of some framework and each noodle is wrapped five times in a needless abstraction. There is nothing preventing you to write nice and clean code in plain JS.

Yeah no shit. JS is the only community I've seen where code size scales with dependency count in the positive direction. It's ridiculous.

Re: A little bit of plain JavaScript can do a lot

#109

Post by mjburgess »

onion2k wrote: post #91
userbinator wrote: post #24

I’ve never worked as a professional frontend developer, so even though I’ve been writing HTML/CSS/JS for 15 years for little side projects, all of the projects have been pretty small I'm pretty much the same, and one thing I've noticed which continues to both amuse and sadden me is the fact that those whose main focus is not web development often make better sites/pages than "professional" developers. I once rewrote,…

The only way your comparison works is if your point is "Framework driven apps are never good". I've lost count of the number of times I've pointed out that a good vanilla JS is always going to be better than a bad framework driven app. One is a good app and the other is a bad app. It's obvious, and therefore not a useful comparison. The valid, useful test is whether or not a good vanilla JS app can be better than a g…

Yes, but the choice of approach isn't outcome-neutral.

There is also the question of whether going-vanilla more often results in good apps.

I'd go so far as to say the "naive approach" for most things, whenever it delivers on all the requirements, is always the best approach.

Be it relational (vs., nosql); grep vs elasticsearch; etc.

Re: A little bit of plain JavaScript can do a lot

#110

Post by Tade0 »

userbinator wrote: post #24

I’ve never worked as a professional frontend developer, so even though I’ve been writing HTML/CSS/JS for 15 years for little side projects, all of the projects have been pretty small I'm pretty much the same, and one thing I've noticed which continues to both amuse and sadden me is the fact that those whose main focus is not web development often make better sites/pages than "professional" developers. I once rewrote,…

I think I know why that might be the case: they used an approach appropriate for large-scale projects in a small-scale project - happens very often really.

None of the max 30-user SPAs I wrote during my time at a certain large pharmaceutical company made sense as SPAs, because the scale at which that becomes beneficial just wasn't there.

As for your other experience: I get where you both are coming from. Thing is, we as front-end developers are kind of forced to use that guy's approach, because over the years stakeholders got used to a level of flexibility that's just not achievable using yours.

I for one would love to use minimal amounts of JS instead of frameworks that make me wait 2 minutes on my sad little work laptop until they compile the project, but that would make any event in which some stakeholder changes their mind a disaster requiring me to re-write the whole application every now and then.

Anyway there's light at the end of this tunnel in the form of compiler-frameworks:

https://svelte.dev/

Writing in this feels just like old school vanilla JS, but with additional language features like reactivity.

Post reply on HN