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

551–560 of 715 posts

Re: Plain Vanilla Web

#551

Post by bondarchuk »

6P58r3MXJSLi wrote: post #532
Vinz_ wrote: post #464

Earlier quoted context omitted.

Because in a lot of cases, the driver isn’t in the correct place, and so if you have their location you can easily tell them how to get to you. I’ve had multiple deliveries where the Uber Eats app just could not tell the driver the correct location for my address, and I wouldn’t have been able to tell the driver how to get there by just them telling me where they were.

> so if you have their location you can easily tell them how to get to you. So you work in logistics support, but you pay to do it?

You want pizza or not?

Re: Plain Vanilla Web

#552

Post by int_19h »

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…

I think that using browser as the way to, essentially, deliver desktop LOB apps to the users seamlessly, updates and all, makes perfect sense. Writing those apps in HTML/CSS/JS, not so much - it's forced on us because that's the only stack that browsers have historically supported, but even with all the app-centric additions to HTML over the past two decades, it's clearly not designed for them first and it shows.

I hope that, in the long term, wasm and canvas (or something similar) will gradually take over this niche. Frameworks like Avalonia already let you write a desktop app and then surface it in the browser, today. This stuff is still rough around the edges, particularly wrt accessibility, but there's nothing unsolvable there in principle, it just needs time and effort (and money).

Re: Plain Vanilla Web

#553

Post by int_19h »

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.

This just means that user doesn't get the animation tho, right? The actual page transition still happens, so you get graceful fallback without the need to do anything special.

Re: Plain Vanilla Web

#554

Post by int_19h »

cmonBro22 wrote: post #471
esseph wrote: post #352

Earlier quoted context omitted.

"Nobody knows how to do anything and shit is inefficient and slow and why does all of this software suck" - customers of things built using frameworks but no understanding of the system being abstracted

Ok so where is the sensible subset of the runtime we're supposed to use? Why have browsers not excised the rest?

Backwards compatibility, which is kinda important on the web. It should be possible to build a website and have it just work a decade later.

Re: Plain Vanilla Web

#555

Post by LAC-Tech »

montag wrote: post #525

Spend five minutes on webcomponents.org for a depressing ride. Broken links, broken demos, ghost town community and shuttered chat servers. Sponsored and abandoned by the Google Polymer team, or so it appears. Just sad.

Of what relevance is this?

Custom elements are very well documented and work in every browser. Get your server to render html with your own elements in them - your own "island architecture", no vercel necessary.

That some site promoting them is moribund doesn't change the fact they work - and are widely used.

Re: Plain Vanilla Web

#556

Post by int_19h »

DrScientist wrote: post #529
deergomoo wrote: post #276

Earlier quoted context omitted.

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 almo…

> HTML is almost frozen in carbonite. Not really - there are pretty big escape hatches - you can do pretty much anything in canvas, custom elements allows you to define your own elements with their own behaviour. I'd say the problem is the opposite - one of the reasons desktop apps from 20-30 years ago ( say MacOS 7 ) where great from a user perspective is pretty much all apps looked and worked in the same way, using…

It's both, really. HTML makes it really easy to do "corporate branded" fancy buttons, but you still have to jump through hoops to do something that could be done with a database and the stock data grid widget in <10 lines of code in VB or Delphi.

Re: Plain Vanilla Web

#557

Post by int_19h »

a99c43f2d565504 wrote: post #149
crystal_revenge wrote: post #119

Earlier quoted context omitted.

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…

Are you implying there exists a better way of making UIs that just hasn't taken over the world for some reason? I also don't like the state of the web.

Look at WPF (or its more modern incarnations like Avalonia or Uno) for a decent example of what a GUI framework designed for desktop apps from the get go can look like.

Things like these haven't taken over the world because they didn't have the ease of app delivery that browsers provide, and attempts to bolt them onto browsers (Silverlight etc) didn't work out because they didn't work out of the box for most end users.

These days though we have enough bits and pieces directly in the browser (wasm, canvas, WebGL etc) to recreate something like Silverlight that "just works" in any modern browser. Take a look at https://eremex.github.io/controls-demo/ for an example of what's possible.

Re: Plain Vanilla Web

#558

Post by sanderjd »

emseetech wrote: post #412
sanderjd wrote: post #404

Earlier quoted context omitted.

For an imagined future. If you're building something with specifications, then what are we even talking about? You know what you need to build so just build that. But this thread is about what to do when you don't know. "Start the simplest way" is not always the right answer, because you have some information about what you plan or want or hope to build, so you can use that information. Not everything is a set of hyp…

We have a fundamental difference of philosophy.

What is your philosophy?

Re: Plain Vanilla Web

#559

Post by sesm »

spankalee wrote: post #188
mmcnl wrote: post #44

This guide assumes web components is a viable alternative for frameworks like React or Vue. That's a very superficial assumption. React and Vue render the UI as declarative function of state, with the help of components. That's why we use those frameworks. Web components don't solve the state management problem.

Web components only solve the interoperable, encapsulated component problem. Rendering libraries like Lit handle declarative templates, and there are many state management solutions, the same ones you can use with React, etc.

Encapsulated - yes.

Interoperable - can you expand on this?

Re: Plain Vanilla Web

#560

Post by sanderjd »

xigoi wrote: post #490
sanderjd wrote: post #404

Earlier quoted context omitted.

For an imagined future. If you're building something with specifications, then what are we even talking about? You know what you need to build so just build that. But this thread is about what to do when you don't know. "Start the simplest way" is not always the right answer, because you have some information about what you plan or want or hope to build, so you can use that information. Not everything is a set of hyp…

> A complex system that works has evolved from a simple system that worked. A complex system built from scratch won’t work. —John Gall

I'm not suggesting building a complex system from scratch. I'm suggesting building systems using tools designed to support the kind of system you're building.

Do you think your quote is true in all cases? Or are you implying that choosing to build using a framework implies building a complex system frame scratch?

Consider a different kind of system. Does every triple-A video game evolve from a simple framework-free implementation, or do most of them choose a graphics engine to build on top of? If a game studio chooses Unity from the start, for instance, is it building a complex system that won't work?

How is it any different to choose a web application framework from the start when building a web application?

Post reply on HN