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

291–300 of 715 posts

Re: Plain Vanilla Web

#291

Post by bob1029 »

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 administrative-style UI/UX wherein we are ultimately giving the admin a way to mutate fields in a database somewhere such that the application behaves to the customer's expectations. In many situations, it is clearly 100x faster/easier/less bullshit to send the business a template of the configuration (Excel files) and then load+merge their results directly into the same SQL tables.

The web provides one type of UI/UX. It isn't the only way for users to interact with your product or business. Email and flat files are far more flexible than any web solution.

Re: Plain Vanilla Web

#292

Post by lolinder »

kybernetikos wrote: post #289
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…

> On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. Photopea is a full-featured web app, not website, written without frameworks by a single individual. It is absolutely possible to build feature rich applications without the framework du jour.

You missed the "teams of 30+" part. I believe that a single individual who's dedicated to it can absolutely build a lot of cool stuff without frameworks, but there's a reason why large teams working on complex software tend to settle on them.

The only real viable alternative with a large team is a hand rolled framework, which isn't always worth the trade-off.

Re: Plain Vanilla Web

#293

Post by austin-cheney »

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 interaction, the view. When the page loads I read from the state object and then execute the corresponding changes using the same event handlers that would normally execute in response to the user interactions that wrote the state changes in the first place, which is the control.

That is simple, but many people find that simple is not easy.

Re: Plain Vanilla Web

#294

Post by rhet0rica »

someothherguyy wrote: post #229
rhet0rica wrote: post #150

Earlier quoted context omitted.

No-framework web tinkerer here. If I had a nickel for every second of my life I've spent typing document.getElementById, I'd be able to afford new fingers. Should've been renamed to getId() and put in global scope two decades ago, if not three. At least querySelector() is a few characters shorter, but I always feel bad using such an alarmingly overdesigned tool for anything trivial.

Why are you writing it so many times? Write an alias in 10 seconds? function getId(v) {return document.getElementById(v)} Dev tools allows $ $$, dunno, make a macro?

But if Brendan Eich wanted us to have a shorter name, he would have given us a shorter name!

We must not defy the system!

Re: Plain Vanilla Web

#295

Post by [deleted] »

evantbyrne wrote: post #231
MrJohz wrote: post #218

Earlier quoted context omitted.

Sure, that's what we did in the good old days, and there's good reason that most of us, when building more complex components, switched to better state management systems. The main issue is that, typically, if you're storing data directly in the DOM, you're storing redundant data. For example, if you've got an input that should have a green background if the input is one string, and a purple background if the input i…

This is a comical misrepresentation of reality. The actual reason people switched to React was because it was what Facebook was doing and they wanted to imitate one of the wealthiest companies to ever exist, not because the masses had problems with rendering form widgets. This problem was solved twenty years ago. Perhaps the worst part about this slander is that benchmarks have actually shown time and again that vani…

[deleted]

Re: Plain Vanilla Web

#296

Post by tomnipotent »

emseetech wrote: post #284
sanderjd wrote: post #277

Earlier quoted context omitted.

There is significant path dependency in either direction. A sibling comment to yours described it very well. There really isn't a good substitute for understanding early on whether you're going to be making a website or an application.

Until you have a definitive answer, err on the side of simplicity.

You err on the side of what's best for your business given known constraints. Usually frameworks make teams more productive, and that's worth more than "simplicity", whatever that means to you.

Re: Plain Vanilla Web

#297

Post by jimbob45 »

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.

Developer productivity, theoretically. Although some of these frameworks don’t help with that for me personally.

Re: Plain Vanilla Web

#298

Post by [deleted] »

evantbyrne wrote: post #262
MrJohz wrote: post #253

Earlier quoted context omitted.

Of course vanilla JS is superior to any framework in terms of performance. Anything you can do in a framework, you can do directly in vanilla JS. But performance isn't the only issue here, otherwise we'd all be writing a lot more assembly code. I find your version of history amusing, because the first project that I migrated away from vanilla JS was actually to Angular, because the team found React's JSX syntax too w…

Listen, if you're losing track of the date in your date picker as implied previously, then I don't know what to tell you man. Not a problem I've ever seen with progressive enhancement, and I've worked on more complex user interfaces than most. I have witnessed people struggle to solve state-related issues in SPAs for even relatively simple problems though, where the solution would be trivial in vanilla js. If it's no…

[deleted]

Re: Plain Vanilla Web

#299

Post by ozim »

kybernetikos wrote: post #289
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…

> On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. Photopea is a full-featured web app, not website, written without frameworks by a single individual. It is absolutely possible to build feature rich applications without the framework du jour.

Again failing to understand what parent wrote.

Team of 30 people is not needed to write fully featured application.

Team of 30 people is needed to build, run and maintain enterprise applications. Where you might need 24/7 support and such support requires at least 5 FTE, you might need features changed when 3 people go on 2 or 3 weeks vacations. Maybe that single person will come up with something better to do with their life so you need to have some people to take over.

What parent comment was about, people make broad statements not understanding that world is much bigger place.

Yea it is absolutely possible to build an app the way you describe but it doesn’t work for every app everywhere.

The same of course using React/Angular doesn’t work for everything, everywhere.

Re: Plain Vanilla Web

#300

Post by robertoandred »

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.

Post reply on HN