Live data from Hacker News

A little bit of plain JavaScript can do a lot

jvns.ca

51–60 of 206 posts

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

#51

Instead of HTML, can’t JavaScript just be used to paint the browser canvas? You can create your text boxes, your drop downs, buttons, etc., everything that makes it a GUI application. Then you fetch your data, per the page you display, via JSON, and fill in the fields. The initial JavaScript download is heavy, but the normal usage of the web application should be quicker, as you’re only fetching the relevant data to…

"The initial JavaScript download is heavy"

Is 64 kb heavy?

There is a graphic libary, that (partly) tries to accomplish this. (but did not really take off)

lib.ivank.net/

Basically the idea was to replace the DOM with a canvas and then create elements in it, like you did in flash.

If it would have matured, you probably could have then used Flex, which is a flash libary, similar to the DOM, but much cleaner. (but flex is heavy, though)

But apparently, no one thought it is worth it. Because, it would mean quite some work, to reimplement the DOM in a faster way ...

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

#52

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…

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, reaching for React/Fluttr/Angular/frontend-framework-de-jour when all you need is to show and hide divs and maybe do css or scroll animations between them is, in my mind, an equally bad decision.

(I can totally see why the framework-de-jour option gets chosen so often though - because no matter how written-in-stone the original specs saying "There wil be no functinality required beyond showing/hiding divs and css animations between them" are, we've all seen projects where a last minute critical/showstopper requirement for the web page to include something insane like a fully functional email client gets dropped in the FE dev's lap the Friday afternoon before launch Monday. Sure, the FE dev made the choice to use React, and while some (perhaps a lot?) of that is "resume driven development", at least some of the blame is on bad sales people and project managers as well...)

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

#53
post #52

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…

[deleted]

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

#54
post #33

Earlier quoted context omitted.

If I'm not mistaken, she's a systems programmer. More low-level stuff. She's definitely not a frontend/React/vue.js dev, as she says in the article. She's written some excellent articles on lower-level programming. But I agree that VanillaJS is not appreciated by a large number of web developers.

That's because in order to build anything of any remote sophistication, you need a framework, otherwise you are committing to maintaining an unmaintainable spaghetti mess. Just like nobody actually built Windows applications with just the Windows API -- they all used frameworks like MFC or reimplemented those frameworks in-house.

Except for the stuff everything else runs on top of like operating systems, servers, runtimes and browsers.

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

#55

Earlier quoted context omitted.

Probably a good batch of spaghetti code if you think vanilla can be used for anything serious. Or rewrite react yourself as another commenter already did.

It is an old meme, that every js-developer, who does not use an existing framework, ends up with his own framework. (also happened to me) Depending on the scope of the work, this is not allways a bad thing. I like my own framework. It does exactly what I want and I can tweak it to my needs anytime. But I work alone and don't have to share my code with different developers, otherwise there would be problems ...

Yeah, the one complaint with frameworks is they never do exactly what you want, instead forcing you to do what generally works for everyone, which is usually good enough. But also can be frustrating. Which is probably why there are many frameworks.

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

#56

This is super super minor but it's JavaScript not Javascript. IMO the camel case makes it look so much better :D

If you really want to nitpick, it's ECMAScript

If you really want to be technical, it's Self in Java garb.

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

#57
post #46

Earlier quoted context omitted.

I mean he is a React developer after all, less than 3 levels of abstraction is greased lightning.

As a React developer I have the strictest policy to never go lower level than the browser and I never touch other fields of computing. I started my computing career in 1986 knowing only React and I'll get to the end of it knowing nothing else.

>> it feels close to the metal

> never go lower level than the browser

So maybe "close to the DOM" rather than "close to the metal"? :-)

On the other hand, if you ever want a project to get you out of your comfort-zone(/rut?) - check this out:

https://www.espruino.com/

You _can_ go "bare metal" and still use your hard won javascript skills...

> I started my computing career in 1986 knowing only React

That's a big gap in your memory between 1986 and when React was first released in 2013. Or _maybe_ 2010 or 2011 if you were working inside Facebook back before they released it publicly...

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

#59

Instead of HTML, can’t JavaScript just be used to paint the browser canvas? You can create your text boxes, your drop downs, buttons, etc., everything that makes it a GUI application. Then you fetch your data, per the page you display, via JSON, and fill in the fields. The initial JavaScript download is heavy, but the normal usage of the web application should be quicker, as you’re only fetching the relevant data to…

> Instead of HTML, can’t JavaScript just be used to paint the browser canvas?

Flutter does this for web support.

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

#60
Of course you can do quite a bit with JS. Some of the projects I’ve made

You can swap CSS classes in JS. But how do you know which classes are available?

You can target HTML elements in JS. But how do you know which elements are available?

You can set “.innerHTML”. But how do you save the state of the application?

As soon as the app grows a little bit in complexity, you’ll end up building functions to keep track of things and functions to perform repeated actions. You end up building a tiny framework that only you know how to use. When it’s time to debug and grow, you’ll need a proper JS framework anyway.

The thing I would say about popular JS frameworks, and which I’m surprised about, is how they favour single page app structures rather than “drop-ins” to enhance a page. I’ve yet to see React or Angular be used as part of a page, which is crazy because they would enhance the developer experience so much, without disturbing the classic way of delivering pages server-side with classic routing and classic user experience.

Post reply on HN