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

311–320 of 715 posts

Re: Plain Vanilla Web

#311

Post by insin »

austin-cheney wrote: post #293
lerp-io wrote: post #287

"However, this rich functionality comes at the cost of framework and tooling complexity" this makes not sense, can someone explain how doing stuff in raw DOM is less complex than using react that is doing stuff for you?

Updating content in raw DOM methods is as direct as: 1. Get the desired node. 2. Write the content. That is it. The corresponding code is two lines. But but but... what about state? State is an entirely unrelated issue from writing content. State is also simple though. State is raw MVC plus storage. The way I do it is to have a single state object, the model. I update that model as necessary on user and/or network in…

It is simple, and it very quickly becomes un-simple when it comes into contact with increasing app size/complexity (for things which _need_ to be apps, and which have to deal tasks where the size/complexity is essential due to factors which _can't_ be avoided, e.g. an app which deals with Workers' Comp, with laws and requirements which differ by U.S. state in ways which cut across the entire app) and team size/mix of experience.

Re: Plain Vanilla Web

#312

Post by lolinder »

aucisson_masque wrote: post #286
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…

> how your frameworkless design handles a dozen different features that their use case absolutely requires Would you mind sharing one or two kind of feature that are required by these development team ?

I could, but it would be a distraction because my entire point is that there are an enormous variety of apps with a large variety of requirements being deployed on the web. If I give examples that's going to turn into an argument over whether these specific examples actually need a framework, which will turn into a whole bunch of other hypotheticals of situations that would justify it or situations that won't.

Rather than opening up that can of worms I'm going to leave it where I left it.

Re: Plain Vanilla Web

#313

Post by ern »

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 agree. Having seem enormous amounts of effort wasted on implementing fancy web apps by Digital-first consultancies (they reject BAs, but substitute designers) in the B2B space, I think there does need to be more education for the people who procure this stuff (especially in government) who get ripped off routinely.

Re: Plain Vanilla Web

#314

Post by a4isms »

lolinder wrote: post #264
donohoe wrote: post #239

Earlier quoted context omitted.

I think that this comment is a great example of the total disconnect these conversations always have. I just pointed out that frameworks are not always necessary. >> In this case: this is a WordPress blog. No. It is not a "blog". It's a news site. It uses WP as a CMS. That does not make it a blog, and comes across as nothing more than an attempt to belittle it. The New Yorker, with its 90 year archive (at the time) w…

It's not an attempt to belittle it at all, but as far as I know a news site and a blog have the same feature requirements—the main difference that I'm aware of is that a news site has more traffic and more articles and so may need better caching. If you're aware of requirements that a news site has that a blog doesn't (and I assume you would be, as the OP and creator of the above site), I'd love to hear it.

Blogs and news sites are both in the "content publishing" space, so yes their requirements will overlap. There's likely a complexity continuum from:

1. Something like a one-person blog published by committing Markdown to a GitHub repository and having that published automatically, all the way to; 2. A journalistic news site that has a full CMS back-end tracking multiple authors/bylines, some kind of editor/approval/review workflow, features for deciding what gets shown "above the fold," linters that enforce style guidelines, specialized search features, &c.

While some blogs can have complex requirements and some news sites might be simple, I hope we can appreciate that there will be some blogs that are much, much simpler than the NYT and this have fewer and simpler requirements.

They're both "publishing words," but the back-end complexity reflects the complexity of the business -processes and model more than the complexity of displaying articles on web pages.

Re: Plain Vanilla Web

#315

Post by SquareWheel »

rjh29 wrote: post #135
lelandfe wrote: post #95

Earlier quoted context omitted.

One of the nice things about this is that back and forwards in history is snappy as hell. I’m so used to going back on my iPhone and the entire page reloading.

SPAs are supposed to be more efficient by only loading the data needed to update, but somehow back/forward are 100x more responsive on static pages or static sprinkled with JS, and they don't break the back button either. SPAs always have a kind of sluggish feel to them.

Totally different caching techniques. MPAs have a built in mechanism called back/forward cache. It works automatically on most sites, though some invalidate the cache. https://web.dev/articles/bfcache

SPAs need to hold onto the data themselves, and correctly transition it between pages/components. Poorly-built ones will simply refresh it every time, or discard it if the data is too large.

Both mechanisms can allow for immediate page loads if they've been correctly implemented. They just require a different approach.

Re: Plain Vanilla Web

#316

Post by austin-cheney »

insin wrote: post #311
austin-cheney wrote: post #293

Earlier quoted context omitted.

Updating content in raw DOM methods is as direct as: 1. Get the desired node. 2. Write the content. That is it. The corresponding code is two lines. But but but... what about state? State is an entirely unrelated issue from writing content. State is also simple though. State is raw MVC plus storage. The way I do it is to have a single state object, the model. I update that model as necessary on user and/or network in…

It is simple, and it very quickly becomes un-simple when it comes into contact with increasing app size/complexity (for things which _need_ to be apps, and which have to deal tasks where the size/complexity is essential due to factors which _can't_ be avoided, e.g. an app which deals with Workers' Comp, with laws and requirements which differ by U.S. state in ways which cut across the entire app) and team size/mix of…

Framework people always complain that simplicity doesn't scale. In my nearly 20 years of experience doing this I can firmly say they are entirely wrong. If an application increases in complexity as its features increase the way to restore order is a minor refactor.

But really that isn't what this is about. Framework people were always falling back on this fail to scale argument even in the early days of jQuery. The real issue is that some people cannot architect and cannot refactor. That isn't a code or application limitation. Its a person limitation.

Re: Plain Vanilla Web

#317

Post by chillpenguin »

pier25 wrote: post #242
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 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.

Re: Plain Vanilla Web

#318

Post by klysm »

cr125rider wrote: post #21
klysm wrote: post #5

Good to understand, but most likely better to stick with react for production stuff anyway

Yup, the 2000 libraries you depend on when you run npm install react won’t have any bugs and will always work together. /s

As the sibling comment points out, react does not bring in dependencies like that. It is not that heavy but people associate it with heavy things

Re: Plain Vanilla Web

#320

Post by lolinder »

a4isms wrote: post #314
lolinder wrote: post #264

Earlier quoted context omitted.

It's not an attempt to belittle it at all, but as far as I know a news site and a blog have the same feature requirements—the main difference that I'm aware of is that a news site has more traffic and more articles and so may need better caching. If you're aware of requirements that a news site has that a blog doesn't (and I assume you would be, as the OP and creator of the above site), I'd love to hear it.

Blogs and news sites are both in the "content publishing" space, so yes their requirements will overlap. There's likely a complexity continuum from: 1. Something like a one-person blog published by committing Markdown to a GitHub repository and having that published automatically, all the way to; 2. A journalistic news site that has a full CMS back-end tracking multiple authors/bylines, some kind of editor/approval/r…

Right, I agree with all of this. My point was always that requirements vary and it's pointless to talk about frameworks-vs-no-frameworks unless you're clear up front what your requirements are.

In this particular site's case, the requirements are met by WordPress, so "a WordPress blog" is a simple description of what it is. It wasn't meant to include a value judgement.

Post reply on HN