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

111–120 of 715 posts

Re: Plain Vanilla Web

#111

Post by MyPasswordSucks »

c-linkage wrote: post #87
smokel wrote: post #73

Earlier quoted context omitted.

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…

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

Even the most friction-free ClickOnce deployment is going to be more of a deployment hassle than "hey, users, you know how you go to https://subdomain.local-intranet/place to add or subtract items from the inventory database? Well, continue doing that".

The webapp doesn't care if someone's machine was down overnight or if the paranoid lady in design managed to install some local "antivirus" which blocked the updated rollout or if the manager of sales has some unique setting on his machine which for some inscrutable reason does silly things to the new version. If their web browser works, the inventory database works for them, and they're on the latest version. If their web browser doesn't work, well, your support teams would have had to eventually take care of that anyway.

Re: Plain Vanilla Web

#112

Post by deepsun »

> Styling.

The problem I found is that my full-SSR project doesn't use any Node.js at all, and it works fine for everything but CSS, because in order to use includes and variables I need a CSS compiler.

For example, I use a CSS library that defines a very nice style class "alib-link" for all links. I would want to set it for all elements, without adding `class="alib-link"` all the time. It's easy with a CSS-preprocrssor, but how to avoid using one?

Re: Plain Vanilla Web

#113

Post by esseph »

cmonBro22 wrote: post #68
giancarlostoro wrote: post #41

Earlier quoted context omitted.

Even so you can do insanely simple refreshing dynamics with CSS and JS without importing any npm packages.

Sure, but the runtime is not exactly designed to guide you to the best way to do this. Hence the prevalence of frameworks to paper over the runtime. I openly admit that I'd rather learn a new framework than touch anything to do with figuring out how the browser is intended to behave in practice. What an abomination and insult to humanity. Edit: holy shit y'all do not like the earnest approach to technology

Oh no, you're part of the problem :(

Re: Plain Vanilla Web

#114

Post by neiman »

I did a small project last week. It's completely vanilla and works great. It's a web tool for writing long threads for Mastodon.

I kept on wondering while making it if I was doing it wrong without any framework. Because that's what everyone else seems to expect.

Splinter, splinter.almonit.club, if anyone cares.

Re: Plain Vanilla Web

#115

Post by zero_shift »

skrebbel wrote: post #22

I support the general idea here but just because something is in a browser doesn't mean it's a good formalism. Notably, Web Components. They're fantastic for distributing components - after all, a Web Component will work in every framework (even React, the IE of frameworks, finally added support), or even in vanilla HTML. So you can build a component once and everybody can use it. It's fantastic. But for internally c…

I really agree with you. Custom elements are a great way to distribute primitives. They start creating friction when trying to actually compose applications.

Perhaps my brain has been addled by a decade of React but as the examples became more advanced, they just looked a lot noiser and more complex compared to JSX or Svelte components.

Re: Plain Vanilla Web

#116

Post by worik »

c-linkage wrote: post #87
smokel wrote: post #73

Earlier quoted context omitted.

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…

> deploying native applications is simply too costly. I do not understand why people hold this impression, especially in corporate environments. Windows supports both system and per-user deployments; the latter so you don't even need administrator rights. And with Intune, deployments can be pulled or pushed. Many desktop applications are written in .Net so you don't even need to install the runtime because it's prein…

> it's preinstalled on the operating system.

Not on my computers. At home, or at work

Re: Plain Vanilla Web

#117

Post by zero_shift »

cr125rider wrote: post #21
klysm wrote: post #5

Good to understand, but most likely better to stick with react for production stuff anyway

Yup, the 2000 libraries you depend on when you run npm install react won’t have any bugs and will always work together. /s

Just for anyone reading this and wondering what the dependency footprint of React is:

- React-DOM has one runtime dependency (a cooperative scheduler)

- React itself has no runtime dependencies

It's possible the poster above is referring to build time dependencies. This is harder to assess because there are several options. For example, if compiling JSX using TypeScript, this adds only one more dependency.

Re: Plain Vanilla Web

#118

Post by paranoidxprod »

trwired wrote: post #83
arccy wrote: post #31

Earlier quoted context omitted.

You can get smooth transitions with just css too with @view-transition https://developer.mozilla.org/en-US/docs/Web/CSS/@view-trans...

Worth mentioning @view-transition is still not supported in Firefox.

I believe it’s finally enabled by default in nightly builds, so it should be standard soon. I may be wrong and it may have been scoped css enabled, but both are available by feature flags on nightly and plan to be enabled by default by the end of the year.

Re: Plain Vanilla Web

#119

Post by crystal_revenge »

coolhand2120 wrote: post #23

Very nice! I wish this was the world we lived in. I'm from the before times, when W3C stuff was all we had, and it was miserable because it was so immature, and we hired people who "knew jQuery, but not JS". But if I'm being honest post query selector frameworks don't have a strong cost benefit argument - testing frameworks notwithstanding, which are quite lovely. I run sites that serve hundreds of millions per day a…

I'm also from the before times, and still think one of the major issues with all of this is that we've decided to build a global application ecosystem by hacking stuff on top of a document format.

HTML was supposed to just a slight markup layer to make it easier to transit and render text documents, likewise that's all HTTP was designed for. The ratio of text-to-markup should be fairly high (I'm sure today it's less than 1). But for some reason (probably the initial ease of publishing globally) we decided that the future of application development should be to entirely reinvent GUIs to be built on top of this layer. If you look under the hood at what React is doing, we just have decades of hacks and tricks well organized to create the illusion that this is a rational way to create UIs.

Imagine a world where we decided we wanted to create applications by hacking Excel documents and Visual Basic (being from the before times, I had seen attempts at this), or have every app be a PDF file making clever use of PostScript? When one remembers how ridiculous it is to attempt to do what we have collectively done, it's not too surprising that a website can require megabytes of JS to render properly and, more importantly, to allow reasonable development processes allowing for some organization of the code base.

Re: Plain Vanilla Web

#120

Post by skrebbel »

troupo wrote: post #99
CharlesW wrote: post #74

Earlier quoted context omitted.

> Sure but this page is about not using a framework. Fair enough, but the way I read TFA, it doesn't dissuade developers from using tiny convenience libraries that leverage native browser capabilities. Based on your pushback, it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect. I'll dig into that more, thanks!

> it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect. It has custom syntax, custom directives that look like regular JS functions but cannot be used like regular functions, a custom compiler in the works etc. etc. They will keep telling you it just a small library and very vanilla though.

And they're right! IMO Lit is a marvel of engineering. I think the goal they set themselves (make it easier to build an entire app out of web components) is silly, but given that goal, they hit a total homerun. It's fast, the compiler is very optional (not using it just means a bit more boilerplate around attributes etc - it's not like using React without a JSX compiler or something), lit-html is a genius alternative to virtual DOMs, etc. The custom html syntax, IMO, is super useful too (eg it lets you workaround The Attribute Mess by passing data straight to properties, as you would in any sane non-web-component framework). And it's a lot closer to regular HTML than eg React's custom HTML syntax (JSX).
Post reply on HN