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

Plain Vanilla Web

plainvanillaweb.com

Post reply on HN
Print view View original

131–140 of 715 posts

Re: Plain Vanilla Web

#131

Post by coolcase »

smokel wrote: post #73
pelagicAustral wrote: post #14

I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.

As a counterpoint, many systems that were originally implemented as native desktop applications have since been migrated to the web. The motivation for this shift is not particularly strong from a technical standpoint, but it is a practical one: deploying native applications is simply too costly. The web finally provides a widespread standard for deploying applications inexpensively. Unfortunately, the technology use…

Nothing wrong with Flash and Silverlight except each being controlled by a single company. I liked those technologies. Adobe Flex was very nice to program in and use for it's time.

Re: Plain Vanilla Web

#132

Post by metabagel »

donohoe wrote: post #66

I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a frame…

Blazing fast. Wow!

Re: Plain Vanilla Web

#134

Post by throwanem »

90s_dev wrote: post #110
mikebelanger wrote: post #80

Earlier quoted context omitted.

You can invoke custom methods and pass in any kind of data into them. As in class SomeElement extends HTMLElement { constructor() { super(); } someMethod(x) { this.innerHTML = ` ${x} `; } } // ignore registry stuff const customElement = document.getElementById('custom-element-id'); customElement.someMethod(42); But you won't learn that from most mainstream custom element tutorials though, for whatever reason.

> ${x} Fine for x:string, but what about w:WebWorker?

Presumably I've defined a .toString() method on w that will behave as I wish when implicitly invoked to perform this coercion.

If I haven't, then presumably I'll be satisfied with the inherited default behavior, which will probably look something like "[object Worker]".

If I care about this extremely contrived example case, in other words, I'll do something to handle it. If I don't, I won't. If I do, it's been easy for at least 25 years now; iirc .toString() was specified in ES3, which was published in March 2000.

Re: Plain Vanilla Web

#135

Post by rjh29 »

lelandfe wrote: post #95
donohoe wrote: post #66

I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a frame…

One of the nice things about this is that back and forwards in history is snappy as hell. I’m so used to going back on my iPhone and the entire page reloading.

SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.

Re: Plain Vanilla Web

#136

Post by lelanthran »

d_burfoot wrote: post #61

Note that you can make things even simpler than this: just use vanilla JS to compose HTML strings, and plug them into divs using innerHTML = "...". When your state changes due to user input, just rebuild the page using the new data. I've been building many simple apps using this technique, it works fine. I'm sure there is some kind of performance hit; it's almost never an issue. I have never seen any browser compatib…

Setting innerHTML is dangerous if it is a value that came from user input.

Users will be able to inject cross site scripting attacks into the forms of other users.

Not saying to never sit, just saying to be aware of injection attacks on the front end.

Re: Plain Vanilla Web

#137

Post by spankalee »

90s_dev wrote: post #110
mikebelanger wrote: post #80

Earlier quoted context omitted.

You can invoke custom methods and pass in any kind of data into them. As in class SomeElement extends HTMLElement { constructor() { super(); } someMethod(x) { this.innerHTML = ` ${x} `; } } // ignore registry stuff const customElement = document.getElementById('custom-element-id'); customElement.someMethod(42); But you won't learn that from most mainstream custom element tutorials though, for whatever reason.

> ${x} Fine for x:string, but what about w:WebWorker?

What would you expect that to do, in any framework?

Re: Plain Vanilla Web

#138

Post by jrapdx3 »

jakelazaroff wrote: post #101
90s_dev wrote: post #78

Earlier quoted context omitted.

Show me a successful GUI made with bash.

Why is a GUI unsuited to stringly-typed data in a way that a CLI is not?

As a matter of fact, Tcl/Tk has been doing exactly that since the 1990s. Of course, Tk has been "borrowed" by other languages, Python's tkinter is well-known. Any language using Tk widgets still has to input options in text form. Obviously that's not particularly difficult to accomplish.

Re: Plain Vanilla Web

#139

Post by spankalee »

hdjrudni wrote: post #103
mikebelanger wrote: post #80

Earlier quoted context omitted.

You can invoke custom methods and pass in any kind of data into them. As in class SomeElement extends HTMLElement { constructor() { super(); } someMethod(x) { this.innerHTML = ` ${x} `; } } // ignore registry stuff const customElement = document.getElementById('custom-element-id'); customElement.someMethod(42); But you won't learn that from most mainstream custom element tutorials though, for whatever reason.

That doesn't look like it even has anything to do with custom components, that's just adding a method to a class. OOP 101.

And custom elements are just classes, so you can do that.

Re: Plain Vanilla Web

#140

Post by electroly »

donohoe wrote: post #66

I'm not against frameworks, but in many cases, they're unnecessary. I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code. My team and I built https://restofworld.org without any frameworks. The feedback, from surveys, outreach, and unsolicited emails, has been overwhelmingly positive, especially around usability and reading experience. We might adopt a frame…

While I think your page is excellent and loads great, I don't think this is related to the approach described by TFA. You're using the biggest framework around: WordPress. You're just static rendering it. TFA is talking about no build tools at all, using modern web standards, and specifically nothing requiring preprocessing. "... just an editor, a browser, and web standards" is a quote from the page.
Post reply on HN