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

591–600 of 715 posts

Re: Plain Vanilla Web

#591

Post by thesuitonym »

invaliduser wrote: post #454
bbkane wrote: post #447

Earlier quoted context omitted.

In fact, I've gone the opposite way- my work has an internal cafe with a menu website that takes a lot of clicks to see everything. I originally planned to scrape the data and make my own website with better (imo) controls, but v0 turned into pumping the data into a Google sheet. I've never needed v1. The Google sheets "UI" solves filtering (i.e., breakfast vs lunch), access control, and basic analytics (~7 other col…

I have a similar experience with providing users with excel files, but would also like to add that in a lot of business, the number 1 competition for a web application is the good old excel file (or its modern cloud version), and it's sometimes a challenge to beat.

I really hate how much work happens out of Excel/Google Sheets, but there's no denying that spreadsheets do a lot of heavy lifting without having to fuss with putting a DB together. Especially nowadays when two people can simultaneously work in a spreadsheet.

Re: Plain Vanilla Web

#592

Post by yCombLinks »

DrScientist wrote: post #561
int_19h wrote: post #556

Earlier quoted context omitted.

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.

Are we really comparing 2 tier to three tier here? ( With the web effectively 3 tier by default ). That old VB code that queried the database directly wouldn't work well over a non-local network. ie there is a bit of apples and oranges comparison here.

How it talks to the backend is irrelevant here. That has zero to do with the fact that the DOM was imply not designed for dynamic application layouts.

Re: Plain Vanilla Web

#593

Post by dragontamer »

jfengel wrote: post #562
bob1029 wrote: post #291

I've transcended the vanilla/framework arguments in favor of "do we even need a website for this?". I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser. A vast majority of the hours I've spent building web sites & applications has been devoted to admini…

I've found that "send me a spreadsheet and I'll upload it" isn't a great user experience. It's just a big pile of cells, with no documentation (which they wouldn't read anyway).There are a billion things they can do wrong, and they get no feedback on it until I email it to them. They don't know what the options are for any field, and it's easy to enter a nonstandard value. A typo in a header row can lead to data loss…

Excel is more than cells?

If you have certain options, use Excels forms to place buttons, menus and selections.

Re: Plain Vanilla Web

#594

Post by derekzhouzhen »

90s_dev wrote: post #9

I am not sold on web-components yet. Especially now with @scoped and import{type:css}, I think there's still a lot of merit to rendering an element statically, shipping it, and updating it dynamically via modern JS. I'm not sold on how people typically do that, and I think we should keep trying to innovate outside of the typical frameworks like React/Svelte, but I definitely don't see any part of web-components being…

You can use shadow-dom without using web-component. web-component and shadow-dom are orthogonal to eachother:

* web-component is a way to attache javascript to certain elements. There are other ways to do it, but sometime this way feel cleaner, like when you do server-side rendering and not using any javascript framework.

* shadow-dom is a way to organize your styles. As you said there are other ways to do it, but I find it useful because it offers full isolation, and is compatible with browsers 3 years back.

Re: Plain Vanilla Web

#595

Post by myfonj »

int_19h wrote: post #570
myfonj wrote: post #512

Am I the only one who (still) does not feel comfortable seeing JavaScript being intertwined into the so-called "vanilla" web in a way that seems more like a hard dependency and not the progressive enhancement we were taught should be the approach for serious public websites? The page https://plainvanillaweb.com/pages/sites.html uses custom components for all code examples and embedded content. Without JavaScript, it…

It depends on the context. What you say makes a lot of sense for web sites , but expecting a web app to use JS strictly as a "progressive enhancement" is IMO unreasonable. Now, this particular website is indeed a proper website, and so it shouldn't need JS to do its thing. But it's also a website that advocates for a certain way of developing web apps (even if they don't use such terminology themselves), and as such,…

This is quite fair point, yet I'd argue that still most so called web apps could (and should) use basic old-school HTML forms as the underlying technology, and progressively enhance from that baseline, up to the "app-y" look and feel we know and ~~ha~~__love__.

Obviously, there are some limits where application built with bog standard HTML forms becomes too cumbersome or makes no practical sense, as you say, but I think that that threshold is far higher than what current web-app landscape exhibits. I think the threshold is around video editing software, or real-time multi-user collaborative spaces perhaps. But for the rest, following three old steps

    Make it work — just HTML.
    Make it nice — add some CSS.
    Make UX slick —  add JS.
still makes sense to me. In context of the plainvanillaweb.com it would mean just moving the content from non-semantic attributes of custom components to their semantic initial content, such as adapt
to get the data from its contents:

Re: Plain Vanilla Web

#596

Post by yCombLinks »

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.

Yes, my first GUI apps were about 20 years ago in visual basic. It was far easier than laying out webpages (assuming you're targeting desktop users). It's just far harder to get users to download and run something (and should be). But the browser's layout system (the DOM) has 0 to do with that, there is nothing but inertia locking us into that.

Re: Plain Vanilla Web

#597

Post by dandelion9 »

NoSalt wrote: post #589

I know I am in the VAST minority, or perhaps the only one, but I cannot stand frameworks. Sure, there may be a lot of power in them, but there is also a lot of bloat and complexity. IMHO, this "power" can easily be achieved with libraries instead of an IOC framework. After you learn a, typically terse and confusing, framework language, you have to know that framework language along with the base language (Java, C#, J…

I agree. It's career-driven bullshit bingo. It gives junior's an opportunity to gain an advantage over senior's ("Oh you don't know JavaScript micro-framework 2025 #10?") and everyone involved in billing for time (employees and consultant) a reason to "refactor" and keep the magic money tree around.

Re: Plain Vanilla Web

#598

Post by archerx »

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’m making a web game and using html, css and vanilla javascript for the UI is fine. I have transitions, sounds and everything is very fast without any of the bloat. The actual game itself is in canvas but everything else is standard web stuff.

Re: Plain Vanilla Web

#599

Post by redandblack »

mrheosuper wrote: post #395
chenster wrote: post #377

Earlier quoted context omitted.

In south east asia, people dont' have very good phone or even smart phone in that matter, txt msg makes sense. The same to many african countries where dumb phones are still dominant.

Do you really think that SEA is still stuck in such economy ? Man you need to explore the world more

this is the storyline that people should ideally internalize and realize that they do not know what they are talking about when commenting on others without having direct experience

Re: Plain Vanilla Web

#600

Post by thesuitonym »

bob1029 wrote: post #389
AdieuToLogic wrote: post #382

Earlier quoted context omitted.

> I've discovered that when you start getting really cynical about the actual need for a web application - especially in B2B SaaS - you may become surprised at how far you can take the business without touching a browser. Enabling customer self administration/configuration of a "B2B SaaS" system mandates some form of interaction. I would be surprised at how many would not expect "touching a browser" to do so. > A vas…

> In short, while letting customers send Excel files "and then load+merge their results directly into the same SQL tables" might sound nice, this does not scale and will certainly result in a failure state at some point. Much of US banking operates almost entirely on this premise and has done so forever. > error detection/reporting, business workflows, and/or role-based access control. I'd take a look at the Nacha (A…

Years ago I was working for a company that was having trouble with their payroll processing vendor. As I was helping them out, I was astounded to find that the final step in payroll was to email a CSV file the bank for the ACH transfers.

This was a fairly small company (~300 employees) and a national bank, so it strikes me as likely that this is how a lot of companies do business.

Post reply on HN