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

701–710 of 715 posts

Re: Plain Vanilla Web

#701

Post by giancarlostoro »

andrewflnr wrote: post #456
cmonBro22 wrote: post #68

Earlier quoted context omitted.

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

I guess openly admitting that you refuse to learn how your platform actually works is an "earnest approach", of a sort, but so is admitting that you routinely leave grocery carts in the parking lot and don't see a problem with it.

Theres even an insane amount of documentation on the web about the web. MDN is very well maintained to boot. Im not as versed as some on front end web, but I recognize that I can slice through a lot of front end stuff by just referring to MDN.

Re: Plain Vanilla Web

#702

Post by klabb3 »

_heimdall wrote: post #661
klabb3 wrote: post #634

Earlier quoted context omitted.

Yes and for those cases it’s kind of already solved decently like with htmx or just plain old forms and post requests. I think those old ways are underrated. But, for a chat app it isn’t gonna cut it. Or a collaborative app, where changes need to be pushed to the client. Or maps, or similar. Or anything which needs offline working. (I’m working on a desktop app where majority of state is owned by and lives on the cli…

Not sure if its an unpopular opinion here, but in those kinds of cases I think browsers are just a bad deployment target for the problem. Dealing with cross-platform issues and app store policies can be frustrating, but the web was fundamentally designed for documents and it just doesn't lend itself well to complex, mostly or entirely clients side apps.

It’s not unpopular, I see it as the majority opinion on HN. It’s based on skepticism against web in general, and outright hatred for electron (which is at least somewhat justified).

My app is 11MB bundle (most of which is an unrelated native extension) on most platforms, and has complex stateful business logic and views. It performs mediocre only on Linux due to lacking investment in webkitgtk.

> the web was fundamentally designed for documents

And yet it successfully penetrated the application server market, which it (JS) was never designed for. Stateful apps are much closer to the original design. The gap is essentially a few enumerable pain points that get smaller every year. Most importantly though, the only other toolkit supporting all 3 desktop, 2 mobile and web is Flutter, which is proprietary and entirely downstream the goodwill of a mega-corp.

Re: Plain Vanilla Web

#703

Post by cheikhcheikh »

6P58r3MXJSLi wrote: post #693
BlewisJS wrote: post #650

Earlier quoted context omitted.

This is a completely unhinged response to the idea of getting pizza delivered...

> unhinged while wanting to monitor what the delivery guy does while doing his job and pretending to "help" him because you truly believe that having tipped a couple dollars makes him your butler, that's completely normal... alright... There’s a reason why everyone hates the USA right now — one major reason is that, unlike in much of the world, you truly believe that workers don’t have rights.

honestly wtf are you talking about. What is these insane leaps and projections you're making?? how did you go from having a map that shows you where the driver is to "makes him your butler" and "micromanaging" and "workers don't have rights".

Re: Plain Vanilla Web

#704

Post by tchalvakspamm »

dragontamer wrote: post #593
jfengel wrote: post #562

Earlier quoted context omitted.

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.

Oh god, a webpage built in excel

Re: Plain Vanilla Web

#705

Post by deepsun »

alwillis wrote: post #179
deepsun wrote: post #112

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

> I would want to set it for all elements, without adding `class="alib-link"` all the time. a { /* the code from the alib-link class */ } If you need to style anchor links depending on where they point to, you could use an attribute selector: a[href*="news.ycombinator.com"] { /* more css */ } No preprocessing necessary.

Yes, that's what I do currently. But that css lib has way more useful styles, it's hard to copy everything (e.g. :hover, :visited, @media etc). They also release new versions, fixes from time to time.

Would be great if CSS had a feature "bind all styles from that selector to this selector".

Or if browsers understood SCSS, it allows that and much more.

Re: Plain Vanilla Web

#706

Post by fud101 »

umvi wrote: post #376

I'd recommend vanilla TypeScript instead of vanilla JavaScript. The benefits of typing are enormous. You don't even need npm in the critical path either if you use VSCode since it has tsc built in

interested in this.what do you mean vscoe has it built in?

Re: Plain Vanilla Web

#707

Post by zchrykng »

immibis wrote: post #626
zchrykng wrote: post #612

Earlier quoted context omitted.

Not to mention the people who actively vilify anyone who "snitches" on the person by turning them in to suffer the consequences of their own actions. Luigi anyone?

Can you elaborate?

https://www.newsweek.com/mcdonalds-worker-luigi-mangione-pri...

https://www.dailymail.co.uk/news/article-14176321/Altoona-Mc...

Re: Plain Vanilla Web

#708

Post by shoeb00m »

dandelion9 wrote: post #597
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.

I would argue the web has remained more stable than any other development space. You can still build something with jQuery code from 2007, and it's still supported by modern browsers. You can even start using modern browser APIs without even upgrading jQuery. You could add any modern library as long as it doesn't depend on jQuery.

If you had a python 2 codebase from the same year, you would basically have to scorch it and do a rewrite.

Re: Plain Vanilla Web

#709

Post by sneak »

int_19h wrote: post #641
vaylian wrote: post #622

Earlier quoted context omitted.

What about self-signed certificates? That's still better than plain HTTP.

What benefits does a self-signed certificate give over plain HTTP? They don't prevent MITM injection, which is the thing you raised in other thread.

This assumes that passive attacks and active attacks are the same.

Self-signed doesn’t protect against active MITM, as you note.

It does protect against passive attacks, in providing privacy against eavesdropping and resistance to packet/content injection on the LAN.

Re: Plain Vanilla Web

#710

Post by leptons »

Swizec wrote: post #608
leptons wrote: post #501

Earlier quoted context omitted.

>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 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints. It's been standard practice for at least…

Lots of people build stuff and don’t have 25 years of experience. Or it seemed like “unnecessary complexity” when the app had 5 users and interactions took 100ms. A lot of standard things feel like “wow people are way overthinking this, it’s so easy” when you have 5 users :)

Whoever taught them wasn't doing their job well.
Post reply on HN