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

331–340 of 715 posts

Re: Plain Vanilla Web

#331

Post by slater »

lolinder wrote: post #266
coldtea wrote: post #240

Earlier quoted context omitted.

> that their use case absolutely requires This is where those people and teams are wrong.

Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work and assert that they could do it better no matter how much context you share. This group is particularly fond of leaving dismissive comments without any substance. Dogma is a hell of a drug.

> Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work

> In this case: this is a WordPress blog.

Re: Plain Vanilla Web

#332

Post by BostonFern »

lolinder wrote: post #329
mickael-kerjean wrote: post #324

Earlier quoted context omitted.

> it doesn't require them because it's a blog. A counter example is Filestash [1], a full fledge file manager that can open > 100 file (from parquet, arrow, geojson, shp, raw images, etc...). Since it got moved out of React, the app perform better by every single metric than the original one. While I agree there's no team of 30 behind it, so is tons of software with people blindly defaulting to React for the same rea…

You and a few others are missing the point, which means I probably failed to communicate super effectively. Counterexamples aren't really a thing here because my point isn't that you do or don't need a framework for any specific kind of project, my point is that requirements vary and you can't talk framework vs frameworkless without talking requirements. A blog is just one example of a place where frameworks don't he…

> one of the key ingredients that in my experience really call for a framework: coordination between a large number of people

Keep going, you might just end the whole debate in this thread.

Re: Plain Vanilla Web

#334

Post by pier25 »

chillpenguin wrote: post #317
pier25 wrote: post #242

Earlier quoted context omitted.

> I've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code With most frameworks you don't need 100kB of JS code. Heck, with Mithril you get the components, vdom, router, and http client in like 10kB gzip.

shoutout to Mithril! Has always been an under-appreciated gem.

maybe you'll be interested to know v3 is in active development

https://github.com/MithrilJS/mithril.js/pull/2982

Re: Plain Vanilla Web

#335

Post by donohoe »

robertoandred wrote: post #300
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…

Your primary image is over 200kb. 100kb is nothing. And you're using WordPress, so yeah you are using a framework. Turns out you do think they're necessary. And as you can see, framework != slow, whether it's WordPress or anything else.

I believe the topic is front-end frameworks. WP is used as a CMS but the entire front end is built from scratch.

Re: Plain Vanilla Web

#336

Post by Swizec »

degamad wrote: post #327
Swizec wrote: post #192

Earlier quoted context omitted.

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…

I agree with you about the customer-facing issues which occur with vanilla sites which don't deliver good user experience. However, I'm interested in how frameworks solve the developer experience problem you mentioned: > Will this javascript file you touched affect only the feature you wanted, or another 50 pages you didn’t even know about? > When you add a new thing in a template, how many N+1 issues across how many…

> Doesn't this just change into /../

Yes and no!

TypeScript helps a lot – you get quick traceability of where things are used and squiggly lines, if you break a contract. Yes a statically typed MVC framework would get you this, but in my experience the apps that get into this mess also don't use types "because types add too much complexity" (likely true for that company stage).

Componentization brings the other piece – self-contained components that declare their own data dependencies (load their own data), bring their own isolated styling, and generally handle all their internal behavior. This takes some skill/experience to get right and yes you can totally pull it off with every toolstack if you're good enough. The benefit is having a stack that encourages you to think about interfaces and contracts between components and hiding the messy internals from the outside world.

So for example in Flask I'm encouraging this pattern of tiny composable views: https://swizec.com/blog/a-pattern-for-composable-ui-in-flask... Once you have these, you can then move them in and out of the page with some JavaScript and an Ajax call. HTMX does this afaik and it's also how we used to build PHP+Ajax apps for a brief moment 20 years ago before client-side rendering took over for various reasons (smaller payloads mattered back then as did sharing an API between web and mobile)

edit: Point is that an approach based on composability guarantees that components won't break each other, can be moved around, and can live side-by-side without worry. The more your stack can guarantee this (as opposed to manual vigilance) the better.

Re: Plain Vanilla Web

#337

Post by zelphirkalt »

littlecranky67 wrote: post #254
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've always questioned why we should add 100KB of JavaScript to a page before writing a single line of real code 100kb would never be a considerations for any of the apps I worked on (as a contractor in the corporate world). I mostly work in large teams, sometimes we had mulit-team monorepos with various line-of-buisness apps using React. 100kb are so completely irrelevant, as for LoB or B2B, no-one cares about the…

That's assuming quite a few things though about the user's browser. Like cache not being cleared on shutdown. And on the project side, that there are not so many changes, that need to be received by the user agent now, instead of whenever the cache expires. That updates can be applied later on the user side. Of course when updates only happen every few weeks, then it might work... but only if that cache is not deleted, which is a big if.

Re: Plain Vanilla Web

#338

Post by roywiggins »

cosmic_cheese wrote: post #330
sofixa wrote: post #208

Earlier quoted context omitted.

Both were absurdly slow and resource intensive.

Nothing got my old iMac G5 whipped into a frenzy like loading a page that had Flash on it somewhere. I’m not kidding when I say that there were many areas in World of Warcraft, a full-fat seamless open world 3D MMORPG, that didn’t make its fans as angry as Flash could manage to. I was so happy when it finally started to disappear. That kind of sheer disregard for my system resources is inexcusable.

I wonder what could have been if it had had the same effort applied to optimize it as JavaScript did.

Re: Plain Vanilla Web

#340

Post by bradly »

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 sell urns online and my website just has an email link. No shopping cart. A brick-and-mortor urn shop would never have a shopping cart, so why would a virtual one?

I've purchased specialized woodworking tools online that simply involved filling out a form. I later received the parts with an invoice to send payment. You can simply not pay if you choose not to.

There are so many way to do commerce both on and offline and if you squint and look closely you'll find interesting people doing interesting things all around you.

Post reply on HN