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

271–280 of 715 posts

Re: Plain Vanilla Web

#271

Post by kgeist »

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…

We have 2 main products: a SaaS and a desktop app (1mln+ users combined). It's a pain in the ass to support the desktop app:

- many people refuse to upgrade for various reasons so we have to support ancient versions (especially for important clients), for stuff like license activations etc.

- various misconfigurations (or OS updates) on Windows can make the app suddenly crash and burn - and you waste time investigating the problem. My favorite recent bug: the app works OK everywhere except on some Japanese systems where it just crashes with access violation (see the next bullet point)

- debugging is hard, because you don't have immediate access to the machine where the bug triggered

- originally it was built 100% for Windows but now we have people asking for a MacOS port and it's a lot of work

- people crack our protection 1 day after release and can use it without paying

SaaS has none of those problems:

- people are used to the fact that SaaS applications are regularly updated and can't refuse to upgrade

- modern browsers are already cross-platform

- browser incompatibilities are easier to resolve

- you debug your own, well-known environment

- if someone doesn't play by the rules, you just restrict access with 1 button

Re: Plain Vanilla Web

#272

Post by sanderjd »

lolinder wrote: post #164
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…

I think that this comment is a great example of the total disconnect these conversations always have. On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requi…

Sites vs. applications. It's important to know which you're building.

Re: Plain Vanilla Web

#273

Post by chuckadams »

doc_manhat wrote: post #6

Question - why would you do this in current year ? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!

Mostly for the virtue signaling. There's something to be said for going with the fundamentals, but people who loudly preach fundamentals tend to be, well...

Re: Plain Vanilla Web

#274

Post by sanderjd »

Swizec wrote: post #192
lolinder wrote: post #164

Earlier quoted context omitted.

I think that this comment is a great example of the total disconnect these conversations always have. On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requi…

I work on a site that was built without frameworks with just a sprinkle of jQuery on top of a traditional MVC framework. It worked great but then the business grew and the software became bigger than what fits in 1 engineer’s head. We now have lots of issues that need fixing. A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 secon…

Nailed it. And a lot of people who say "this sounds like an application, let's pick an application framework to use" from the start are people who have experienced what you're currently experiencing. But it's very hard to describe in a compelling way to someone who has never had the same experience.

Re: Plain Vanilla Web

#275

Post by kybernetikos »

90s_dev wrote: post #165
spankalee wrote: post #141

Earlier quoted context omitted.

You absolutely can put properties in templates. Web component authors do this all the time. Here's a lit-html template that sets a property: html` `

At that point you're not using HTML anymore, you're just calling html() in a fancy way, and that's the whole point of the complaint, that custom-elements are not good at being plain HTML even though that's like its whole thing .

Normal HTML elements don't exclusively use HTML attributes either. Surely you've used button.onclick or element.classList or element.innerHTML?

Re: Plain Vanilla Web

#276

Post by deergomoo »

crystal_revenge wrote: post #119
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…

Yup, the web is a thoroughly mediocre application platform†, but the world’s best application distribution platform.

†I know this claim will rub some people the wrong way, but if you compare the capabilities of web tooling to build rich application UIs against desktop app tooling of even 20-30 years ago, there’s no comparison. The web is still primitive, and while JS and CSS are improving at a good pace, HTML is almost frozen in carbonite.

Re: Plain Vanilla Web

#277

Post by sanderjd »

emseetech wrote: post #191
dorfsmay wrote: post #168

Earlier quoted context omitted.

On the third hand, some people use React and some framework to write static web page...

Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React. Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly. There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by…

There is significant path dependency in either direction.

A sibling comment to yours described it very well.

There really isn't a good substitute for understanding early on whether you're going to be making a website or an application.

Re: Plain Vanilla Web

#278

Post by kgwxd »

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.

People looking to get shit done don't really care but, when they're just mindlessly clicking, they'll hit the back button to the main feed way before the time it takes to fetch a modern framework if your site happens to be the first they hit with that particular version from the CDN.

Re: Plain Vanilla Web

#279

Post by claytongulick »

andoando wrote: post #250
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…

My problem with all this vanilla showcases is they are dead ass simple pages with the most basic layouts and user interaction. Shit just show me how long it takes you to create a nice reactive table with search or a form with proper labels, user interaction, validation, errors, etc Why would I implement that all from scratch when I can install svelte install a UI library and add a couple lines of code, all with a 25k…

Increasingly, this is actually an argument in favor of vanilla web components.

The WC ecosystem has grown a lot, and one of the great things about native web components is that they can be consumed by most major frameworks at this point. There are also many mature component sets you can pick from, like shoelace, etc... you can mix and match components from different offerings, something that's not practical with React/Angular (for example).

I can use a select from Ionic, a breadcrumb from Shoelace, and a date picker from Lightning and it'll all just work.

Doing vanilla Javascript development doesn't mean "don't use any libraries" (well, it might to purists, but whatever) it means stick to using standards based technologies with libraries and accelerators.

For example, I use many of the techniques described by the site, but I prefer to use lit-html library (NOT lit framework) for rendering.

Sometimes I use the vaadin router for routing, sometimes the Ionic router, sometimes my home grown one.

I use a little library I wrote called ApplicationState for cross component shared state, because I don't like state being coupled to my DOM structure.

Sure, this requires a deeper understanding than "batteries included" frameworks, but the advantages outweigh the negatives IMHO.

Re: Plain Vanilla Web

#280

Post by const_cast »

whstl wrote: post #178
listenallyall wrote: post #70

Earlier quoted context omitted.

Part of the complaints about MPAs originally was that navigating all the different pages was slow, because loading new pages was slow. But plenty of today's SPAs deliver content even slower and the user is staring at a spinner for lengthy stretches. The key is quick, efficient server responses, whether using SPA or MPA approaches.

Yeah. In theory SPAs should be faster, but in practice rendering/sending the whole template is not as bad. And as you mention, both can be slow, due to the non-cached API/DB call, so...

Even in theory, producing json is just typically slower than producing HTML.

It seems unintuitive, but traversing an object tree using reflection to generate json is just slower than using an HTML template, which is probably a rope data structure.

Post reply on HN