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

561–570 of 715 posts

Re: Plain Vanilla Web

#561

Post by DrScientist »

int_19h wrote: post #556
DrScientist wrote: post #529

Earlier quoted context omitted.

> HTML is almost frozen in carbonite. Not really - there are pretty big escape hatches - you can do pretty much anything in canvas, custom elements allows you to define your own elements with their own behaviour. I'd say the problem is the opposite - one of the reasons desktop apps from 20-30 years ago ( say MacOS 7 ) where great from a user perspective is pretty much all apps looked and worked in the same way, using…

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.

Re: Plain Vanilla Web

#562

Post by jfengel »

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 with no errors.

There are times when it's the easiest way to handle things, especially for experienced users. But I find it a massive hassle to maintain support for every possible mistake the user can make.

Re: Plain Vanilla Web

#563

Post by sanderjd »

arkh wrote: post #478
sanderjd wrote: post #274

Earlier quoted context omitted.

Nailed it. And a lot of people who say "this sounds like an application, let's pick an application framework to use" from the start are people who have experienced what you're currently experiencing. But it's very hard to describe in a compelling way to someone who has never had the same experience.

But the "looks like not an app, maybe we should not use an application framework" tends to be silenced by "React bootcamp people are a dime a dozen so let's use what they know".

Maybe. Personally I haven't come across this phenomenon. But I haven't worked on this type of system in a very long time, so it's probably different perspective from different experience.

Re: Plain Vanilla Web

#564

Post by threetonesun »

Swizec wrote: post #448
zelphirkalt wrote: post #387

Earlier quoted context omitted.

I think I will never understand, how people write their code in such a messy unorganized way, that it becomes unclear, whether touching some piece of code changes the behavior on 50 other pages. To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file. Especially for websites, the…

> To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file Yes and that’s normal. Big ball of mud is the worlds most popular software architecture. Original: http://www.laputan.org/mud/ My modern take based on the original: https://swizec.com/blog/big-ball-of-mud-the-worlds-most-p…

MVC with jQuery or some SPA framework at some point you have to consider why the menu is tied to the view at all, and not deriving its state from the user session. I'd say in either case who decides that (and who rewrites it) is equally messy. The nice part about SPAs is you can usually slice off that functionality and give it to one set of developers to deal with in isolation much easier than you can with an MVC structure.

Re: Plain Vanilla Web

#566

Post by int_19h »

EmilyHughes wrote: post #510
sebak82 wrote: post #504

When it comes to reducing complexity—especially for Java developers—it’s worth checking out Vaadin. It lets you build full web UIs without touching HTML, CSS, or JavaScript, entirely in Java. The UI logic runs on the server, meaning: no API design, no JSON mapping, no Redux — just a Java object model. Vaadin follows a true full-stack approach, where frontend and backend live in a single codebase. Combined with Spring…

This still of programming does not adhere to MVC though, you can't ever swap out the frontend because it's basically merged to the backend and I suspect complex to debug simmilar to JSF.

All MVC (or rather something more modern like MVVM) happens on the server in this scenario, but it doesn't mean that it doesn't happen at all.

A different View + ModelView on top of the same Model could then be used to provide a different frontend if that is ever required (in practice, it probably won't be).

Re: Plain Vanilla Web

#568

Post by sgbeal »

hdjrudni wrote: post #102
mikebelanger wrote: post #75

Earlier quoted context omitted.

>Perhaps nostalgia and the principle of KISS (and a few others) is clouding my judgement here, after all, frameworks are made for a reason. But it's difficult to imagine a new engineer having any more difficulty with vanilla than learning framework after framework. I feel the same way. React and Angular (well an earlier version of Angular) were made prior to ES2015 being mainstream, so I do think they made sense to u…

I wanted to refute the "the constant churn of new frontend frameworks to learn". If you just stuck with React since 2015, they've only had 4 major versions since then and every ver they deprecate only a few things and then you have a full release cycle to migrate to the new hot thing. It's probably the best upgrade paths of any of the libs I work with. But you're not wrong about there being many ways to write compone…

> I wanted to refute the "the constant churn of new frontend frameworks to learn". If you just stuck with React since 2015, they've only had 4 major versions since then and every ver they deprecate only a few things and then you have a full release cycle to migrate to the new hot thing.

Contrast that with non-framework JS/HTML, where _you_ decide how long it lives and how often you need to upgrade (or not). Having to rejigger a web app every 2-3 years because someone outside of your organization changes something is not only unappealing, but it's horribly expensive for large-scale businesses and possibly prohibitively expensive for small-scale businesses or solo developers.

Re: Plain Vanilla Web

#569

Post by sanderjd »

ummonk wrote: post #354
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.

Replacing non-framework JS with a framework is very hard. Replacing static HTML+CSS with React is much more doable, as it isn’t too hard to transform HTML to JSX.

Yes but if it turns out that you really are building an application, but you didn't think you were up front, it is likely that you started to add "just a little bit of js here and there", because after all each little thing you're doing is not that hard and it feels silly to block any one of those little things on "let's add a framework now". So then you find that you have a "non-framework JS" application that is hard to migrate. That's how path dependency works.

It's true that there is path dependency in the other direction. You implement a framework up front, but then it turns out you're making something too simple for that to really be worthwhile. But very similarly, no individual thing you're doing is a forcing function to simplify things, so you keep doing your simple thing with an overly complex tool.

It always strikes me that people want there to be one right answer for how to start a project, either always choose a framework up front, or never do that. But in my view it's just not that easy, you have to think about what you're doing and make the right decision for that thing.

Re: Plain Vanilla Web

#570

Post by int_19h »

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, is essentially a demo for the same.

Post reply on HN