[HN Gopher] Plain Vanilla Web
___________________________________________________________________
Plain Vanilla Web
Author : andrewrn
Score : 1375 points
Date : 2025-05-11 16:31 UTC (1 days ago)
(HTM) web link (plainvanillaweb.com)
(TXT) w3m dump (plainvanillaweb.com)
| andrewrn wrote:
| Interesting article about ditching frameworks. Embarassingly
| helpful for someone who jumped rather quick into React after
| learning js basics.
| prisenco wrote:
| We have a whole generation of devs and designers who "think in
| react" and it's going to take some time for the culture to
| decouple itself.
| prezjordan wrote:
| As a framework-enjoyer, I'm finding this helpful to leaf through
| just to learn about modern web platform tech.
| braden-lk wrote:
| Very cool overview and a great article--it's fascinating to see
| how far web components have come. Data passing, interactivity,
| and state management still seem pretty tedious in vanilla,
| though!
| 90s_dev wrote:
| Data passing seems _inherently_ broken in web components,
| because all HTML attrs must have string keys _and_ values. Such
| a model just can 't be built on top of.
| kybernetikos wrote:
| Web Components can have properties too, and in fact this is
| the norm.
| skrebbel wrote:
| Can't put those in templates though. It's a serious pain
| and completely unnecessary.
| spankalee wrote:
| You absolutely can put properties in templates. Web
| component authors do this all the time.
|
| Here's a lit-html template that sets a property:
| html`<my-element .someProp=${x}></my-element>`
| 90s_dev wrote:
| At that point you're not using HTML anymore, you're just
| calling html() in a fancy way, and that's the whole point
| of the complaint, that custom-elements are not good at
| being plain HTML even though that's like its _whole
| thing_.
| spankalee wrote:
| Being plain HTML is important for the user of the
| element.
|
| That the element may use a library for its implementation
| is basically irrelevant.
| 90s_dev wrote:
| Hi.
| kybernetikos wrote:
| Normal HTML elements don't exclusively use HTML
| attributes either. Surely you've used button.onclick or
| element.classList or element.innerHTML?
| MrJohz wrote:
| That's not web components, though that's lit-html. That's
| an additional library you need to pull in to manage your
| web components. Which kind of ruins a lot of the stated
| benefits of web components. If I need a framework to
| write my web components, why not just pull in a different
| framework that skips the web component level completely
| and just outputs HTML/CSS directly? What is this
| intermediate step actually bringing me?
| spankalee wrote:
| How does using a library ruin the goals of the components
| at all?
|
| The goal of web components is to enable interoperable,
| encapsulated, reusable components, where how they're
| built is an implementation detail.
|
| You can use a web component that used lit-html without
| knowing anything about lit-html, it even that the
| component uses it.
| MrJohz wrote:
| In theory it is completely an implementation detail, I
| agree. In practice, it's bloat. If every web component I
| use in my project might pull in a completely different
| framework behind the scenes (and worse: if those web
| components depend transitively on other web components
| that pull in yet more frameworks), then I now have to
| deal with all of those different frameworks. Each of them
| will load more bytes and make my page's startup time
| slower. Each of them will have their own state management
| systems. Each of them will have their own approach to
| templating. Each of them will behave subtly differently
| in practice.
|
| Why bother when I can just write everything in a single
| framework?
| skrebbel wrote:
| Not in <template>s, the vanilla HTML alternative to this.
| jakelazaroff wrote:
| Imagine 50 years ago: _"Data passing seems inherently broken
| in Unix, because all processes must use strings for input and
| output. Such a model just can 't be built on top of."_
| 90s_dev wrote:
| Show me a successful GUI made with bash.
| jakelazaroff wrote:
| Why is a GUI unsuited to stringly-typed data in a way
| that a CLI is not?
| 90s_dev wrote:
| Just an intuition.
| jrapdx3 wrote:
| As a matter of fact, Tcl/Tk has been doing exactly that
| since the 1990s. Of course, Tk has been "borrowed" by
| other languages, Python's tkinter is well-known. Any
| language using Tk widgets still has to input options in
| text form. Obviously that's not particularly difficult to
| accomplish.
| mikebelanger wrote:
| You can invoke custom methods and pass in any kind of data
| into them. As in
|
| ``` class SomeElement extends HTMLElement { constructor() {
| super(); } someMethod(x) {
| this.innerHTML = `<h1>${x}</h1>`; }
|
| }
|
| // ignore registry stuff
|
| const customElement = document.getElementById('custom-
| element-id');
|
| customElement.someMethod(42); ```
|
| But you won't learn that from most mainstream custom element
| tutorials though, for whatever reason.
| hdjrudni wrote:
| That doesn't look like it even has anything to do with
| custom components, that's just adding a method to a class.
| OOP 101.
| spankalee wrote:
| And custom elements are just classes, so you can do that.
| mikebelanger wrote:
| >just adding a method to a class. OOP 101.
|
| You're right, it is just a method call from a class.
| Nothing interesting or new. And that's exactly why I like
| it! I like me FE code as boring, unimpressive and as
| simple as possible.
| 90s_dev wrote:
| > <h1>${x}</h1>
|
| Fine for x:string, but what about w:WebWorker?
| throwanem wrote:
| Presumably I've defined a .toString() method on w that
| will behave as I wish when implicitly invoked to perform
| this coercion.
|
| If I haven't, then presumably I'll be satisfied with the
| inherited default behavior, which will probably look
| something like "<h1>[object Worker]</h1>".
|
| If I care about this extremely contrived example case, in
| other words, I'll do something to handle it. If I don't,
| I won't. If I do, it's been easy for at least 25 years
| now; iirc .toString() was specified in ES3, which was
| published in March 2000.
| 90s_dev wrote:
| Yeah sorry I meant how would you pass it to another GUI
| component like we can in React.
| throwanem wrote:
| If I want in the general case to append a child node to a
| parent (as here with the h1 as parent and the stringified
| interpolated value as child), I will in almost every case
| call parent.appendChild(child), where parent and child
| both implement Node, which is the parent class of
| Element. The result will correspond closely to the
| element tree which would be constructed by assigning a
| string like your example to some other element's
| innerHTML. (You are essentially using the browser DOM
| implementation as a templating engine. As sugar over a
| lot of createElement calls and piecewise tree
| construction, this isn't a terrible strategy! The JSX
| with which you're familiar is a more elaborate and more
| typesafe solution for essentially the same problem.)
|
| Similarly, these references would be from the JS
| perspective a POJO with lots of seriously heavy implicit
| "render magic," so you can use them, as with any first-
| class Javascript value, as function arguments parallel to
| but a superset of what React does with its props. See the
| MDN documentation on Node.appendChild (and Node, Element,
| HTMLElement, etc) for more:
| https://developer.mozilla.org/en-US/docs/Web/API/Node
|
| If I want to represent the state of a worker thread in
| the UI, a problem I first recall solving over a weekend
| in 2016, the way I do it will end up closely resembling
| the "MVC pattern," with the Worker instance as "model,"
| the DOM element structure as "view," and a "controller"
| that takes a Worker and returns an element tree. Even if
| I'm using React to build the UI - which I have _also_
| been mostly doing for about as long - I am still going to
| handle this translation with a library function, even if
| my component actually does accept a Worker as a prop,
| which it actually very likely will since that will enable
| me to easily dispatch effects and update the UI on
| changes of worker state. I might define that "business
| logic" function alongside the component which uses it, in
| the same module. But React or vanilla, I won't put that
| logic _in_ the UI rendering code, unless it is trivial
| property mapping and no more (unlikely in this case,
| since any interesting worker thread state updates will
| arrive via message events requiring the parent to keep
| track in some way.)
|
| Does that help clear up what I'm getting at?
| spankalee wrote:
| What would you expect that to do, in any framework?
| MrJohz wrote:
| In React, say, I might write
| <MyComponent worker={worker} />
|
| and expect the worker instance to be passed as an object
| to `MyComponent` as a prop. But with webcomponents, I
| can't do something like that.
| this.innerHTML = `<my-component worker="${worker}">`
|
| will just stringify the worker and pass that string to
| the `my-component`. To get the worker instance to be
| passed correctly, I'd need to do something like
| this.innerHTML = `<my-component>`
| this.firstChild.worker = worker;
| mikebelanger wrote:
| So this isn't even a question about web workers, it's a
| question about how to prop-drill non-string/number data
| through multiple layers of web-components.
|
| Tbh, I'm not sure there's a way for that. But why not
| just define a method in your target child component and
| pass the worker in there?
| MrJohz wrote:
| Yeah, I think the original question was a bit weirdly
| worded which made people focus on web workers rather than
| complex data in general.
|
| You can use properties (as opposed to attributes) as I
| demonstrated, and you can use methods like you suggest,
| but these are both verbose and limited, and add an extra
| "the component has been created but the props haven't
| been fully passed" state to the component you're writing.
| Imagine a component with maybe five different props, all
| of which are complex objects that need to be passed by
| property. That's a lot of boilerplate to work with.
| spankalee wrote:
| In what way are properties verbose and limited in your
| view?
|
| You can set them declaratively with a template binding in
| most template systems.
| MrJohz wrote:
| I showed earlier how it takes multiple lines and some
| fiddling with DOM to set a simple property with vanilla
| web components. Sure, if you're using a framework like
| lit, you have access to template binding, but at that
| point you might as well use an equivalent framework like
| SolidJS or Svelte which just skips the web component
| layer.
| spankalee wrote:
| Skipping the web component later would skip then
| interoperable component part.
| mikebelanger wrote:
| Bringing it back to the site, the author does describe
| implementations of context providers and signals:
|
| https://plainvanillaweb.com/blog/articles/2024-10-07-need
| s-m... https://plainvanillaweb.com/blog/articles/2024-08-
| 30-poor-ma...
|
| I haven't tried signals yet, but I couldn't see why you
| could pass in an object with multiple values.
| spankalee wrote:
| With any web component you could assign the worker to a
| property, either imperatively:
| el.worker = worker
|
| Or declaratively: html`<my-component
| .worker=${worker}></my-component>`
|
| That's using lit-html syntax, but there are a lot of
| other rendering libraries that work similarly.
| insin wrote:
| Every time I go back to give Web Components another 5
| minutes, I hit this point where using lit or a lit-like
| would take a lot of the pain of the problems Web
| Components don't solve and have no planned solution for
| away.
|
| But once I decide to cross the "no dependencies" line,
| using something like Preact + htm as a no-build solution
| would also take the most of the rest of the pain away,
| and solve many, many other problems Web Components have
| no solution and no planned solution for.
| spankalee wrote:
| This is just a lie perpetuated by the React team 10 years ago
|
| All HTML elements are JavaScript objects that have
| properties. You can pass arbitrary data to custom elements
| via those properties.
|
| Look at any modern HTML template system and you'll see the
| ability to pass data to properties declaratively.
| MrJohz wrote:
| Well it's not a lie, it's how HTML and the DOM work.
| Attributes are strings, and what you write in HTML will be
| passed as attributes.
|
| You do _also_ have access to properties, but only in
| Javascript -- you can 't for example write something like
| `<my-custom-component date="new Date(2024, 02, 04)">`. That
| means that if you need to pass around complex data types,
| you need to either manipulate the DOM objects directly, or
| you need to include some sort of templating abstraction
| that will handle the property/attribute problem for you.
|
| This is my main criticism of web components. At the
| simplest levels, they're not useful -- you could build this
| website very easily without them, they aren't providing a
| particularly meaningful abstraction at this level of
| complexity. But at the more complex levels, they're not
| sufficient by themselves -- there's no state management
| concept, there's no templating, there's not even much
| reactivity, other than the stuff you could do with native
| JS event emitters.
|
| As far as I can tell, the best use-case for web components
| is microfrontends, which is a pretty useful use-case (much
| better than iframes), but it's very niche. Apart from that,
| I really don't see why you wouldn't just write normal
| Javascript without worrying about web components at all.
| spankalee wrote:
| It is absolutely a lie, because web components can handle
| arbitrary data just at much as any framework.
|
| You're holding web components to a higher standard here
| in expecting them to take arbitrary data _in HTML_ when
| HTML itself doesn 't support arbitrary data. Notably you
| can't assign arbitrary data to framework components from
| within HTML either, so how are web components any more
| limited?
| MrJohz wrote:
| The original comment was that "all HTML attrs must have
| string keys and values", which is completely true.
|
| The point of web components is that they create normal
| HTML elements. So it makes sense to consider what the
| value of them being normal HTML elements is. You can
| write them directly in your HTML source code, for
| example. But if you do that, you only get access to
| attributes and not to properties, and therefore
| everything needs to be strings. Alternatively, you can
| treat them as DOM nodes in Javascript, at which point you
| get access to properties and can use non-string values,
| but now you've got to deal with the DOM API, which is
| verbose and imperative, and makes declarative templating
| difficult.
|
| Yes, we could compare them to components from other
| frameworks, but that's honestly an absurd comparison.
| They're simply trying to do different things. Frameworks
| aren't trying to create HTML elements. They're trying to
| reactively template the DOM. It's just a completely
| different goal altogether. The comparison doesn't make
| sense.
| mmcnl wrote:
| State management is arguably one of the most important problems
| to solve. That's why we use React and Vue. You can very easily
| build complex user interfaces at scale with those frameworks.
| And you can even take web components along for the ride if you
| want to. They are partially overlapping solutions for different
| problems.
| ilaksh wrote:
| some people cheat by using web components but with Lit
| Elements. https://lit.dev/ . I use it with raw JS without any
| bundling.
| owebmaster wrote:
| Same. Recreating a basic lit framework is like 300 lines of
| code
| chenster wrote:
| Microsoft solved this with VIEWSTATE in ASP.NET it's perfect,
| then industry went with everything Ajax and other over
| engineered frameworks.
| TimTheTinker wrote:
| You don't know how much easier it was at that time (at least
| for web developers with little prior ASP experience) to:
|
| - write a simple web service in C# on top of ASP.NET MVC v1
|
| - build a web frontend on top of it using Prototype.js (or
| jQuery) and a library of components like ExtJS
| klysm wrote:
| Good to understand, but most likely better to stick with react
| for production stuff anyway
| cr125rider wrote:
| Yup, the 2000 libraries you depend on when you run npm install
| react won't have any bugs and will always work together.
|
| /s
| jbreckmckye wrote:
| Just for anyone reading this and wondering what the
| dependency footprint of React is:
|
| - React-DOM has one runtime dependency (a cooperative
| scheduler)
|
| - React itself has no runtime dependencies
|
| It's possible the poster above is referring to build time
| dependencies. This is harder to assess because there are
| several options. For example, if compiling JSX using
| TypeScript, this adds only one more dependency.
| klysm wrote:
| 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
| doc_manhat wrote:
| Question - why would you do this in _current year_? Is it that
| much more performant? I might be ignorant but frameworks seem to
| be the lingua franca for a reason - they make your life much
| easier to manage once set up!
| henning wrote:
| Because of the ridiculous complexity in their setup and
| operation, their glacially slow performance if it is actually
| written in JavaScript and not a non-web platform language that
| compiles to native code, and their extreme volatility and
| instability/pace of deprecation.
|
| The benchmarks I've seen actually show web components being
| slightly slower than the best frameworks/libraries.
|
| The idea is: no build steps initially, minimal build steps
| later on, no dealing with a constant stream of CVEs in
| transitive dependencies, no slow down in CI/CD, much more
| readable stack traces and profiling graphs when investigating
| errors and performance, no massive node_modules folder, etc.
| Massive worlds of complexity and security holes and stupid
| janky bullshit all gone. This will probably also be easier to
| serve as part of the backend API and not require a separate
| container/app/service just running node.js and can probably
| just be served as static content, or at least the lack of Node
| build steps should make that more feasible.
|
| It's a tradeoff some people want to make and others don't.
| There isn't a right and wrong answer.
| 90s_dev wrote:
| Frameworks are fine when you just need to get a job done
| quickly. And they're ideal when you're in a typical corporate
| code factory with average turnover, and for the same reasons
| Java is ideal there.
|
| React is the new Java.
|
| But when you need something the framework can't provide, good
| luck. Yes, high performance is typically one of those things.
| But a _well engineered design_ is almost always another,
| costing maintainability and flexibility.
|
| This is why you _almost always_ see frameworks slow to a crawl
| at a certain point in terms of fixing bugs, adding features, or
| improving performance. I 'd guess React did this around like
| 2019 or so.
| Capricorn2481 wrote:
| > React is the new Java.
|
| Overly hated on and conflated with frameworks, yes.
|
| React requires very little from you. Even less if you don't
| want to use JSX. But because Facebook pushes puzzlingly heavy
| starter kits, everyone thinks React needs routers or NextJS.
| But what barebones React is, at the end of the day, is hardly
| what I'd call a framework, and is suitable for little JS
| "islands."
| zeroq wrote:
| It actually is kind of about performance.
|
| For me it's mostly about de-tooling your project.
|
| For example - I have a fairly complex app, at least for a side
| project, but so far I managed to keep everything without a
| single external dependecy nor any build tool. Now I have to
| convert it all to react and I'm not very happy about that, I
| will have to add a ton of tooling, and what's most important
| for me, I won't be able to make any changes without deploying
| the tooling beforehand.
| SoftTalker wrote:
| Why do you have to convert it to react?
| zeroq wrote:
| it's a long story, let's just call it "a non-functional
| requirement" :)
| lelanthran wrote:
| Performance is irrelevant to 99% of web apps.
|
| Cognitive burden is relevant to 100% of web apps.
|
| When frameworks are used for that 99% of web apps for which
| they are overkill, performance actually _drops_.
|
| > frameworks seem to be the lingua franca for a reason
|
| Sure, but theres no evidence that the reason is what you think
| it is.
|
| The reason could just be "legacy", ie. " this is the way we
| have always done it".
| reconnecting wrote:
| The use of a framework always involves a trade-off between
| independence, responsibility, and delegation of control.
| jerf wrote:
| Well, one nice thing about doing things this way is that it'll
| still be as viable in five years as it is today.
|
| I'm sitting on two UIs at work that nobody can really do
| anything with, because the cutting-edge, mainstream-acceptable
| frameworks _at the time_ they are built in are now deprecated,
| very difficult to even reconstruct with all the library motion,
| and as a result, effectively frozen because we can 't
| practically tweak them without someone dedicating a week just
| to put all the pieces back together enough to rebuild the
| system... and then that week of work has to largely be done
| again in a year if we have to tweak it again.
|
| Meanwhile the little website I wrote with just vanilla HTML,
| CSS, & JS is chugging along, and we can and have pushed in the
| occasional tweak to it without it blowing up the world or
| requiring someone to spend a week reconstructing some weird
| specific environment.
|
| I'm actually not against web frameworks in the general sense,
| but they do need to pull their weight and I think a lot of
| people underestimate their long-term expense for a lot of
| sites. Doing a little bit of JS to run a couple of "fetch"
| commands is not that difficult. It is true that if you start
| building a large enough site that you will eventually
| reconstruct your own framework out of necessity, and it'll be
| inferior to React, but there's a lot of sites under that "large
| enough" threshold.
|
| Perhaps the best way to think about it is that this is the
| "standard library" framework that ships in the browsers, and
| it's worth knowing about it so that you can analyze when it is
| sufficient for your needs. Because if it is sufficient, it has
| a lot of advantages to it. If it isn't, then by all means go
| and get something else... again, I'm definitely not in the camp
| of "frameworks have no utility". But this should always be part
| of your analysis because of its unique benefits it has that no
| other framework has, like its 0KB initial overhead and
| generally unbeatable performance (because all the other
| frameworks are built on top of this one).
| chuckadams wrote:
| Mostly for the virtue signaling. There's something to be said
| for going with the fundamentals, but people who loudly preach
| fundamentals tend to be, well...
| hu3 wrote:
| What irks me about most about web frameworks is the error
| stack.
|
| 20 lines of anonymous function calling gibberish is so
| unpalatable.
|
| It's hard to understand what is actual application code in
| these stacks.
| jonplackett wrote:
| As a react dev I find this fascinating - in the same way I was
| fascinated by the foraging walk I went on the other day - but was
| SO HAPPY that supermarkets exist when I saw how much effort it
| is.
| 90s_dev wrote:
| No, it's more like fast food vs grocery store & home cooked
| meals.
| bryanhogan wrote:
| Love to see this!
|
| Although I do think there is merit to "light" frameworks such as
| Astro, with its scoped styling and better component syntax. But
| at the same time, independence is also important.
|
| I started something similar with https://webdev.bryanhogan.com/
| which focuses on writing good and scalable HTML and CSS.
| 90s_dev wrote:
| I am not sold on web-components yet. Especially now with @scoped
| and import{type:css}, I think there's still a lot of merit to
| rendering an element statically, shipping it, and updating it
| dynamically via modern JS. I'm not sold on _how_ people typically
| do that, and I think we should keep trying to innovate _outside
| of_ the typical frameworks like React /Svelte, but I definitely
| don't see _any part_ of web-components being useful to _any_ type
| of site I run (and I run several disparate types).
| pajamasam wrote:
| > rendering an element statically, shipping it, and updating it
| dynamically via modern JS
|
| Noob question, but what happens behind the scenes in terms of
| these concepts for web components instead?
| vaylian wrote:
| Web components provide a clean abstraction boundary. You can
| add additional methods to your own tags which can encapsulate
| the logic for updating the data in the component.
| benatkin wrote:
| They let you encapsulate the logic pretty much however you
| want, same as not using web components.
| vaylian wrote:
| When you call document.querySelector("something") in the
| main HTML document, it will not find "something" inside the
| internal HTML of a web component.
| benatkin wrote:
| You can use the shadow DOM outside of custom elements,
| and can use custom elements without a shadow DOM.
|
| Edit: I just added a shadow root to a div in your
| comment, saving its content beforehand, moved its content
| inside the shadow root, and added a style with * { all:
| initial } and your comment text got Times New Roman.
| insin wrote:
| Web Components don't solve the problems I do have and add new
| problems I don't want.
|
| Many of the 25 mentions of Shadow DOM in the Components Page
| and 14 mentions of it in the Styling page are about solving
| problems you now only have because the site recommended you use
| Shadow DOM, and the problem Shadow DOM itself is _trying_ to
| solve is one I don't have in components written specifically
| for my app, which will only be used in my app.
| d0gbread wrote:
| Hard agree, from practical experience also. One thing will
| push you towards shadow dom (slots, for example) then ten
| things will push you back towards light dom. I don't exactly
| understand what the spec is aiming to solve with the way
| things currently are. But I do appreciate no build process.
| benatkin wrote:
| I think it's time to go back to Unobtrusive JavaScript. What is
| needed for this are lightweight libraries or practices you can
| code yourself. HTMX is lightweight which is nice but it's like
| script tags. I would rather the urls and methods go in plain
| HTML and stuff like hx-target be determined by JavaScript,
| using data- attributes if needed. That way all the unused HTMX
| features aren't included.
| recursivedoubts wrote:
| see also https://github.com/bigskysoftware/fixi
| dleeftink wrote:
| Shoutout to Facet also[0].
|
| [0]: https://github.com/kgscialdone/facet
| derekzhouzhen wrote:
| You can use shadow-dom without using web-component. web-
| component and shadow-dom are orthogonal to eachother:
|
| * web-component is a way to attache javascript to certain
| elements. There are other ways to do it, but sometime this way
| feel cleaner, like when you do server-side rendering and not
| using any javascript framework.
|
| * shadow-dom is a way to organize your styles. As you said
| there are other ways to do it, but I find it useful because it
| offers full isolation, and is compatible with browsers 3 years
| back.
| pawelduda wrote:
| Other than for learning purposes or very lean projects, you'll
| de-framework yourself just so that you have to spend extra time
| rebuilding it instead of focusing on the essence of your project
| hnthrowaway121 wrote:
| This is the common wisdom about frameworks but I think it
| ignores the wastage & other side effects around frameworks and
| the things they make easy or difficult. Many of the decisions
| made in any framework will represent guardrails for things that
| don't apply to you specifically.
|
| I know you'll "write your own framework" but maybe that's
| optimal in some situations - more than we might give credit to
| at the moment.
| mikebelanger wrote:
| I really wish web components weren't promoted as a "framework
| alternative" and more of a standardization of custom display
| components. Frameworks like enhance.dev and lit.dev are good
| examples of this.
| 90s_dev wrote:
| > The most basic structuring technique is separating CSS into
| multiple files. We could add all those files in order as \<link>
| tags into the index.html but this quickly becomes unworkable if
| we have multiple HTML pages. Instead it is better to import them
| into the index.css (via @import)
|
| You'll eventually need \<link> _anyway_ for preloads, especially
| with web fonts, since that 's the _only_ way to prevent FOUC.
| Personally I lean on build steps to solve this. I don 't like
| bundlers or frameworks, but I have grown accustomed to custom-
| building.
| Etheryte wrote:
| I don't find this convincing. For one, many sites don't need
| web fonts to begin with. For two, the sites that do can use
| `font-display` or, even better, just let the browser figure it
| out. Browser developers have spent way more time on these
| problems than any one of us individually ever will and more
| often than not, the behavior you get out of the box is already
| pretty fine.
| 90s_dev wrote:
| As a user of websites, I definitely notice when a website
| uses web fonts and relies on font-display. Preloading them is
| the only way to avoid jarring changes to the layout. Even if
| the changes are relatively small, they're very jarring. I
| won't do that to users of my sites. It's not hard to take
| care of properly.
| Etheryte wrote:
| That's a very subjective take on what properly means in
| this context. Many would argue that serving the content is
| the main thing that matters to your users, and if your font
| takes so long to load that you need to deal with it
| separately, it would be better to not do that to begin
| with. To put another way, as a fellow user of websites, I
| would much rather read what's written than look at a blank
| page while some marginally different version of Helvetica
| is fetched in the background.
| 90s_dev wrote:
| That's the point of preloads. You don't need to choose.
| As soon as the HTML is loaded, the font is ready. You see
| the HTML immediately (about 10-20ms) _with_ the web font.
| Win win.
| pelagicAustral wrote:
| I work for about 2k users, they do not give a shit about
| reactivity... build a monolith, make it comfy, embrace page
| refresh (nobody gives a fuck about that in the real world), and
| get shit done.
| thenthenthen wrote:
| Unless the page refresh is fast, I tend to agree with you!
| gjsman-1000 wrote:
| I have seen more broken SPAs than MPAs, by far. Ironic,
| considering SPAs are supposed to improve conversion rates and
| user experience. Even from big companies with no excuse -
| Reddit is almost unusable on phones, X was straight up broken
| for a month straight with image loading on mobile.
|
| If you're writing an SPA, and it isn't Twitter or a content
| consumption platform, and it isn't necessary to be API-driven,
| seriously just stop. You're not clever, you're not improving
| the experience, you're only appealing to the tastes of other
| programmers. If billion-dollar companies can't get them working
| perfectly, you certainly won't.
| pelagicAustral wrote:
| We created a generation of developers that AIM to over-
| engineer requirements... and we also came up with extremely
| pervasive frameworks to go with it... My firm cannot hire
| people with no React experience... people REALLY only know
| how to build cruft these days...
| gjsman-1000 wrote:
| I have no React, Vue, or Angular experience. My websites
| were built with Livewire, some HTMX (basically Hotwire in
| the Rails world, server rendered HTML partials; or maybe
| Blazor SSR in the .NET world). I use Tailwind and a Laravel
| backend, but have some experience with C#.
|
| If you think that's interesting, send me your firm's URL,
| I'll consider applying. (Edit: or really anyone reading
| this who is interested - government of a foreign nation
| outside the US is not viable, unfortunately.)
| pelagicAustral wrote:
| my firm is government, so do not expect too much... email
| to {trafalgar battle british general's last
| name]@rails.cl
| bradly wrote:
| As a Rails developer with no desire to work in a React
| codebase, I'm not qualified for about 50-60% of the Rails
| jobs postings. My lastest full time was at Shopify where I
| said over an over that I was Ruby only and not interested
| in a React position only to be told a few months in I
| needed to know React to get promoted. It is exhausting.
| zelphirkalt wrote:
| I have given up on doing frontend work for the time
| being, because of this crap. I used to do full stack with
| modern JS, TS, CSS, HTML and whatnot, but then someone
| made it all go to shit by advertising for NextJS and
| React, while there was zero interactivity on the whole
| platform, except for a couple of checkboxes. A few years
| later, there still isn't much. Some page transitions for
| when things happen in the backend. I told them in the
| beginning, that there is not much interactive stuff, but
| they all got flashed by some one minute low effort
| Material Design shit, and the idea of the whole thing
| being "modern" and hiring more React devs. So I stepped
| away from that while frontend part and let them dig their
| own hole.
|
| Moving a navigation/menu from one app to another takes 3
| people 2-3 weeks by now. Changing the "router" to update
| the TS version is just as time consuming. Things that
| would have taken 1 day max. take now 2-3 weeks. That is
| 1/14th of the productivity and people get paid for that,
| more than I did. Oh and did I mention the menu
| responsiveness was broken for months at a certain
| viewport width? I did report it, but apparently it was so
| hard to fix, that it could not be done in a quiet hour,
| so it took months laying around in the queue of things to
| fix.
| panstromek wrote:
| Might be a bit of a selection bias though. I certainly
| remember a lot of crappy MPAs before SPAs got big. The
| crappines just moved to SPAs as they became mainstream.
| Overall I agree that MPAs are better default, though, good
| SPAs are hard to build.
| listenallyall wrote:
| Part of the complaints about MPAs originally was that
| navigating all the different pages was slow, because
| loading new pages was slow. But plenty of today's SPAs
| deliver content even slower and the user is staring at a
| spinner for lengthy stretches. The key is quick, efficient
| server responses, whether using SPA or MPA approaches.
| whstl wrote:
| Yeah. In theory SPAs should be faster, but in practice
| rendering/sending the whole template is not as bad. And
| as you mention, both can be slow, due to the non-cached
| API/DB call, so...
| const_cast wrote:
| Even in theory, producing json is just typically slower
| than producing HTML.
|
| It seems unintuitive, but traversing an object tree using
| reflection to generate json is just slower than using an
| HTML template, which is probably a rope data structure.
| zelphirkalt wrote:
| Rendering the template or JSON response is the last and
| probably often the least computationally expensive step
| though.
| whstl wrote:
| I guess the rendering itself is pretty much the same for
| both SPAs and MPAs, since in the end it can be pretty
| much the same markup, but the SPA is also at a
| disadvantage here because it has to combine
| template/components + JSON to generate the HTML :/
| whstl wrote:
| That reminds me of when I first benchmarked a Rails app
| and noticed that JSON rendering was significantly slower
| than the remote database call. No lie, jbuilder was
| taking about 80% of the request time for about 90% of all
| endpoints.
| panstromek wrote:
| Oh, totally. I myself have written on how GitHub manages
| to make client side navigation 2x slower than full page
| reload: https://yoyo-code.com/why-is-github-ui-getting-
| so-much-slowe...
| astura wrote:
| Issues with old school websites before SPAs were usually
| "kinda clunky/hard to navigate/find stuff" and
| "ugly/inconsistent UI."
|
| Issues with SPAs are "core features straight up don't work
| " and "page is now just an endless spinner."
|
| I know which I prefer.
| arccy wrote:
| You can get smooth transitions with just css too with @view-
| transition https://developer.mozilla.org/en-
| US/docs/Web/CSS/@view-trans...
| gjsman-1000 wrote:
| The view transitions can even do most of the in-page or
| cross-page animations marketing wants. Just with way, way
| less code or things to break.
|
| https://m.youtube.com/watch?v=jnYjIDKyKHw
| trwired wrote:
| Worth mentioning @view-transition is still not supported in
| Firefox.
| paranoidxprod wrote:
| I believe it's finally enabled by default in nightly
| builds, so it should be standard soon. I may be wrong and
| it may have been scoped css enabled, but both are available
| by feature flags on nightly and plan to be enabled by
| default by the end of the year.
| mvdtnz wrote:
| No one uses Firefox (within the margin of error). Use them
| to your heart's content.
| int_19h wrote:
| This just means that user doesn't get the animation tho,
| right? The actual page transition still happens, so you get
| graceful fallback without the need to do anything special.
| 8organicbits wrote:
| This feels like bringing the annoying transitions people used
| to use between slides in PowerPoint to the web. There's
| nothing smooth about the transition in the linked demo, it's
| quite jarring.
| multjoy wrote:
| Bring back the <blink> tag.
| arccy wrote:
| The point is there's no reload flash as you switch between
| pages. The specific transition is up to the author.
| nico wrote:
| Also, it's a mess separating stuff between react and the
| server, especially when building with express/node as the
| backend and the whole codebase together
|
| It's such a pain having clear separation in development where
| everything runs off of the react server by default, but then it
| won't when deploying, so either you end up doing all sorts of
| weird stuff or you need to be building and running production
| locally constantly, thus defeating the whole convenience of
| having a dev server that can hot reload the changes
| giancarlostoro wrote:
| Even so you can do insanely simple refreshing dynamics with CSS
| and JS without importing any npm packages.
| cmonBro22 wrote:
| 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
| hdjrudni wrote:
| Huh? The built-in APIs aren't perfect, but we're talking
| about something simple as
|
| ``` fetch('/my-content').then(async res => { if(res.ok) {
| document.getElementById('my-element').innerHtml = await
| res.text(); } }) ```
|
| Something like that. Doesn't get much easier. Gone are the
| days of browser inconsistencies, at least of you stick to
| "Baseline Widely available" APIs which is now prominently
| displayed on MDN.
| rhet0rica wrote:
| 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.
| pests wrote:
| You don't have to call getElementById or querySelector on
| document. You can narrow the search by starting at a
| specific node, just most people default into document as
| it's already a global.
| someothherguyy wrote:
| > You don't have to call getElementById or querySelector
| on document.
|
| You do have to call `getElementById` on a document. There
| can be many documents in a window.
| pests wrote:
| Ah yes correct on getElementById, especially as every id
| must be unique.
| Jaygles wrote:
| > especially as every id must be unique.
|
| Although a very consistent convention, there are no
| guardrails put in place to prevent something from setting
| the same id on two or more elements.
|
| getElementById will return the first element that it
| finds with the id, but you can't know for sure if it is
| the only one without additional checks
| insin wrote:
| If I'm just adding sprinkles of interactivity to a
| statically-rendered page for something that vanilla is
| good enough for (i.e. minimal-to-no display logic), I use
| the expando giving an element an `id` adds to `window`:
| <textarea id="userNotes"></textarea> <button
| type="button" id="copyButton">Copy</button>
| <script> copyButton.addEventListener('click', ()
| => {
| navigator.clipboard.writeText(userNotes.value)
| copyButton.innerText = 'Copied' setTimeout(()
| => copyButton.innerText = 'Copy', 1000) })
| </script>
| someothherguyy wrote:
| 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?
| cmonBro22 wrote:
| Sorry?
| rhet0rica wrote:
| 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!
| BrendanEich wrote:
| As I said to Lex Fridman, I was influenced by AWK.
| Ragrets!
| akoboldfrying wrote:
| JavaScript has functions: const g = (x)
| => document.getElementById(x);
| kentbrew wrote:
| That's a code smell. If you're creating the element you
| ought to already know about it. If you're not creating
| the element you should inventory them all at once as the
| page (or component) loads.
| cmonBro22 wrote:
| ...what is this simple compared to?
| esseph wrote:
| Oh no, you're part of the problem :(
| cmonBro22 wrote:
| yes, probably, even _maybe_
|
| But what's the problem again?
| esseph wrote:
| "Nobody knows how to do anything and shit is inefficient
| and slow and why does all of this software suck" -
| customers of things built using frameworks but no
| understanding of the system being abstracted
| cmonBro22 wrote:
| Ok so where is the sensible subset of the runtime we're
| supposed to use? Why have browsers not excised the rest?
| int_19h wrote:
| Backwards compatibility, which is kinda important on the
| web. It should be possible to build a website and have it
| just work a decade later.
| andrewflnr wrote:
| 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.
| al_borland wrote:
| I have a few sites that aren't that complex, and I use JS to
| run a PHP file and populate the results in a div. It appears
| reactive, but it's dead simple.
|
| I get that huge apps probably need a lot more than that, but
| so many people these days reach for heavy frameworks for
| everything, because it's all they know.
| mikebelanger wrote:
| The nice thing about the plain "vanilla" approach is it can be
| used to enhance a more traditional SSR-rendered site. And it
| doesn't need a complete rewrite in React or whatever.
|
| The author of this article blog is describing some more
| advanced SPA-like scenarios, but those are completely optional
| zelphirkalt wrote:
| React aficionados will disagree though, and tell you to move
| your logic into the React framework using code.
| smokel wrote:
| As a counterpoint, many systems that were originally
| implemented as native desktop applications have since been
| migrated to the web. The motivation for this shift is not
| particularly strong from a technical standpoint, but it is a
| practical one: deploying native applications is simply too
| costly.
|
| The web finally provides a widespread standard for deploying
| applications inexpensively. Unfortunately, the technology used
| to build user interfaces for the web remains somewhat mediocre.
|
| It's unfortunate that history took some wrong turns with X11,
| Java, Flash, Silverlight, .NET, and countless other
| alternatives that I haven't personally lived through.
|
| Hopefully, someone will eventually find a way to make
| developing web applications comfortable _and_ the broader
| community will embrace it.
| c-linkage wrote:
| > deploying native applications is simply too costly.
|
| I do not understand why people hold this impression,
| especially in corporate environments.
|
| Windows supports both system and per-user deployments; the
| latter so you don't even need administrator rights. And with
| Intune, deployments can be pulled or pushed.
|
| Many desktop applications are written in .Net so you don't
| even need to install the runtime because it's preinstalled on
| the operating system.
|
| Even ClickOnce deployments -- which you can deploy on the web
| or on a file share -- pretty much make deployments painless.
|
| EDIT: For the naysayers: please then explain to me why Steam
| is so successful at deploying large games on multiple
| platforms?
| hdjrudni wrote:
| That sounds nice and it probably works fine if you're
| targeting a single business running Windows, but targeting
| Mac, Windows and Linux remains more difficult, no?
|
| And is there even a guarantee that your deploy will be
| rolled out in X minutes?
|
| Version skew remains one of the biggest sources of
| catastrophic bugs at the company I work for, and that's not
| even taking into client app ver, just skew between the
| several services we have. Once you add client app ver, we
| have to support things for 3 years.
|
| At my one-person company I just do a Kubernetes deploy, it
| goes out in a couple minutes and everyone has the latest
| ver whether they like it or not. I don't have the resources
| to maintain a dozen versions simultaneously.
| SoftTalker wrote:
| In large corporate environments I agree but small companies
| still mostly don't have central management of end user
| computers. They order a computer from Dell and use it as
| delivered. Much easier to just access everything via a
| browser that way.
| MyPasswordSucks wrote:
| Even the most friction-free ClickOnce deployment is going
| to be more of a deployment hassle than "hey, users, you
| know how you go to https://subdomain.local-intranet/place
| to add or subtract items from the inventory database? Well,
| continue doing that".
|
| The webapp doesn't care if someone's machine was down
| overnight or if the paranoid lady in design managed to
| install some local "antivirus" which blocked the updated
| rollout or if the manager of sales has some unique setting
| on his machine which for some inscrutable reason does silly
| things to the new version. If their web browser works, the
| inventory database works for them, and they're on the
| latest version. If their web browser doesn't work, well,
| your support teams would have had to eventually take care
| of that anyway.
| pests wrote:
| The web browser is not some magic tool that is always
| guaranteed to work. Group policy alone can wreck total
| havoc on web apps on all the major browsers.
| bluefirebrand wrote:
| This would be noticed _immediately_ when all of the
| workers under the group policy try to access their email
| in the morning
| zelphirkalt wrote:
| Some people should probably only be given thin clients,
| because they are too inept to be allowed to handle
| anything else.
|
| Not sure yet how to solve this problem on the Internet
| yet though. How can we prevent uninformed masses from
| creating incentives for businesses, that turn the web
| into a dystopia?
| worik wrote:
| > it's preinstalled on the operating system.
|
| Not on my computers. At home, or at work
| rjh29 wrote:
| Here's a good example: I used Weylus which turns any touch
| device (phone, tablet etc) into a drawing tablet + screen
| mirror. It can be used to turn your iPad into a second
| monitor or as a touch device for your laptop.
|
| Weylus gives you a URL that you can visit on the device and
| instantly use it. Try doing that with native apps. They'd
| need native apps for Windows, Linux, Mac, iOS, Android...
| get them on the app stores too, support all the different
| Linux distros... or just a single URL that works instantly
| anywhere.
|
| Steam works for the same reason the App Store works, it
| targets mostly a single platform (Windows) and all
| dependencies are bundled in. The Steam client itself is a
| web app running on the chrome engine, though.
| debugnik wrote:
| > Many desktop applications are written in .Net so you
| don't even need to install the runtime because it's
| preinstalled on the operating system.
|
| The last .NET version to be deployed this way has a 10 year
| old feature set. Nowadays you bundle the parts of .NET you
| need with the application.
| pjmlp wrote:
| You can still do system wide deployments with .NET Core,
| or .NET 5+, as you prefer to call it.
|
| https://learn.microsoft.com/en-
| us/dotnet/core/install/window...
| debugnik wrote:
| Of course. I was strictly refering to .NET _preinstalled_
| in Windows as per the comment I replied to, which I
| believe only applies to Framework 4.8.
|
| Although, on re-read, maybe they meant there's a good
| chance another application already installed it? This I
| wouldn't agree with, as applications often insist on
| installing different versions of the system-wide runtime,
| even for the same major version.
| neonsunset wrote:
| It doesn't usually happen (on Windows but realistically
| elsewhere too) unless you publish an application as self-
| contained.
|
| To be specific, .NET install is version-aware and would
| manage those side by side, unless the destination folder
| is overridden.
| LegionMammal978 wrote:
| > For the naysayers: please then explain to me why Steam is
| so successful at deploying large games on multiple
| platforms?
|
| Because Valve puts lots of time and money into making it
| work for their customers (https://github.com/ValveSoftware/
| Proton/graphs/contributors), time and money that the
| average small business can't afford.
| conception wrote:
| There's a hidden cost in web applications as well: you lose
| the value of the operating systems application language.
| Every website and thus electron app suffers from this.
| There's no standard place for settings, buttons and windows
| don't behave normally. There's a lot of value in native
| apps in usability just in it sharing the same UX language
| as the operating system. Sadly this is mostly dead for new
| applications.
| kgeist wrote:
| We have 2 main products: a SaaS and a desktop app (1mln+
| users combined). It's a pain in the ass to support the
| desktop app:
|
| - many people refuse to upgrade for various reasons so we
| have to support ancient versions (especially for important
| clients), for stuff like license activations etc.
|
| - various misconfigurations (or OS updates) on Windows can
| make the app suddenly crash and burn - and you waste time
| investigating the problem. My favorite recent bug: the app
| works OK everywhere except on some Japanese systems where
| it just crashes with access violation (see the next bullet
| point)
|
| - debugging is hard, because you don't have immediate
| access to the machine where the bug triggered
|
| - originally it was built 100% for Windows but now we have
| people asking for a MacOS port and it's a lot of work
|
| - people crack our protection 1 day after release and can
| use it without paying
|
| SaaS has none of those problems:
|
| - people are used to the fact that SaaS applications are
| regularly updated and can't refuse to upgrade
|
| - modern browsers are already cross-platform
|
| - browser incompatibilities are easier to resolve
|
| - you debug your own, well-known environment
|
| - if someone doesn't play by the rules, you just restrict
| access with 1 button
| zelphirkalt wrote:
| You could of course also make your desktop app auto
| update without offering a way to refuse. Or you could
| make it display an error, if the user accesses it without
| being at the newest version, and block all further
| interaction. Those are considered impolite, but it seems
| you are doing it anyway in your web app already.
| socalgal2 wrote:
| Building a game for multiple platforms for steam is way
| more work than building a single web app. Builting the game
| often requires unique settings for each platform, machines
| for each target platform, testing on each target platform,
| dealing with bugs on each target platform. Getting
| noterized/certified on each
|
| > EDIT: For the naysayers: please then explain to me why
| Steam is so successful at deploying large games on multiple
| platforms?
|
| How many games are multi-platform on steam? Checking the
| top 20 current most played games, 14 of them are windows
| only. If it's so easy to be multi-platform, why would 14 of
| the top 20 games not be multi-platform? Oh, it's because
| it's NOT EASY. Conversely, web apps are cross platform by
| default.
|
| Only 2 of the top 20 games supported 3 platforms (windows,
| mac, steam-deck). 1 was windows+steam-deck, 3 were
| windows+mac
| crummy wrote:
| > please then explain to me why Steam is so successful at
| deploying large games on multiple platforms?
|
| if you look into the support forums on steam for any random
| game you'll find lots of complaints about stability and
| crashes, many of which are likely to be esoteric system-
| specific problems.
| ummonk wrote:
| That's a very ironic example given that the Steam Client is
| a web-app hosted in Chromium.
| stevepotter wrote:
| I love ClickOnce and am amazed that it never got that
| popular. Installs and updates are seamless.
|
| I wrote an inventory management program for my father's
| hazardous waste company. Used .net mvc as the backend, WPF
| as the frontend. WPF sucks in many ways, but I got it
| working and have had zero complaints.
|
| I built that program almost 20 years ago. Until last year I
| spend maybe 5-6 hours total in maintenance, mostly ssl cert
| updates. Let that sink in.
| eddieroger wrote:
| I get the impression this is said by people who observe
| large enterprises or don't have good device management. I
| work for a big company that deploys proper MDM to our Macs
| and PCs, and as long as the application is packaged
| correctly, they sure can push stuff out fast and without
| user intervention, including killing a running process if
| they so choose. Making an app that packages well is also
| hard, but that's not on those who push them to
| environments.
| coolcase wrote:
| Nothing wrong with Flash and Silverlight except each being
| controlled by a single company. I liked those technologies.
| Adobe Flex was very nice to program in and use for it's time.
| sofixa wrote:
| Both were absurdly slow and resource intensive.
| coolcase wrote:
| My experience circa. 2008/9 was it was fine (used it on a
| commercial app in lieu of good enough web standards for
| the featureset). It was fast and reactive for an app-like
| experience.
|
| Games were made in flash so it can't be that slow.
|
| Maybe slow for time to load. I think we got that down a
| bit and this wasn't to render content but a utility for a
| signed up user.
| SoftTalker wrote:
| It was OK on Windows. It sucked on any other platform.
| And it was a security disaster.
| ab5tract wrote:
| Flash was a lot of things, but also, at the same time,
| neither of these things. (You could come across poorly
| coded and thus poorly performing apps, but that wasn't
| the standard).
|
| Modern day SPAs are far, far worse offenders when it
| comes to smothering resources.
| cosmic_cheese wrote:
| 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.
| roywiggins wrote:
| I wonder what could have been if it had had the same
| effort applied to optimize it as JavaScript did.
| cosmic_cheese wrote:
| It probably could've been great, but unfortunately such a
| thing would've been unlikely at best with Flash being
| solely controlled by Adobe. Not only does that company
| have a disinclination towards optimization that persists
| to this day, but with there having been no alternative
| implementations of Flash, there was no possibility of
| other organizations taking up that torch or for there to
| be competition between implementations driving things
| forward.
| pwdisswordfishz wrote:
| Just like browsers now.
| mejutoco wrote:
| The flash player leaked memory. The longer-running the
| app, the more noticeable it was. I believe this is why
| Adobe Air (flash player packaged as deliverable) failed.
|
| As for the speed of the flash player itself it was quite
| good.
| tomgp wrote:
| They were resource intensive (though probably less so
| than yr average React based site these days) but Flash,
| especially post AS3, was an order of magnitude or two
| faster than JS + html/svg/canvas at the time. It was
| years after the death of Flash that standards based tech
| finally caught up.
| int_19h wrote:
| I think that using browser as the way to, essentially,
| deliver desktop LOB apps to the users seamlessly, updates and
| all, makes perfect sense. Writing those apps in HTML/CSS/JS,
| not so much - it's forced on us because that's the only stack
| that browsers have historically supported, but even with all
| the app-centric additions to HTML over the past two decades,
| it's clearly not designed for them first and it shows.
|
| I hope that, in the long term, wasm and canvas (or something
| similar) will gradually take over this niche. Frameworks like
| Avalonia already let you write a desktop app and then surface
| it in the browser, today. This stuff is still rough around
| the edges, particularly wrt accessibility, but there's
| nothing unsolvable there in principle, it just needs time and
| effort (and money).
| archerx wrote:
| I'm making a web game and using html, css and vanilla
| javascript for the UI is fine. I have transitions, sounds and
| everything is very fast without any of the bloat. The actual
| game itself is in canvas but everything else is standard web
| stuff.
| accrual wrote:
| > I'm making a web game and using html, css and vanilla
| javascript
|
| Nice work. Reminds me of "A Dark Room" and how a simple
| mostly-text interface with a bit of HTML/CSS/JS can have
| such a big impact.
|
| https://adarkroom.doublespeakgames.com/
| spoonsort wrote:
| Not going to lie, that's a pretty out of touch opinion in the
| current decade, where most software feels an order of magnitude
| slower and less reactive than a mechanical device made 120
| years ago.
| zelphirkalt wrote:
| Most of that software are bloated SPAs that somehow manage to
| be slower than a complete page reload of any website or app,
| that is rendered server side using any traditional web
| framework statically rendering HTML templates.
| aziaziazi wrote:
| And adTech. I've been a happy user or the local gumtree [0]
| that always worked fine with my 9yo iPhone... until last
| year: the business model seems to have changed as they
| added in-list advertisement and I can only scroll the
| products list until the first ad wrapper shows up. Then the
| UI freeze and never gets back to life. I don't even see the
| advertisements itself.
|
| [0] https://www.leboncoin.fr/
|
| Edit: just tried it again and seems they fixed it! The ads
| stays in loading state forever but the site is usable
| again. Wonder if they did something on their side or if
| they changed ad provider.
| esafak wrote:
| How do you know? Are you surveying them, including the ones who
| noped out of your site?
| kgwxd wrote:
| People looking to get shit done don't really care but, when
| they're just mindlessly clicking, they'll hit the back button
| to the main feed way before the time it takes to fetch a modern
| framework if your site happens to be the first they hit with
| that particular version from the CDN.
| chenster wrote:
| Still the case in most Asian countries where UIs are all
| Craigslist alike and UX is just shit. People just got use to
| it. Apparently westerns willing to pay a premium for better UX.
| It's a culture gap.
| notfed wrote:
| Side note but as a buyer looking to buy used tools from
| locals, Craigslist's UX could not be better. I just started
| using it recently (after forgetting about it for a decade).
| Absolutely the opposite of shit.
|
| Though I think maybe if one is using it for a different
| purpose, like looking for apartments or roommates then that's
| probably shit.
| lmm wrote:
| Page refresh between pages is ok. Lag when updating a form
| based on your inputs isn't. Frontend UI is like a bigger
| monitor or faster PC - you may not have known what you were
| missing, but once you've experienced it it's very frustrating
| to go back to the clunky old thing.
| Yhippa wrote:
| > Lag when updating a form based on your inputs isn't.
|
| Why not?
| lmm wrote:
| > Why not?
|
| It's really irritating for your users. They might not
| consciously be able to point it out as the cause of their
| irritation, but they'll like your app a lot less.
| andrewmcwatters wrote:
| I have some notes here at andrewmcwatters/custom-elements
| https://github.com/andrewmcwatters/custom-elements.
|
| My business doesn't use React anymore, and I'm so happy I don't
| have to do pointless maintenance.
|
| A side note, included in my repository: you update your element's
| innerHtml from the constructor, not from the connectedCallback.
| MDN and the web standards seem to be inconsistent on this, and
| elsewhere people write about it, too.
|
| People talk a lot about data and binding, etc. I think it's
| weird, it's like people have forgotten how to just use setters.
| You can call a render() method from a setter, and it does the
| same thing WebKit et al do when you call an internal setter on an
| HTML element.
|
| I don't see the value in these frameworks anymore.
| skrebbel wrote:
| I support the general idea here but just because something is in
| a browser doesn't mean it's a good formalism.
|
| Notably, Web Components. They're fantastic for _distributing_
| components - after all, a Web Component will work in every
| framework (even React, the IE of frameworks, finally added
| support), or even in vanilla HTML. So you can build a component
| once and everybody can use it. It 's fantastic.
|
| But for _internally_ composing a web application, Web Components
| are simply awful. They add nearly no helpful features that
| vanilla JS doesn 't already have, and they add bucketloads of
| extra complexity. You got attributes _and_ properties, and they
| 're mostly the same but kinda not always and oh by the way,
| attributes can only be strings so good luck keeping that in sync.
| You got shadow DOM which is great for distribution but super
| restrictive if you want any sort of consistent global styling
| (and a total pain in devtools, especially once you go 10 levels
| deep). You can turn that off, of course, but you gotta know to do
| that. And plenty more quirks like this. It's just.. It makes lots
| of easy things 5x harder and 1 hard thing 1.5x easier. Totally
| not worth it!
|
| If you really want to not use a big clunky framework, but at the
| same time you have a complex enough app that composition and
| encapsulation is important, you'd be much better off just making
| your own object hierarchy (ie without extending HTMLElement),
| skipping all that awkward web component luggage and solely doing
| what they do best (tie an object to an element).
|
| Or, better yet, get over yourself and just use a framework that
| does this for you. Your future self will thank you (and your
| colleagues even more so).
|
| ps. rant time: If only the web browser people had gotten off
| their high horse and not proposed the word "Web Components"! If
| they would've just been named "Custom Elements", which is what
| they are, then we wouldn't have had 5+ years of people mistaking
| them for a React competitor.
| CitrusFruits wrote:
| I remember when web components first came out and there was
| some hype around them, and just being really confused on what
| they're actually good for. I think it's really telling that
| since web components came out there's never been a popular
| framework, website, or company that has heavily leveraged them.
| 90s_dev wrote:
| What about Lit?
| CharlesW wrote:
| I haven't started using Web Components, but I was under the
| impression that libraries like Lit address most of the issues
| you mentioned for devs who don't want to write their own
| minimal base class, no?
| skrebbel wrote:
| Sure but this page is about not using a framework. Once
| you're on board with using a framework like Lit, you might as
| well use Preact or Svelte or a similarly lightweight
| framework. The "web component" angle adds no value if it's
| all internal to your app.
|
| Lit is amazing though. It's fast, lean, and easy to learn. In
| fact, to my experience, the only things about it that are un-
| ergonomic, are due to the fact that it's built around web
| components. Lit without web components would be so much
| better (again, except if you're building something to be
| distributed to other programmers on any framework). It
| wouldn't have a single global registry of components, it
| wouldn't have that attribute mess, and I bet it'd not need a
| compiler at all (it doesn't _need_ it now either, but is
| easier /nicer with it).
| CharlesW wrote:
| > _Sure but this page is about not using a framework._
|
| Fair enough, but the way I read TFA, it doesn't dissuade
| developers from using tiny convenience libraries that
| leverage native browser capabilities. Based on your
| pushback, it sounds like my perception that Lit is mostly a
| convenient base class for Web Components is very incorrect.
| I'll dig into that more, thanks!
| troupo wrote:
| > it sounds like my perception that Lit is mostly a
| convenient base class for Web Components is very
| incorrect.
|
| It has custom syntax, custom directives that look like
| regular JS functions but cannot be used like regular
| functions, a custom compiler in the works etc. etc.
|
| They will keep telling you it just a small library and
| very vanilla though.
| skrebbel wrote:
| And they're right! IMO Lit is a marvel of engineering. I
| think the goal they set themselves (make it easier to
| build an entire app out of web components) is silly, but
| _given_ that goal, they hit a total homerun. It 's fast,
| the compiler is _very_ optional (not using it just means
| a bit more boilerplate around attributes etc - it 's not
| like using React without a JSX compiler or something),
| lit-html is a genius alternative to virtual DOMs, etc.
| The custom html syntax, IMO, is super useful too (eg it
| lets you workaround The Attribute Mess by passing data
| straight to properties, as you would in any sane non-web-
| component framework). And it's a lot closer to regular
| HTML than eg React's custom HTML syntax (JSX).
| troupo wrote:
| > lit-html is a genius alternative to virtual DOMs, etc
|
| It's a haphazard solution that they now fight against
| with "directives" and even a custom compiler "for when
| initial render needs to be fast". It's not bad, but it's
| far from genius. And honestly, the only reason it works
| is that browsers have spent ungodly amounts of time
| optimizing working with strings and making innerHtml
| fast.
|
| Additionally, it's weird to ask for "close to html" in a
| 100% Javascript-driven library/framework.
|
| As for "etc.", I don't even know what etc. stands for.
| lit is busy re-implementing all the things all other
| frameworks have had for years. Including signals, SSR
| etc.
| skrebbel wrote:
| Can you explain more about how they're "fighting against
| lit-html" with the directives? I'm curious what's the
| struggle here.
|
| > Additionally, it's weird to ask for "close to html" in
| a 100% Javascript-driven library/framework.
|
| Fair point. I don't personally really care about that
| either. I guess I just meant to be say that it's not _all
| too_ custom :-)
| troupo wrote:
| It's not really a struggle, but when all you have is a
| string, how do you enforce certain rules and
| requirements?
|
| E.g. classMap
| https://lit.dev/docs/templates/directives/#classmap
|
| --- start quote ---
|
| The classMap must be the only expression in the class
| attribute, but it can be combined with static values
|
| --- end quote ---
|
| So now you have to figure out which attribute this is
| called from, whether this particular call is allowed in
| this attribute etc.
|
| So what they do is they parse (with regexes) their "close
| to HTML" code into a structure not dissimilar to React's,
| figure all this stuff out, reassemble actual HTML and
| dump it to the DOM
| insin wrote:
| I do know what you specifically mean when you say that,
| but... _all_ libraries are leveraging native browser
| capabilities, even ones which implement a better
| component model than Web Components.
| ntaso wrote:
| The irony is: I wrote a bunch of small custom elements
| [0][1] that do one thing and I don't use Lit for that,
| because Lit is still overhead. The litte bit of boilerplate
| overhead of Web Components, I simply wrote by hand.
|
| [0]: Table of contents element:
| https://github.com/cmaas/table-of-contents-element
|
| [1]: SVG avatars (React-free fork of Boring Avatars):
| https://github.com/cmaas/playful-avatars
| MrJohz wrote:
| Based on the JS Framework Benchmarks (so caveats apply), an
| app built with lit-html (i.e. just the HTML templating part,
| as I understand it) is about the same size as SolidJS, and an
| app built with lit (i.e. the full framework) is about the
| same size as Svelte or Preact, and at a similar order of
| magnitude to Vue or Mithril.
|
| So at least in terms of minimal bases, all of these
| frameworks are much of a muchness.
| troupo wrote:
| > then we wouldn't have had 5+ years of people mistaking them
| for a React competitor.
|
| The browser people literally promoted them as a React
| alternative. Then their goals and role changed every year, and
| now they are _again_ promoted as an alternative
| skrebbel wrote:
| Yeah what a waste of collective brainspace that was eh. If
| they had promoted them as "custom elements are the best way
| to distribute components!" then I bet they'd have been much
| more widely embraced by now, by merit of not overselling
| them.
| jbreckmckye wrote:
| I really agree with you. Custom elements are a great way to
| distribute primitives. They start creating friction when trying
| to actually compose applications.
|
| Perhaps my brain has been addled by a decade of React but as
| the examples became more advanced, they just looked a lot
| noiser and more complex compared to JSX or Svelte components.
| coolhand2120 wrote:
| Very nice! I wish this was the world we lived in. I'm from the
| before times, when W3C stuff was all we had, and it was miserable
| because it was so immature, and we hired people who "knew jQuery,
| but not JS". But if I'm being honest post query selector
| frameworks don't have a strong cost benefit argument - testing
| frameworks notwithstanding, which are quite lovely.
|
| I run sites that serve hundreds of millions per day and we pour a
| ton of resources into these projects. We're trapped in a
| framework (react) prison of our own creation. All failures are
| those of complexly. Highly coupled state machines with hacked,
| weaved, minified, compiled, transpiled, shmanzpiled etc. into
| unreadable goop in production. Yes I know source maps, but only
| when needed, and they are yet another layer of complexity that
| can break - and they do. How I long for the good old days before
| frameworks.
|
| 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.
| aidos wrote:
| At 100s of millions I'm assuming you have something closer to a
| static site than an application?
| coolhand2120 wrote:
| It's a popular non-netflix/google video streaming app that
| you've maybe heard of. HTML5 apps/sites/whatever are just
| part of our supported clients. All clients are supported by a
| largish SOA. All of the HTML clients are indeed sites, SPAs
| on a CDN to be more specific, and not "apps" but this is the
| sickly nomenclature our industry has adopted. But I really
| should have called them sites if I want to motivate others to
| do the same, thanks for the correction.
| mikebelanger wrote:
| >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 use when they were initially created.
| Since then, I've become burned out from the constant churn of
| new frontend frameworks to learn. Even within the world of
| React, there's different ways of writing components, and
| different state managers.
| hdjrudni wrote:
| 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
| components and manage state.
|
| And RSC is a mess. But thankfully you can keep pretending
| that doesn't exist.
| sgbeal wrote:
| > 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.
| ardleon wrote:
| It happened to me with a personal project, I abandoned it
| for about 2 years and one day I decided to take it up
| again to add some features and when I did npm install I
| almost died.
| crystal_revenge wrote:
| I'm also from the before times, and still think one of the
| major issues with all of this is that we've decided to build a
| global application ecosystem by _hacking stuff on top of a
| document format_.
|
| HTML was supposed to just a slight markup layer to make it
| easier to transit and render text documents, likewise that's
| all HTTP was designed for. The ratio of text-to-markup _should_
| be fairly high (I 'm sure today it's less than 1). But for some
| reason (probably the initial ease of publishing globally) we
| decided that the future of application development should be to
| entirely reinvent GUIs to be built on top of this layer. If you
| look under the hood at what React is doing, we just have
| decades of hacks and tricks well organized to create the
| illusion that this is a rational way to create UIs.
|
| Imagine a world where we decided we wanted to create
| applications by hacking Excel documents and Visual Basic (being
| from the before times, I had seen attempts at this), or have
| every app be a PDF file making clever use of PostScript? When
| one remembers how ridiculous it is to attempt to do what we
| have collectively done, it's not too surprising that a website
| can require megabytes of JS to render properly and, more
| importantly, to allow reasonable development processes allowing
| for some organization of the code base.
| a99c43f2d565504 wrote:
| Are you implying there exists a better way of making UIs that
| just hasn't taken over the world for some reason?
|
| I also don't like the state of the web.
| knuckleheadsmif wrote:
| Yes, making UI's is not a new problem but building on top
| of the DOM/HTML as the backbone is.
|
| I too am from the before times where I guess we built
| essentially our own frameworks to handle own unique issues
| and take security into our own hands (verses have to trust
| external libraries and external resources....)
|
| I sadly laugh when I hear 20+ years late people are still
| fighting back button navigation issues. I still see sites
| that can't handle double posts correctly or recovery
| gracefully when post responses fail/timeout.
|
| I'm out of the game now but for all the benefits of the web
| it's been haves to death to support stuff the underlying
| infrastructure was nit designed for.
| int_19h wrote:
| Look at WPF (or its more modern incarnations like Avalonia
| or Uno) for a decent example of what a GUI framework
| designed for desktop apps from the get go can look like.
|
| Things like these haven't taken over the world because they
| didn't have the ease of app delivery that browsers provide,
| and attempts to bolt them onto browsers (Silverlight etc)
| didn't work out because they didn't work out of the box for
| most end users.
|
| These days though we have enough bits and pieces directly
| in the browser (wasm, canvas, WebGL etc) to recreate
| something like Silverlight that "just works" in any modern
| browser. Take a look at https://eremex.github.io/controls-
| demo/ for an example of what's possible.
| yCombLinks wrote:
| Yes, my first GUI apps were about 20 years ago in visual
| basic. It was far easier than laying out webpages (assuming
| you're targeting desktop users). It's just far harder to
| get users to download and run something (and should be).
| But the browser's layout system (the DOM) has 0 to do with
| that, there is nothing but inertia locking us into that.
| bigstrat2003 wrote:
| Desktop apps have had superior UIs compared to the web for
| _decades_ , and are still superior today. The Web is a
| terrible application platform which only persists because
| it's very easy to distribute to users.
| deergomoo wrote:
| Yup, the web is a thoroughly mediocre application platform+,
| but the world's best application distribution platform.
|
| +I know this claim will rub some people the wrong way, but if
| you compare the capabilities of web tooling to build rich
| application UIs against desktop app tooling of even 20-30
| years ago, there's no comparison. The web is still primitive,
| and while JS and CSS are improving at a good pace, HTML is
| almost frozen in carbonite.
| DrScientist wrote:
| > 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 the same UI
| toolkit and the same UI principals. And from a developer
| perspective - a lot of the key decisions had already been
| made for you.
|
| The web of today is a zoo of UI styles and interaction
| modes.
|
| The problem isn't so much a lack of innovation or
| possibilities, but perhaps rather the opposite.
| int_19h wrote:
| 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.
| DrScientist wrote:
| 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.
| int_19h wrote:
| You do have a point, but then again, think about how many
| corpnet apps are web apps these days, even though the
| network is local.
| yCombLinks wrote:
| How it talks to the backend is irrelevant here. That has
| zero to do with the fact that the DOM was imply not
| designed for dynamic application layouts.
| DrScientist wrote:
| Sure DOM is retained mode graphics - however as I said,
| if you want to immediate mode - then canvas is available.
| klabb3 wrote:
| > But if I'm being honest post query selector frameworks don't
| have a strong cost benefit argument
|
| To me the killer app in the modern world is reactivity, ie
| making views that update in response to changes in the data
| model. To manually create listeners and do differential
| updates, and manage removal and teardown of event listeners
| etc, is akin to doing manual memory management. We used to do
| that with jquery sometimes, and it's the most error-prone thing
| you can do. It's a stateful shithole.
|
| Once they manage to find a way to modularize components in a
| way that is largely view-declarative, I would be happy to crawl
| up on the surface of vanilla JS again, but not before. It's
| simply missing functionality, imo.
| _heimdall wrote:
| Reactivity features are helpful, but in my opinion they're
| only helpful in a problem that largely shouldn't exist.
|
| For a vast majority of websites out there state largely lives
| on the server. Reactivity is only helpful when the state
| reacted to is client side, and for that most sites that's
| only going to happen when we decide to keep a duplicate copy
| of state in the client rather than rendering on the back end
| where the state lives.
|
| I get the desire for smooth transitions, optimistic
| rendering, etc. Those goals lead to endless complexity and
| bugs when the actual source of truth lives elsewhere.
|
| How a site is build becomes way more simple when we stick to
| keeping HTML rendering where the state lives even if that
| means making UX tradeoffs.
| klabb3 wrote:
| 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 client.)
|
| TLDR I agree for passive web pages but the web is often
| more than that, many times for good reason.
| _heimdall wrote:
| 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.
| lmm wrote:
| But you don't have to learn "framework after framework".
| Realistically, at a well-organised organisation you learn React
| and that's it. You don't worry about the compilation and
| minification and what have you, because you have a working
| build system that does the build and does the source maps, and
| you have a culture that fixes these things if they break or
| become flaky.
|
| As someone who stepped away from web for a while and came back
| to it a couple of years ago, a straight React or Next.js
| application is so, so much nicer to work with than old-school
| webapps were. It feels like the web has finally been dragged
| kicking and screaming into a world of regular software
| development best practices. JS isn't the best programming
| language but it's a proper programming language and it does the
| job, I'm continually baffled that people would rather contort
| themselves with the sub-Turing tarpit of CSS and what have you
| instead of just using some libraries, writing some code, and
| actually solving their problems in what's usually an
| objectively easier and better way.
| _heimdall wrote:
| Why would a language meant to focus only on styling need to
| be Turing complete?
| lmm wrote:
| It doesn't necessarily need to be Turing complete, but CSS
| in its current form is harder to understand, debug or make
| sense of than most Turing-complete languages.
| _heimdall wrote:
| Do you mean because of how its designed to cascade, and
| all the details of priority that requires? Or something
| else?
|
| Personally I've never found the language itself hard to
| understand _other_ than issues where a style somewhere
| else bleeds in and I have to hope browser dev tools can
| point me in the right direction.
| troupo wrote:
| Any attempt to show that vanilla web components are somehow a
| viable solution always read like a parody.
|
| The boilerplate, the innerHTML strings, the long list of caveats,
| the extra code to make basic things like forms work, manually
| attaching styles etc. etc.
| andrewmcwatters wrote:
| I think routing components are mostly out of date now that CSS
| View Transitions exist.
| jjcm wrote:
| A solid overview with some great tips.
|
| One recommendation is to change the mental model here. In my eyes
| it isn't "don't use a framework", it's "build the framework you
| need". It's tremendously easy to set up an extension of
| HTMLElement that has 90% of the functionality you'd want out of
| react. My SPA non.io is built like this - one master component
| that has class functions I want, and one script for generic
| functions.
| dragonwriter wrote:
| > It's tremendously easy to set up an extension of HTMLElement
| that has 90% of the functionality you'd want out of react.
|
| The last 10%, OTOH...
| edoceo wrote:
| Get the first 90% easy, the next 90% is much harder.
| einpoklum wrote:
| The navigation bar of that site to not stay put, vertically, when
| you click one of the links.
|
| That in itself undermines a lot of the author's message, as they
| were not able to reasonably de-framework themselves.
|
| (And - it's not hard to get the navbar right, in any number of
| ways. But you do have to do a bit of work before you preach
| things to others.)
| mmcnl wrote:
| This guide assumes web components is a viable alternative for
| frameworks like React or Vue. That's a very superficial
| assumption. React and Vue render the UI as declarative function
| of state, with the help of components. That's why we use those
| frameworks. Web components don't solve the state management
| problem.
| mbrumlow wrote:
| State management, state manage management everybody yells when
| talking about web dev.
|
| It's not some sort of mystery, it's just a global of your
| variables.
|
| The example given clearly showed components backed by
| JavaScript. Which means you could implement a state management
| system in seconds.
|
| But beyond that state management is overrated. I remember when
| react came out and somebody from face book was describing
| updating some pending message count number. And how they had
| trouble with it. The issue was they made shitty code, and the
| result of react was a solution that hid that shitty code.
| Because I bet to this day if you profile their example they
| still had the bug but the state management system silently hid
| it as a future performance problem.
| evantbyrne wrote:
| State should really only be kept at rest in the backend, form
| elements, and the occasional variable. SPA state management is
| fun to puzzle around with, but gives developers the false
| impression of productivity and is totally redundant to the
| browser's built-in capabilities for shuttling data back and
| forth to a server.
| hdjrudni wrote:
| C'mon.
|
| Even something simple like a date picker. Where are you going
| to store which month you're looking at?
|
| There's state everywhere, and we should not be sending it all
| back and forth to the server.
| evantbyrne wrote:
| Date pickers aren't simple. I would challenge you to
| explain why you couldn't just store it in a variable or on
| the element itself.
| MrJohz wrote:
| Could you explain what you mean by "storing it in a
| variable"? It's perfectly fine to store data in a
| variable (that's what most frameworks do in the end), but
| that state needs to be reactive in some way -- updating
| that state needs to trigger the necessary UI changes (and
| ideally in such a way that the entire component isn't
| being regenerated every time the state changes). This is
| what makes state management so hard.
| evantbyrne wrote:
| Maybe I'll write a blog post on it someday. It depends on
| the exact method you use to build the calendar my man.
| You could just change classes and attributes. Or you
| could use a variable within the scope of where you
| initialize the component. I wouldn't re-render the whole
| thing to apply changes, but that's up to you. The nice
| thing about using vanilla APIs is you don't typically
| have to worry about thrashing the DOM with unnecessary
| renders because that's rarely (perhaps never?) the
| easiest way to patch changes to it, unlike in React where
| useMemo is prevalent.
| MrJohz wrote:
| 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 is another string, what state
| should you store here? Fundamentally, there's only one
| thing that's interesting: the input's value. Anything
| else -- say, the class used to set the background colour
| -- is derived from that value. And therefore we always
| want our data to flow in one direction: the input value
| is the source, and any other state or UI updates are
| based on that.
|
| But in practice, it's usually hard to maintain that
| strict flow of data. For example, you'll probably have
| multiple sources that combine in different ways to create
| different derived data. Or you might have multiple
| different ways of updating those sources that all need to
| perform the same updates to the derived data. Or you
| might have multiple levels of derived data.
|
| It's definitely possible to build applications like this
| -- I started out this way, and still use this for simple
| projects where the state is fairly easy to manage. But as
| projects get more complex -- and as the state gets more
| complex -- it almost invariably leads to weird glitches
| and broken states that shouldn't exist. Hence why state
| management is the core of most modern frameworks -- it's
| the most important problem to solve.
|
| N.B. `useMemo` in React has nothing to do with the DOM --
| React will never thrash the DOM with unnecessary changes,
| that's the point of the diffing process. `useMemo` is
| instead about reducing the number of times that React
| builds its own VDOM nodes.
| evantbyrne wrote:
| 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 vanilla JS is superior to React
| in terms of performance.
| MrJohz wrote:
| 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
| weird. And these weren't even the first wave of
| frameworks -- people had been using state management
| systems long before then, but they had other flaws that
| made them difficult to work with in their own right.
| React became popular very quickly because it had a very
| simple rendering model, and because it was quick in
| comparison to a lot of other options at the time. Since
| then, the field has developed a lot, and at this point I
| wouldn't recommend React at all.
| evantbyrne wrote:
| 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 not for the
| performance, and it's not cutting down development time,
| then what is the endless framework churn really
| accomplishing? Because that js date picker from twenty
| years ago still works.
| creata wrote:
| > at this point I wouldn't recommend React at all.
|
| Out of curiosity, what _would_ you recommend?
| MrJohz wrote:
| I mostly use SolidJS. It's super lightweight - in many
| ways, it's just a wrapper around `document.createElement`
| and a signals library - so you've got a lot of
| flexibility to use it how you want. It works well for
| complex web applications, but the library part of it is
| small enough that you could probably use it for
| individual widgets on a page and not have too much
| overhead. The UX is React-like (hooks and JSX), but
| honestly feels simpler - JSX gets compiled directly to
| DOM nodes rather than a VDOM abstraction, and there's no
| "rules of hooks" to learn.
|
| That said, it's kind of niche, which means you need to be
| more willing to write stuff yourself, so a good
| mainstream alternative is Vue. Vue is also signals-based
| and relatively lightweight, but still has a lot of
| batteries included and a wider ecosystem that is fairly
| strong. They're also great at taking the parts of other
| frameworks that work best and implementing them in Vue,
| but in a fairly considered way. I understand there's also
| some fairly battle-tested full-stack frameworks in the
| Vue ecosystem, although I've not had much personal
| experience of that.
|
| Both libraries are signals-based, which is a completely
| different reactivity concept to React, which will take a
| bit of getting used to. But I suspect Vue will make that
| transition a bit easier - despite SolidJS's more
| superficial similarities to React, it behaves quite
| differently.
| gkiely wrote:
| You were doing ok up until this comment.
| evantbyrne wrote:
| yeah idk either I didn't read it carefully enough or it
| was edited at roughly the same time, because I thought I
| was responding to something very different.
| benatkin wrote:
| One place to store it is in a data attribute.
| austin-cheney wrote:
| I get so tired of framework people talking about state as the
| hill they are willing to die on. State is stupid simple. You
| use the frameworks because you cannot figure it out on your own
| and need the giant tool to do it for you.
| spankalee wrote:
| Web components only solve the interoperable, encapsulated
| component problem.
|
| Rendering libraries like Lit handle declarative templates, and
| there are many state management solutions, the same ones you
| can use with React, etc.
| sesm wrote:
| Encapsulated - yes.
|
| Interoperable - can you expand on this?
| ArinaS wrote:
| I wouldn't call a website automatically loading 7 scripts on your
| single visit "vanilla web" though.
| kmoser wrote:
| Why? The first line of the site explains:
|
| > An explainer for doing web development using only vanilla
| techniques. No tools, no frameworks -- just HTML, CSS, and
| JavaScript.
|
| You're thinking of a lightweight site, which this isn't
| claiming to be.
| jay-barronville wrote:
| In theory, "de-frameworking yourself" is cool, but in practice,
| it'll just lead to you building what effectively is your own ad
| hoc less battle-tested, probably less secure, and likely less
| performant de facto framework.
|
| I'm not convinced it's worth it.
|
| If you want something a la KISS[0][0], just use
| Svelte/SvelteKit[1][1].
|
| Nowadays, the primary exception I see to my point here is if your
| goal is to better understand what's going on under the hood of
| many libraries and frameworks.
|
| [0]: https://en.wikipedia.org/wiki/KISS_principle
|
| [1]: https://svelte.dev
| ricardo81 wrote:
| As someone with a 'full stack' history (ie basic front end
| knowledge compared to a full-timer on that coal face every day),
| I do notice a lot of the stuff jQuery does is now native to the
| browser, like being able to use fetch with promises in a few
| lines of code, or select stuff with querySelector(All)? or xpath.
| Then all the nice additions to CSS (and HTTP, no more sprites)
| that weren't possible in the past and remove the need for
| frameworks.
|
| I tend to rely on Bootstrap so the layout is reasonable on
| mobile- but that's purely through my own lack of experience.
|
| But I guess someone with a more intimate knowledge can easily get
| the idea of building a framework. Then add on all the use cases
| and feature requests...
|
| Some web pages, particularly traditional media websites are
| absolute hell holes of bloat, but I guess that's more about their
| ad serving than lean web development.
| phoronixrly wrote:
| Man, the example web components seem to work great if you wish to
| hide data from scraping and search indexing... And if you try to
| work around this, you end up with something very very similar to
| https://stimulus.hotwired.dev/ .
| pajamasam wrote:
| > the example web components seem to work great if you wish to
| hide data from scraping and search indexing
|
| Interesting. Why do web components have this effect, but some
| JS frameworks apparently do not? Or do they all?
| kdbuck wrote:
| Reminds me of this classic: http://vanilla-js.com/
| kdbuck wrote:
| Also, http only. Tell me you are a site from the before time
| without telling me you are a site from the before time.
| int_19h wrote:
| What value would HTTPS possibly add to the website in
| question?
| vaylian wrote:
| It makes it harder for ISPs to inject ads:
| https://superuser.com/questions/1087669/blocking-the-isps-
| ad...
| pests wrote:
| Funny story, I have a comment chain here from a few years ago
| with someone who didn't realize it wasn't actually a framework.
| Total _woosh_. Lumped it in with the other frameworks and
| dismissed them all in the same sentence.
| ntaso wrote:
| Well, it's totally likely. But there is VanJS, which calls
| itself a vanilla JS framework, which adds to the confusion:
| https://news.ycombinator.com/item?id=36067983
| sn0n wrote:
| I missed the part where they show how to do something similar to
| ejs or PHP HTML includes for things like header.html and
| footer.html.
| laurentlb wrote:
| That's how I wrote my website a long time ago.
| #include "header.htm" <h1>Title</h1> ...
| #include "footer.htm"
|
| I'm still using it, and I wonder when I'll be able to get rid
| of PHP.
| d_burfoot wrote:
| Note that you can make things even simpler than this: just use
| vanilla JS to compose HTML strings, and plug them into divs using
| innerHTML = "...". When your state changes due to user input,
| just rebuild the page using the new data.
|
| I've been building many simple apps using this technique, it
| works fine. I'm sure there is some kind of performance hit; it's
| almost never an issue. I have never seen any browser
| compatibility issues.
| euph0ria wrote:
| Beware of xss
| busymom0 wrote:
| Make sure to sanitize the content before inserting if you use
| this approach.
|
| > Warning: This is a security risk if the string to be inserted
| might contain potentially malicious content. When inserting
| user-supplied data you should always consider using a sanitizer
| library, in order to sanitize the content before it is
| inserted.
|
| https://developer.mozilla.org/en-US/docs/Web/API/Element/inn...
| reassess_blind wrote:
| Anything with user input I just use innerText.
|
| Or a simple escapeHTML function within the innerHTML - but I
| prefer innerText in a separate pass, as using escapeHTML as a
| pattern gives an opportunity to forget to use it.
| hdjrudni wrote:
| If the thing you need to input contains inputs, you're just
| throwing the user's content away.
| lelanthran wrote:
| Setting innerHTML is dangerous if it is a value that came from
| user input.
|
| Users will be able to inject cross site scripting attacks into
| the forms of other users.
|
| Not saying to never sit, just saying to be aware of injection
| attacks on the front end.
| zelphirkalt wrote:
| On one hand this approach is simple, but on the other hand I
| dislike treating HTML as a mere string, when it is actually a
| tree and treating it as such is a huge enabler, that many
| frameworks miss out on.
| derekzhouzhen wrote:
| Yes, you can kiss reactivity good-bye and just render the whole
| page on any state change.
|
| No, generating HTML string and setting innerHTML is unsafe and
| slower than necessary. It is better to create DOM elements
| programmatically. HTML is for serialization of the DOM tree; if
| everything is done in javascript then you don't need HTML as an
| intermediate step.
| encom wrote:
| <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
| "http://www.w3.org/TR/html4/strict.dtd">
|
| Anything more is for the kids on my lawn.
| donohoe wrote:
| 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 framework eventually (I do appreciate how their
| opinionated structure can cut down on endless debates), but for
| now, plain JavaScript serves us really well.
| pmdr wrote:
| Congtats! Usability should be a first class citizen. Instead we
| seemed to have perfected the art of loading screens,
| "hydrating" components, time & power consuming animations and
| annoying modals.
| eduction wrote:
| Kudos, the site feels really snappy and I've definitely come
| across the journalism before.
|
| Any sharp edges to this approach?
| nzgrover wrote:
| In my experience, the sharp edges are browser compatibility
| issues, and I've been gratefully avoiding them for years by
| using jQuery.
| CharlesW wrote:
| Ahhh, the beauty of WordPress-generated static pages.
| lelandfe wrote:
| 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.
| rjh29 wrote:
| 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.
| zdragnar wrote:
| That's because backend-rendered sites need a shit load of
| caching. SPAs tend to just use APIs that aren't cached.
| moritzwarhier wrote:
| That's primarily because many SPAs aggressively prevent
| caching of all xhr responses using headers (which are ofc
| defined from the BE side)
|
| And the reason for that is mainly to prevent edge cases
| and make sure people in CRUD apps see up-to-date content.
|
| The experience with a no-cache max-age=0 server-rendered
| site would be very similar.
|
| All of the headaches around custom routing code +
| restoration of state are pretty much obsolete wirh
| bfcache, introduced more than 5 years ago.
|
| If you build a dynamic page and use HTTP headers to
| prevent caching, stop complaining about it. Most people
| making this argument want to offload dealing with
| external APIs to the frontend, and then complain about
| the result when no requirements around API response
| caching were defined, let alone time was given to define
| them.
| zdragnar wrote:
| No, this proves my point. Back in my days of backend
| programming, Varnish was the "magic" that made servers
| (especially CMSs) feel fast. Memcached is another common
| go-to cache.
|
| Browser caching isn't a replacement as the first request
| for every endpoint is still going to be slow.
|
| Yet somehow, APIs aren't treated with the same
| requirements for performance as web pages.
| SquareWheel wrote:
| 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.
| lelandfe wrote:
| And frankly, most big sites in my experience break
| bfcache. For instance: YouTube, Gmail, NYT,
| steampowered.com, CNN. All have broken bfcache in Chrome.
| atoav wrote:
| As a fellow vanilla-fan: If this shows anything, it shows how
| bloated modern web development has become. Your page is snappy
| as hell.
| insin wrote:
| Modern static content web development is in some of the best
| health it's ever been in with the likes of Astro.
|
| You get your lovely developer experience with components,
| with the same component API enabling layouts for the
| repeatable outer structure, easy composition of reusable
| parts of your content, ease of passing data around between
| these and implementing any logic you need before rendering or
| inside what you're rendering.
|
| The user gets a snappy, static website.
| metabagel wrote:
| Blazing fast. Wow!
| hoherd wrote:
| I thought this was sarcasm, so I loaded the page, and yeah,
| that is an insanely fast cold load time, and even more
| impressive once the resources are cached.
| electroly wrote:
| While I think your page is excellent and loads great, I don't
| think this is related to the approach described by TFA. You're
| using the biggest framework around: WordPress. You're just
| static rendering it. TFA is talking about _no build tools at
| all_ , using modern web standards, and specifically nothing
| requiring preprocessing. "... just an editor, a browser, and
| web standards" is a quote from the page.
| andrewstuart wrote:
| No user cares about 100K.
| austin-cheney wrote:
| They care about time and they absolutely do care. If your
| giant virtual DOM mess takes 10x longer to respond on every
| user interaction they will absolutely notice. It's just the
| developers that don't care because deviating from the
| framework puts their job at risk.
| someothherguyy wrote:
| > 10x longer to respond
|
| 10x longer than what?
|
| > It's just the developers that don't care because
| deviating from the framework
|
| You realize that many major modern (and legacy) web
| frameworks started inside companies?
| austin-cheney wrote:
| 10x longer than not using that framework and yes, I do
| realize that.
| lolinder wrote:
| 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 requires, and the answer is that it doesn't handle
| those features because it doesn't require them because it's a
| blog.
|
| Meanwhile there are also a lot of people on here who have never
| worked on a large-scale web app and wonder why frameworks even
| exist when it's so obviously easy to build a blog without them.
|
| It would be nice if we could just agree that the web hosts an
| enormous spectrum of different kinds of software and make it
| clear what kind of software we're talking about when we were
| opining about frameworks--whether for or against.
|
| In this case: this is a WordPress blog.
| dorfsmay wrote:
| On the third hand, some people use React and some framework
| to write static web page...
| lolinder wrote:
| And if you can point me to an example of that I will
| happily lampoon them.
|
| If we're talking about Medium, then yes, Medium is a
| complete disaster zone that should not be emulated
| anywhere. Their reader-facing use case does not require
| JavaScript at all except as a light optional seasoning on
| top.
|
| All I'm saying is that we need to actually talk about use
| cases whenever we're talking about frameworks, which we
| almost never do. Failing to specify the use cases turns the
| conversation incoherent because we end up having two
| different conversations without even realizing it.
| austin-cheney wrote:
| The primary use case for these large frameworks is
| hiring.
| prisenco wrote:
| Not just some people. There are a wildly unnecessary amount
| of marketing pages and pages with basic forms that are
| built using React.
|
| Every time I've been at a company and suggested moving to
| vanilla css+html or a static generator, the reaction is
| like I brought up rewriting in assembly.
|
| There needs to be a significant push for simplification of
| the default toolchain. I understand using React, but
| reaching for it by default at the beginning should be seen
| as unnecessary complication.
|
| Especially because it's 100x easier to move from html+css
| to a framework than it is to move from a framework to
| literally anything else.
| sanderjd wrote:
| 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.
| prisenco wrote:
| Until you have a definitive answer, err on the side of
| simplicity.
| tomnipotent wrote:
| 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.
| sanderjd wrote:
| You never have a definitive answer. It's always
| probabilistic. You make the decision that you think has
| the highest odds of success at every point in time.
| prisenco wrote:
| Success for the current requirements? Or success for an
| imagined future?
| sanderjd wrote:
| For an imagined future.
|
| If you're building something with specifications, then
| what are we even talking about? You know what you need to
| build so just build that.
|
| But this thread is about what to do when you don't know.
| "Start the simplest way" is not always the right answer,
| because you have some information about what you plan or
| want or hope to build, so you can use that information.
| Not everything is a set of hyperlinked webpages, and you
| often know that right away, even when you don't have many
| details sorted out at all.
| prisenco wrote:
| We have a fundamental difference of philosophy.
| sanderjd wrote:
| What is your philosophy?
| xigoi wrote:
| > A complex system that works has evolved from a simple
| system that worked. A complex system built from scratch
| won't work.
|
| --John Gall
| sanderjd wrote:
| I'm not suggesting building a complex system from
| scratch. I'm suggesting building systems using tools
| designed to support the kind of system you're building.
|
| Do you think your quote is true in all cases? Or are you
| implying that choosing to build using a framework implies
| building a complex system frame scratch?
|
| Consider a different kind of system. Does every triple-A
| video game evolve from a simple framework-free
| implementation, or do most of them choose a graphics
| engine to build on top of? If a game studio chooses Unity
| from the start, for instance, is it building a complex
| system that won't work?
|
| How is it any different to choose a web application
| framework from the start when building a web application?
| ummonk wrote:
| 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.
| sanderjd wrote:
| 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.
| zarzavat wrote:
| Why not use React for that? If I use React for everything
| then I don't have to decide, I don't have to use two
| different tools. Consistency is fantastic, if you only
| use nails then you only need to carry a hammer.
|
| Why use two incompatible languages (JSX and HTML) for
| different types of web pages, when you could just always
| use JSX? React can statically render to HTML if your page
| is really static.
|
| I think what you're really complaining about is that
| people use React for static content and don't statically
| render it first. That is sloppy, I agree. But it's not
| React itself that's the problem but rather the developers
| who don't care what they are doing.
| MrJohz wrote:
| In theory, you can completely statically render
| everything. In practice, every static site I've seen
| built with React also uses dynamic client-side
| components, either as a prerendering mechanism, or
| because there are dynamic toggles and things on the site
| that are easiest to build as React components. This
| usually means that a lot of excess Javascript gets loaded
| on the client that isn't usually necessary.
|
| The islands/RSC work seems to offer some improvements to
| this, but most of these websites still include a full
| copy of React on the page to essentially do what the
| speculation rules API and a `<dialog>` element could do
| just as easily.
| prisenco wrote:
| HTML will be around long after React is dead. What
| guarantee does a React codebase have that its toolchain
| will still work in 5 years? We've seen build tools come
| and go, whole approaches deprecated. What if a security
| update requires upgrading to a non-compatible version of
| React, therefore necessitating a considerable refactor?
|
| Meanwhile, the original Space Jam website still renders
| perfectly.
|
| The standards are superior to the frameworks built on top
| of them. Abstractions come and go, but web standards,
| once adopted, have a solid track record of sticking
| around.
| dismalaf wrote:
| There's a shocking amount of people who don't know that
| vanilla JS is a thing... They _only_ know React...
| llbbdd wrote:
| haven't observed this at all
| evbogue wrote:
| It's mostly younger people
| atoav wrote:
| Maybe there is this disconnect, but half of the react
| developers I personally met used react: "because it is good
| on resumes and I don't understand how to work without a
| framework". So I am not entirely sure we have the whole
| picture here.
|
| I also write more complex webapps using vanilla webtech (with
| a strong server-side solution like flask, django or similar).
| I checked out react it just hasn't clicked yet for me in
| combination with my serverside style.
| Swizec wrote:
| 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 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. Now as a user you're confused: did
| you place the order or not? You got an error but the order
| also showed up in your history. Hmmm
|
| As engineers we have issues understanding what is and isn't
| in scope. 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 pages did you just cause? Where
| does the data even get loaded?? The query lives so far away
| from where you use the data that it's really hard to track
| down. Etc
|
| We started putting new things in React, especially the more
| interactive areas of the site. It's pretty nice in
| comparison. Not perfect, but the framework pushing you to
| think in components helps a lot. I'm slowly introducing this
| mentality to other parts but the framework really wants to
| fight you on it so it's gonna take a while.
| sanderjd wrote:
| 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.
| Swizec wrote:
| Oh I was hired _because_ I've been here before and know
| what to do. It's fast becoming a career specialty lol
| arkh wrote:
| 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".
| sanderjd wrote:
| 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.
| degamad wrote:
| 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 pages did you just cause?
|
| > Where does the data even get loaded??
|
| Doesn't this just change into
|
| - "Will changing this React component affect only the
| feature I want, or do other pages interact with it
| differently?"
|
| - "When adding a new component into a template, will I
| break any other pages which use this template?"
|
| - "Where does the data even get loaded??"
| Swizec wrote:
| > 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.
| t-writescode wrote:
| Thankfully, there's a bunch of great and "easy to get
| going" languages now that __also__ have types (or
| optionally encourage them) that the "don't have types"
| thing isn't as much of a forced issue anymore (though
| engineers can still choose to go type-free and eventually
| face the wrath of lack of types in a large-scale project)
| zelphirkalt wrote:
| 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 path to rendering a page
| should be pretty clear. Have some weird JS requiring menu
| functionality? Well ... put it in "menu.js". Will it affect
| 50 other pages? No, it will affect the menu. Or yes, if you
| count the menu as part of those pages. Have some video
| player stuff? Well it is going to affect all pages where
| there is the video player. Something for forms? All pages
| where you have such forms. Then there are things like maybe
| animations or checkbox states. But I fail to come up with
| examples, where the scope of the change is so unclear, that
| one can't relatively quickly figure out what will be
| affected and what not. It must be some WordPress mess or
| something. Then I can imagine it. But with a site built
| from ground up? Nope, must be bad design or structure.
|
| Of course you could just have made up that example as a
| straw man as well.
| Swizec wrote:
| > 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-
| popu...
|
| > Well ... put it in "menu.js". Will it affect 50 other
| pages? No, it will affect the menu
|
| MVC frameworks, used traditionally, don't support this
| super well. If you want some dynamic value in the menu
| supplied by the backend, every view has to make sure it
| passes that value into the template layer. Change the
| menu, gotta go around changing every view to supply that
| new value.
| threetonesun wrote:
| 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.
| Swizec wrote:
| > why the menu is tied to the view at all, and not
| deriving its state from the user session
|
| Yes! But it turns out in some of these frameworks "the
| user session" is not a magic global, your view has to
| pass it into the template.
|
| And even if it was a global, you are super limited in how
| much derived data/queries you can compute off of it.
| Because you're not using a full-powered language -
| instead it's jinja, mustache, or similar.
| fenomas wrote:
| This is doing the same thing described in the GP of your
| comment.
|
| If 1/few people are building a site so simple that the
| menu code is in "menu.js", then sure, separate your code
| and go about your day. But when 30+ FTEs are building a
| huge app with lots of tightly interconnected features,
| then the complexity is there no matter how you architect
| your code - it's part of the business requirements. Like
| GGP said, they're different domains, and stuff said about
| one doesn't necessarily apply to the other.
| leptons wrote:
| >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 25 years to
| disable the submit button once it is pressed. If you aren't
| doing this as a developer, you are practically _begging_
| for trouble, and it 's really so easy to avoid that
| trouble.
| Swizec wrote:
| 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 :)
| NohatCoder wrote:
| At least adding in the feature once you notice the
| problem shouldn't be difficult.
| ardleon wrote:
| Or disable the component completely until you receive a
| response.
| mixmastamyk wrote:
| I'd approach this with a wizard-style (step by step)
| interface and transactions--orthogonal to JS framework.
| a4isms wrote:
| Many years ago--2002!--Joel Spolsky wrote this:
|
| https://www.joelonsoftware.com/2002/05/06/five-worlds/
|
| His thesis was that before arguing about software development
| tools, practices, anything really, it's vital to establish
| what kind of development you're doing, because each "world"
| has its own requirements that in turn motivate different
| practices and tools.
|
| The worlds he quoted were Shrink-wrap; Internal; Embedded;
| Games; and Throwaway. Shrink-wrap is no longer a thing for
| most developers, and we can probably name some others today
| that didn't exist then. But the basic advice he gave then
| matches what you're saying today:
|
| We need to anchor arguments about tooling in a statement
| about the type of development we're trying to address, and we
| need to appreciate that the needs of each world are
| different.
| sisve wrote:
| 100% this. The biggest problem I see is understanding the
| context of what you are building. Even inside a SaaS
| company. Are you building a feature that is a core part of
| the service or just a test shot to see if its possible to
| sell,or maybe you already sold something to a customer that
| is not your target customer. Yhey still need it and should
| get it. But maybe its more important to be quick and dirty.
| if its a core part, Then you need to make sure the
| architecture is good and maybe even add more test then
| normal. Context matter so much
| kalaksi wrote:
| This is also why it's often frustrating to try to
| understand people's opinions regarding programming and
| code. There's almost always too little context, even
| without handwavy or subjective stuff like "it's too
| complex" or general bandwagoning.
|
| Actually, I feel like many times the conversations about
| code are pretty shallow anyway with not much info. Maybe
| it's just difficult without properly established context
| but OTOH that can quickly get complicated and require a lot
| more effort.
| 90s_dev wrote:
| That was one of the most interesting reads I've read in a
| while, thanks.
| Cthulhu_ wrote:
| So much great and timeless stuff was written in the
| 2000's, it's great and should be part of everyone's read
| list. Another one that's still pretty timeless is
| https://randsinrepose.com/
| kerkeslager wrote:
| I agree with Spolsky in theory. But in practice, I've been
| on _one_ project in the last few decades which I actually
| think benefited from integrating a web framework. The
| majority of projects I 've worked on absolutely did not
| need JavaScript, and the rest would have been served by an
| approach similar to what's described in the OP--a few
| minimal vanilla JS files to create a few web components.
|
| And yet large teams of very smart people reach for NPM as
| just part of their initial setup process. It's so
| ubiquitous that I essentially had to learn to not write
| this way on my own, by asking myself "can I do this without
| JS"? Almost every time I asked that question, the answer
| was "yes", and the non-JS way was much easier. But for a
| long time I wondered if I was wrong--maybe the framework JS
| way is easier in some way I don't understand--because
| everyone around me was doing it the framework JS way. It's
| taken me years of experimentation to build up a
| preponderance of evidence to persuade myself that in fact,
| the framework JS way is just worse, most of the time.
|
| Everybody wants to be Facebook or Google, but the fact is
| you probably just aren't. You probably don't have their
| problems and you probably don't need to use their tools.
| jaza wrote:
| Thanks for the JoS link, a thought-provoking read as
| always! (And it doesn't feel like a 23-year-old blog post -
| love your work Joel).
| hahn-kev wrote:
| I think a really good example of this is that lots of times
| even when making a web app, different people make the web
| app from the people who made the marketing site for selling
| the web app.
| int_19h wrote:
| Shrink-wrap is still very much a thing, even if
| distribution is entirely digital in most cases. It's
| dominated by internal line-of-business apps, sure, but that
| was true back then also.
| a4isms wrote:
| True!
|
| Of course, Shrink-wrap 2020-2025 is not exactly the same
| as Shrink-wrap 1995-2000. You mentioned digital
| distribution. Speaking from my lived experience... We
| shipped software on golden masters that were used to
| manufacture DVDs at scale.
|
| At that time, the entire software industry worked on long
| release cycles because of the friction of shipping
| software on manufactured media. And in those days, people
| read physical dead tree computer magazines, which had
| long lead times for articles. This affected software
| development, because months before we were scheduled to
| "ship," we were sharing screen shots with journalists,
| doing interviews, and placing stories in magazines timed
| to drop when we released.
|
| I remember a death march to get a product ready so that
| we'd have DVDs to give away at JavaOne in the Moscone
| Center, where our CTO was scheduled to give a talk. The
| way software was distributed in those days all strongly
| influenced the way companies attempted to manage software
| development.
| wim wrote:
| We're building a collaborative IDE for tasks and notes [1]
| from scratch without frameworks/dependencies.
|
| Not saying frameworks are never the right answer of course,
| but it's as much a trade-off for complex apps as it is for
| blogs. Things like performance, bundle size, tooling
| complexity, easy of debugging and call stack depth, API
| stability, risk of hitting hard-to-work-around constraints
| all matter at scale too.
|
| [1] https://thymer.com/
| lolinder wrote:
| Agreed that it's a trade-off. In your case I probably would
| have made the same call. Again, though: that's why use
| cases matter. Web app/blog is only one dichotomy--the most
| common two types of web dev but far from the only.
| ismi wrote:
| I love it! All ES6, no deps.. probably makes your lives
| harder than they should be but in the name of pureness and
| badassery and complete control over performance, awesome!
| You choose to suffer for the right reasons. Wishing you the
| best of luck and that I can try it soon.
|
| Forgot to say.. I very much admire and appreciate the
| aspect of "ejectability". More software should strive for
| this ideal.
|
| https://thymer.com/ejectable-apps
|
| I read that and nod all the way through. Hope you succeed!
| donohoe wrote:
| 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) was run on WP too for
| a time. Its used by many major publishers.
|
| If you look at other news sites, be it NYTimes, Polygon,
| Verge, Wired, etc, most of them use frameworks to some
| degree. React, preact, svelte, whatever. It works for them.
| Underscore, and Backbone are two frameworks that were
| developed at the NYTimes. Its not alway necessary, and you
| can still do a lot without them.
| lolinder wrote:
| 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.
| a4isms wrote:
| 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.
| lolinder wrote:
| 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.
| a4isms wrote:
| Oh, I do believe we're in general agreement!
| coldtea wrote:
| > _that their use case absolutely requires_
|
| This is where those people and teams are wrong.
| lolinder wrote:
| 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.
| slater wrote:
| > 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.
| lolinder wrote:
| If you assign a value judgement to that statement that's
| on you, not me. I was just providing the missing context:
| _why_ OP didn 't need a frontend framework to meet their
| requirements.
| slater wrote:
| Well, at least you found your category.
| tayo42 wrote:
| I feel this about just about every k8s discussion that comes
| up.
|
| I kind think that if your discussing tech about the web you
| need to include the scale and your experience.
| sanderjd wrote:
| Sites vs. applications. It's important to know which you're
| building.
| aucisson_masque wrote:
| > 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 ?
| lolinder wrote:
| 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.
| aucisson_masque wrote:
| Holy moly, that's pretentious.
|
| I was genuinely curious because i never faced the kind of
| issue a web development team would have, it wasn't about
| counter argumenting.
|
| You could have just said "x and y".
| lolinder wrote:
| I'm not trying to be pretentious, but wrangling an HN
| thread is hard and I don't have time to get into an
| argument about a bunch of different implementation
| details. Rather than just ignore your post I decided to
| respond explaining why I couldn't answer.
|
| The only valid short answer is what I said: that it
| really depends on the details and how they all work
| together. I truly can't give you features in isolation
| that won't be questionable, because the decision hinges
| on the whole combination of factors. Had I said "x and y"
| someone would have come along and argued that X and Y
| didn't call for a framework because Z. Me identifying the
| two points would have accomplished nothing and would
| actually have undermined my primary point of "it
| depends".
|
| Edit: btw, I just corrected the downvote on your original
| post with an upvote. Whoever did that probably assumed
| you were being belligerent, but that's not fair.
| aucisson_masque wrote:
| Well thank you for at least being willing to reason.
|
| I get its complicated, wasn't trying to nail you or web
| framework.
| kybernetikos wrote:
| > 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.
| lolinder wrote:
| 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.
| ozim wrote:
| 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.
| filchermcurr wrote:
| I don't really have anything to add to the conversation at
| hand, but Photopea looks pretty cool. Thanks for sharing!
| ozim wrote:
| Fully support the comment.
|
| Those kind of posts are the same as ORm vs plain SQL or Scrum
| vs whatever.
|
| Time wasting at best, misdirection of inexperienced at worst.
| mickael-kerjean wrote:
| > 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 reason than people choose IBM: nobody get
| fired for choosing IBM / React.
|
| [1] https://github.com/mickael-kerjean/filestash
| lolinder wrote:
| 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 help, chosen because the site OP shared is
| functionally the same as a blog. Other applications have
| different requirements and those requirements _may also_
| not benefit from a framework. Alternatively, the
| requirements themselves may _actually_ have benefited from
| a framework and the authors chose to avoid them because the
| team preferred not to or because they felt strongly about
| avoiding frameworks because of personal preference.
|
| In this case, this project has really one active
| contributor [0], so it's missing one of the key ingredients
| that in my experience really call for a framework:
| coordination between a large number of people.
|
| (And lest I be mistaken: just because a project has a large
| number of people _does not_ mean a framework would for sure
| be the best choice. I 'm sure there are counterexamples to
| that too! It's just a hint in that direction, not an
| ironclad law.)
|
| [0] https://github.com/mickael-
| kerjean/filestash/graphs/contribu...
| BostonFern wrote:
| > 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.
| andrewrn wrote:
| I like this framing the most. My personal website is vanilla,
| and my SPA-like apps are with React. I originally chose
| vanilla for my personal website bc I thought it'd keep
| refreshing my fundamentals... but actually its simple enough
| that vanilla is actually just the correct choice.
| chaboud wrote:
| Absolutely, and this sort of thing happens in large companies
| as well.
|
| Software engineers are great at providing "well, why don't
| you just.." answers to problems they don't actually have
| their brains wrapped around. This often leads to attempts to
| scale poorly scaling approaches (e.g., we'll just bake every
| variant, since there are only four today - which becomes
| combinatorially intractable after a few years of
| development).
|
| On the flip side, software engineers are _also_ great at
| choosing how they're going to solve a problem before they
| really have a handle on what they're going to solve.
|
| I use this maybe 5-10 times per year (and several engineers I
| work with have taken to repeating it): "tell me what you're
| doing but, more importantly, tell me what you're _not_
| doing."
|
| Forcing people to be explicit about what is not in scope
| helps to bring clarity to otherwise murky tangles of
| ambiguity.
| eduction wrote:
| > It would be nice if we could just ... make it clear what
| kind of software we're talking about when we were opining
|
| Irony here is that OP did precisely this with a link to the
| precise thing he built. Meanwhile you haven't offered even a
| rough description of what you built, much less a link.
| evantbyrne wrote:
| > I think that this comment is a great example of the total
| disconnect these conversations always have.
|
| If we're being fair, the same could be said of this comment,
| which goes on to make some assumptions. One guy giving an
| anecdote that is not a web app does not prove much. I've
| built award winning web apps with progressive enhancement. It
| takes less code, less time, the performance is better, and
| they can be just as interactive. We need to stop looking for
| the weaknesses in each other's arguments and look for their
| strengths. I'm guilty of this as well.
| lolinder wrote:
| I think you're reading into my comment implications that I
| didn't intend to put there. The point is that situations
| differ and we need to be explicit about what kinds of
| situations we're talking about when we're sharing our
| opinions on the suitability of frameworks. I'm not
| advocating for or against frameworks in any particular
| situation.
| evantbyrne wrote:
| That seems like a good take to me
| jemmyw wrote:
| Nice site, I found some interesting stories.
|
| I do find it a little annoying that when we have these
| discussions about vanilla vs frameworks people hold up an
| example and I go there and see a news site of articles rather
| than a complex application, and I think to myself yeah I
| wouldn't have used a framework in this situation anyway. It's
| annoying from 2 directions: the first that people ARE using
| frameworks for sites that shouldn't have ever had them in the
| first place, and I can bring to mind a couple of news sites I
| visit regularly where this is obviously the case because of the
| silly ways they work. Secondly that this is then held up as an
| example, because most of my work is on very interactive sites
| so I end up thinking well yeah but that's not going to work for
| me is it. My feeling is that I could do vanilla but would end
| up with something like a site specific framework.
|
| My current approach is to use a framework and consistent
| patterns but to try and use as few other dependencies as
| possible.
| eviks wrote:
| Not sure if it's no-framework related, but navigation
| back/forth is sometimes broken: the url changes immediately,
| but the page doesn't update and stays on the same article.
|
| Also infinite scroll breaks the most basic usability issue -
| you can't track where in the article you're with the scrollbar
| positioning
| ntnsndr wrote:
| I love Rest of World! Great work!
| pier25 wrote:
| > _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.
| chillpenguin wrote:
| shoutout to Mithril! Has always been an under-appreciated
| gem.
| pier25 wrote:
| maybe you'll be interested to know v3 is in active
| development
|
| https://github.com/MithrilJS/mithril.js/pull/2982
| andoando wrote:
| My problem with all this vanilla showcases is they are dead ass
| simple pages with the most basic layouts and user interaction.
|
| Shit just show me how long it takes you to create a nice
| reactive table with search or a form with proper labels, user
| interaction, validation, errors, etc
|
| Why would I implement that all from scratch when I can install
| svelte install a UI library and add a couple lines of code, all
| with a 25kb overhead and get a better, nicer looking, more well
| tested product that would take you to do in a week?
| claytongulick wrote:
| Increasingly, this is actually an argument in favor of
| vanilla web components.
|
| The WC ecosystem has grown a lot, and one of the great things
| about native web components is that they can be consumed by
| most major frameworks at this point. There are also many
| mature component sets you can pick from, like shoelace,
| etc... you can mix and match components from different
| offerings, something that's not practical with React/Angular
| (for example).
|
| I can use a select from Ionic, a breadcrumb from Shoelace,
| and a date picker from Lightning and it'll all just work.
|
| Doing vanilla Javascript development doesn't mean "don't use
| any libraries" (well, it might to purists, but whatever) it
| means stick to using standards based technologies with
| libraries and accelerators.
|
| For example, I use many of the techniques described by the
| site, but I prefer to use lit-html library (NOT lit
| framework) for rendering.
|
| Sometimes I use the vaadin router for routing, sometimes the
| Ionic router, sometimes my home grown one.
|
| I use a little library I wrote called ApplicationState for
| cross component shared state, because I don't like state
| being coupled to my DOM structure.
|
| Sure, this requires a deeper understanding than "batteries
| included" frameworks, but the advantages outweigh the
| negatives IMHO.
| andoando wrote:
| If you use a bunch of libraries for routing, UI,
| authentication, the only thing thats left is the rendering.
|
| And quite frankly I don't see why Id want to reinvent the
| wheel there.
|
| {#each notes as note} {note.content} {/each
|
| is exactly what Id want to implement for example if I were
| writing JS functionality to render a collection.
|
| And Svelte for example doesnt restrict you from using
| vanilla JS whenever you want either
| claytongulick wrote:
| It's not reinventing the wheel, it's more like not
| putting snow chains on your wheel when it's summer.
| int_19h wrote:
| Does your "nice reactive table with search" retain its
| current state (including scrolling!) if I click on a link
| that opens another page, and then back out?
|
| Does it let me link to page N of results?
|
| As a user, I find that, in practice, it's these kinds of
| things that frustrate me far more than the lack of instant
| reactivity, whereas simple form with a submit button and a
| paginated table below works just fine.
| andoando wrote:
| Implementing state isnt very difficult.
|
| I think youre thinking of a very static use case again.
| Link to page number doesnt make too much sense when the
| data changes (and do you really want to refresh the whole
| page just to change the table data?), but yes thats easy to
| implement to.
|
| It would just look something like let pageNum = params.page
|
| <Table defaultPage={pageNum}/>
|
| Now think about if you need to implement a more complex
| table in an admin UI that lets you filter / sort,
| delete/add rows, etc. Thats where reactivity is really
| really nice. All you have to do is something like items =
| items.filter(i -> i.name.startsWith(input)) and youre done.
| littlecranky67 wrote:
| > 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 initial page load. Your users use the app on a daily basis,
| so they get all the JS/CSS/static assets served from their
| browser cache almost all of the time, until we make a new prod
| deployment (usually weeks). Plus, all users are always on
| Ethernet or WiFi at least, not some 3G cellular network
| somewhere in the desert.
|
| If you use some smarter framework like Next.js, you even get
| smartly chunked js parts on a per-route basis, that are
| _immutable_ - they contain a sha256 hash of their content in
| the filename, and we configure the webserver to serve them via
| `Cache-Control: immutable`. There won 't even be a roundtrip to
| check for newer versions.
|
| Plus Nextjs comes with tons of other stuff, like pre-loading
| chunks in the background, or when hovering over a link (i.e.
| using the time between the hover and the click to already load
| a chunk). Let alone that the initial render _is_ static html
| and hydration happens completely unnoticed from the user.
| lolinder wrote:
| This is spot on. Load times _do not matter_ for the kinds of
| apps that:
|
| * Are exclusively loaded on high speed internet in corporate
| networks.
|
| * Have a high hours-of-work-per-page-load count.
|
| * Update infrequently.
|
| We're engineers, or at least we like to call ourselves that.
| Engineering is the process of gathering requirements and
| building a system that meets those requirements on time and
| under budget. If your requirements include being able to
| serve users on 3G networks or users who only load your site
| in order to read a single piece of content per day, yeah,
| optimize your load times. But don't attack other engineers
| for failing to live up to _your app 's_ requirements.
| zelphirkalt wrote:
| 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.
| littlecranky67 wrote:
| It is _NOT_ a big if, because by default, caches are not
| deleted on shutdown. Plus, in a corporate environment, the
| windows installations are centrally managed and won 't be
| configure to do so. But coming back to the original
| argument: If there is no caching, your SSR is never going
| to be fast too.
| worldhistory wrote:
| what? that is impossible
| jimbob45 wrote:
| _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.
| robertoandred wrote:
| 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.
| donohoe wrote:
| I believe the topic is front-end frameworks. WP is used as a
| CMS but the entire front end is built from scratch.
| bigtones wrote:
| Rest of World looks like a fantastic news website I was not
| familiar with. I just spent a half hour reading a whole bunch
| of interesting articles there. Well done for helping build it -
| its super fast from Australia.
| ummonk wrote:
| What do you even need JS for on that site? It looks like it
| should be doable with plain HTML.
| vivzkestrel wrote:
| So you are the guys behind this amazing news website. What made
| you build this and is the target audience American? If you
| don't mind me asking, how are you guys monetizing this? Is this
| a funded venture or bootstrapped?
| EZ-E wrote:
| Fantastic website, really happy to be able to finally read
| interesting stories and news about the tech scene where I work,
| in Vietnam
| duc_minh wrote:
| Took me off guard too :D I didn't expect to click on a random
| link on HN and see an article about my home country
| rikroots wrote:
| I recently did a ShowHN post for my browser-based screen
| recording web page side project. 100% vanilla, with added wasm-
| based ML shenanigans. It really is amazing what functionality
| can be built into a web page without resorting to framework
| support!
|
| https://news.ycombinator.com/item?id=43960434
| heyheyhouhou wrote:
| Just wanted to say that I really like restofworld.org. Thanks
| to you and your team for building it.
| EGreg wrote:
| I think there are two separate things.
|
| The static websites and beautiful designs
|
| With a lot of iframes and widgets, running some kind of services
| like Disqus chatrooms were
|
| It's far more secure, too.
| mikebelanger wrote:
| Great resource! I particularly like the fact that their web
| component section doesn't use the shadow DOM. It's really too bad
| custom elements got associated with shadow DOM, as they're so
| useful beyond the more niche usage cases of the shadow DOM.
| troupo wrote:
| > It's really too bad custom elements got associated with
| shadow DOM
|
| Because it was heavily pushed, advertised, and is the default
| way of writing web components (you have to explicitly specify
| mode: open)
| throwitaway1123 wrote:
| > you have to explicitly specify mode: open
|
| The mode does not toggle the shadow DOM on and off. It just
| specifies whether or not the element's shadowRoot object is a
| public property. An open mode makes this possible:
| `document.querySelector('my-component').shadowRoot`.
|
| You have to explicitly opt-in to the shadow DOM either
| imperatively by calling `attachShadow`, or declaratively in
| HTML by giving the element a template child element with a
| `shadowrootmode` attribute.
| troupo wrote:
| I stand corrected!
| mschuster91 wrote:
| From https://plainvanillaweb.com/pages/components.html I see this
| piece: if (!this.#span)
|
| What is _that_ kind of magic syntax sugar?! A shorthand for
| document.getElementById?
| jbreckmckye wrote:
| No, the hash is a red herring. It's a way of signifying a
| private field on an object.
| mschuster91 wrote:
| Ah. Thanks, that hint pointed me to [1]. Seems like it's been
| supported by every major browser since 2021, and only
| specified in the upcoming ECMAScript 2026 spec.
|
| [1] https://developer.mozilla.org/en-
| US/docs/Web/JavaScript/Refe...
| jbreckmckye wrote:
| It has a contentious history and largely was forced through
| by one person in TC39 who focused on a particular corner
| case
| lenerdenator wrote:
| From the people who brought you vanilla-js.com
|
| http://vanilla-js.com/
| deepsun wrote:
| > 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
| <a> elements, without adding `class="alib-link"` all the time.
| It's easy with a CSS-preprocrssor, but how to avoid using one?
| alwillis wrote:
| > I would want to set it for all <a> 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.
| neiman wrote:
| I did a small project last week _. It 's completely vanilla and
| works great. It's a web tool for writing long threads for
| Mastodon.
|
| I kept on wondering while making it if I was doing it wrong
| without any framework. Because that's what everyone else seems to
| expect.
|
| _ Splinter, splinter.almonit.club, if anyone cares.
| spoonsort wrote:
| Be wary of building a website without a framework to abstract
| stuff like DOM usage and page generation. Raw webdev is _hard_ ,
| due to lots of compatibility issues at every level (CSS, HTML,
| JS) and are moving targets. You shouldn't even try it until you
| understand protocol design and have implemented some medium
| complexity standards like IRC and a basic DNS client or server.
| lenkite wrote:
| If they just had HTML imports and template substitution, you
| wouldn't need Javascript nor web components for a lot of apps.
| andrewstuart wrote:
| I'm building a plain vanilla web application right now.
|
| The main reason is I want direct control of the DOM and despite
| having 10 years or more react experience, it is too frustrating
| to deal with the react abstractions when you want direct dom
| control.
|
| The interesting thing is that it's the LLM/AI that makes this
| possible for me. LLMs are incredibly good at plain JavaScript.
|
| With an LLM as capable as Gemini you rarely even need libraries -
| whatever your goal the LLM can often directly implement it for
| you, so you end up with few of no dependencies.
| daitangio wrote:
| Hum for me vanilla is html+css. If you throw in javascript
| language, I do not see the 'vanilla' anymore :)
|
| I ended up using hugo + isso (for commenting) and it works very
| well. I moved to this setup after the wordpress drama, and even
| if I miss something, freedom has no price:
| https://gioorgi.com/2024/liberta-come-aria/
| rtcode_io wrote:
| https://clock.rt.ht/::code has a sophisticated custom <analog-
| clock> HTML element!
|
| https://go.rt.ht has other custom elements!
| hanlonsrazor wrote:
| Seems like this is more for the hobbyists - building webpages for
| the love of the act. Frameworks are built to be standardized,
| enforce best practices via their design, and allow developers to
| 'hit the ground running', so to speak.
|
| No web site is intrinsically valuable - the information and
| functionality it wraps is what holds its value. Developing the
| access to that information and function, enforcing correctness,
| and the timeliness of that development is what frameworks empower
| orgs to deliver at much lower cost in the present and future, vs.
| vanilla web dev.
| jonahx wrote:
| This is the narrative, of course.
|
| In practice, it is sometimes true, and often not.
|
| You can't overstate how often decisions are large orgs are
| driven by hype, follow-the-herd, or "use popular framework X
| because I won't get in trouble if I do" mentalities. The added
| complexity of tools can easily swamp productivity gains,
| especially with no one tracking these effects. And despite
| being _terrible_ decisions for the business, they can align
| with the incentives of individual decision makers and teams. So
| "people wouldn't do it if it wasn't a net positive" is not an
| argument that always holds.
| codazoda wrote:
| I see absolute messes created out of React and associated
| frameworks. Quite possibly because, "you're holing it wrong".
| Just using a framework is not going to force best practices and
| it's very easy to create terribly bloated and slow systems with
| these tools if you're not thoughtful.
| pjmlp wrote:
| Loved the whole point being made.
| Dwedit wrote:
| When you include "No tools" in your requirements, you're locking
| yourself out of WebAssembly. WebAssembly still requires that you
| have a C compiler that can target WebAssembly binary format. Zig
| works well as a compiler for this purpose, even if it's just
| building C code.
|
| WebAssembly doesn't need to be bloated, I've written a C program
| that imports nothing, and the resulting WASM file is under 3KB in
| size, and there's under 10 lines of code to load it up.
| runlaszlorun wrote:
| Did you find using Zig's compiler better than using LLVM sans
| emscripten?
|
| Tinygo is also on my list to try for Wasm.
| RyanOD wrote:
| This is the approach I took for my side project website. The idea
| of installing a framework and dealing with hosting and whatnot
| just did not interest me.
|
| More importantly, the needs of the site are drop-dead simple so
| no need to install a Ferrari when all I need is a bicycle.
|
| Plain vanilla site served from Github FTW!
| Waterluvian wrote:
| That's exactly what I do. The projects are small enough that
| it's perfect. But it reminds me how insane it would be if it
| was one of my professional projects.
| bl_valance wrote:
| I've been recently going this route, everything is static. If I
| can't host them on an S3 bucket, then I'm building it wrong.
|
| Sites are way too bloated nowadays, a lot of the content being
| served can be static and cached.
| nomaxx117 wrote:
| Web components are honestly the first time I have seen web stuff
| in years and thought "that actually looks nice".
|
| Maybe it's time for me to crawl out of my systems-software-only
| hole and play around with the web again.
| FjordWarden wrote:
| I don't find WebComponents a good replacement for what in other
| web frameworks are called components. For one thing they don't
| support complex values like Objects and Arrays as attributes. The
| amount of boilerplate you have to write is way too high, and you
| still don't have reactivity. I do vanilla-ish JS using
| signals[1]. Not everything the W3C releases should be canon,
| XHTML is a testament to that.
|
| [1] https://wrnrlr.github.io/prelude/
| jonahx wrote:
| See also:
|
| Meiosis Pattern:
| https://meiosis.js.org/docs/01-introduction.html
|
| Mithril: https://mithril.js.org/
| chrisweekly wrote:
| This is a great resource.
|
| IMHO everyone building for the web should understand how it works
| and know how to use the foundational web stack, leveraging the
| web platform per se. Then, by all means use a build system and
| your preferred frameworks at your discretion, remaining aware of
| tradeoffs.
|
| For my part, one of the things I like best about Remix (/React-
| router v7+) is its explicit philosophical alignment with
| leveraging web standards and doing more by doing less (e.g.
| mutate server data using... the HTML form tag).
|
| I also highly recommend https://every-layout.dev which showcases
| eye-opening, mind-expanding techniques for implementing
| performant, accessible, flexible web layouts using only browser-
| native CSS.
|
| Context: I've been professionally involved with web development
| since 1998.
| tanepiper wrote:
| When I built my new project (https://teskooano.space) I decided
| to go all vanilla web for it.
|
| No regrets, except I found myself also building a framework....
| lucb1e wrote:
| Can we just use links to go between pages, instead of toggling
| css display:none on custom elements to show different "pages"?
| You're replacing browser functionality with custom code. To get
| on par with browser default functionality, you need to implement
| a loading indicator, error handling, back/forward button
| handling, address bar updates, opening links in a new tab when
| someone middle clicked or ctrl clicked, new window when they
| shift clicked, etc.
|
| https://plainvanillaweb.com/pages/applications.html This example
| code does exactly one of those things: update the address bar by
| setting the fragment identifier. Middle clicking and back/forward
| buttons work because of that. Error handling (if it were to not
| just be static content but actually loading something from a
| server like a real website, which can fail) and loading
| indicators are not present
|
| Re-implementing browser code in JavaScript is not using the
| "plain" or "vanilla" web functionality. You're making your own
| framework at that point
| JodieBenitez wrote:
| Indeed... I'd critisize SPAs a lot less if they wouldn't try to
| (poorly) mimic MPAs that often.
| zelphirkalt wrote:
| And at that point of course we would see some 90% reduction
| of SPAs, and hordes of FE devs looking for work. There is
| non-technical incentive at work to keep this bloat in the
| boat.
| wewewedxfgdf wrote:
| Is there any clean solution to the innerhtml problem in plain
| JavaScript applications, that does not require a virtual DOM or
| component lifecycle AND has Jetbrains IDE support?
|
| I'd like to use lit-html but Jetbrains does not support it - very
| annoying.
| lucgommans wrote:
| Was wondering what you meant so I looked up "the innerhtml
| problem" and the top result indeed does list quite a few issues
| with appending to innerHTML that can be easily avoided. For
| anyone else interested:
| https://stackoverflow.com/a/33995479/1201863
| runlaszlorun wrote:
| Is connected callback still needed over a constructor? I read
| somewhere it's not needed but couldn't say where that was
| lerp-io wrote:
| "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?
| intalentive wrote:
| It's less complex in the sense that you only need an editor and
| a browser. You don't need to install npm or Vite.
| austin-cheney wrote:
| 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.
| insin wrote:
| 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.
| austin-cheney wrote:
| 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.
| lerp-io wrote:
| the tools are supposed to make u be able to make products
| faster and more efficiently and iterate faster on
| business requirements or whatever problem you are trying
| to solve. you are treating it like its some toy your
| supposed to fiddle with or something. there is a reason
| we aren't coding in binary and use functions to
| encapsulate and abstract away logic. these frameworks are
| supposed to provide boilerplate so that you don't have to
| go through the trouble yourself because somebody already
| solved it so you can be more productive and build on top.
|
| getting a site up and running with vercel is like 20x
| faster and more simple than hardcoding .html files man.
| austin-cheney wrote:
| If you want to iterate faster then don't impose
| unnecessary abstractions. These tools exist so that
| otherwise unqualified people can participate.
| bob1029 wrote:
| 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.
| getnormality wrote:
| This is how 100% B2B worked before there was B2B SaaS, and it's
| still how 99% of B2B works today.
| SoftTalker wrote:
| Yep. EDI and FTP.
| accrual wrote:
| Still is that way in many places. Some smaller clients I've
| worked with prefer the flat-file + FTP over a more
| integrated solution (TCP/IP, etc.).
| _heimdall wrote:
| Especially for internal tooling that is little more than CRUD,
| I find the web to be most useful when a consultant is brought
| in to build it once or when an internal team can't be allocated
| to help maintain it.
|
| If you have even a small bandwidth to maintain it over time,
| quick and simple solutions like an Excel template and a few
| custom scripts work great and often end up being more flexible
| as your end user is mostly working with raw data.
| ern wrote:
| 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.
| bradly wrote:
| 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.
| numbsafari wrote:
| As in urns for ashes, not Universal Resource Names.
| jagged-chisel wrote:
| urns, not URNs
| 90s_dev wrote:
| > if you squint and look closely you'll find interesting
| people doing interesting things all around you
|
| Yep :)
| gotaqmyfriends wrote:
| How does the woodworking company ensure payment? Does the
| specialized nature ensure only "real" customers buy? Is there
| a trusted relationship? A threat of legal action?
|
| I know the other way around is basically the norm: how does
| one know the company, the seller, will actually provide the
| product after paying. But the prevailing culture, currently,
| is that companies in this regard are trustworthy and
| customers are not. It's a bit debatable but it makes sense.
| bradly wrote:
| > How does the woodworking company ensure payment? Does the
| specialized nature ensure only "real" customers buy?
|
| Yes, I believe it does. These are highly specific brass
| tacks for making oval shaker boxes. There are very few
| manufactures of a proper #2 brass tack these days, so I
| would very much want to stay on the good side and any
| suppliers.
|
| I think they said in their faq that twice they haven't been
| paid in 20 years or something like that. Their online
| "store" appears to be down right now-hopefully they are
| still in business.
|
| edit: It appears John passed in 2023 :(
| https://blog.lostartpress.com/2023/02/07/john-
| wilson-1939-20...
| gotaqmyfriends wrote:
| Sad to hear. Thanks for the info.
| ccppurcell wrote:
| They have your address and it would be illegal not to pay.
| But also if the products have little to no resale value,
| are good quality and replaced relatively frequently, then
| such a company is worth its weight in gold. Even if you
| "get away with it" you can obviously never do business with
| them again.
| brazzy wrote:
| Not sure about the US, but in my country that's how mail
| order used to work for decades, and it's still pretty
| common to offer that payment option, though usually with
| some restrictions (e.g. not for your first order).
|
| Most people are not scammers and will pay simply because
| it's the right thing to do.If your margins are decent, you
| can just eat the loss to some scammers as the cost of doing
| business. Especially if there's no real resale market for
| your product.
| DrillShopper wrote:
| Cash on delivery (COD) used to be popular in the US for a
| lot of the mail order junk on television in the 70s to
| early 80s. The rise of the credit card for normal people
| was a cause of its decline because people now had a
| reliable way to pay over the phone when ordering said
| junk.
|
| https://en.wikipedia.org/wiki/Cash_on_delivery
| brazzy wrote:
| COD still protects against fraud by having the delivery
| company collect the money before handing over the order.
|
| With the "pay the bill later" it's entirely up to the
| recipient whether they decide to pay. Some will even just
| forget it with no ill intent.
| Aurornis wrote:
| > 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.
|
| People romanticize businesses like this but there's a reason
| you're not posting the link. It only works when it's for a
| small group of people who are in the know and refer trusted
| buyers.
|
| It's also trivial to set up any number of different online
| purchase options that would avoid all of the problems with
| this for a nearly trivial fee.
|
| I guess I've spent enough time dealing with things like non-
| payment or doing work for trades that never arrive that I
| just don't romanticize this stuff any more.
| bradly wrote:
| > People romanticize businesses like this but there's a
| reason you're not posting the link
|
| You are correct that I was a worried about an HN hug of
| orders for brass tacks.
|
| > I guess I've spent enough time dealing with things like
| non-payment or doing work for trades that never arrive that
| I just don't romanticize this stuff any more.
|
| In this case there isn't much of a choice. When the last
| manufacture of brass tacks closed down, John bought the
| machinery and is the only place I know of to get proper
| shaker-style brass tacks in the US. I wanted the tacks, so
| I had no choice in the method of payment.
|
| I understand your sentiment but it was perfectly normal to
| pump gas before paying in the U.S. for a very long time and
| still is in many places. In other cities it is unheard of.
| Restaurants we can still eat before paying, but not many
| other places still give consumers much trust.
| Aurornis wrote:
| > I understand your sentiment but it was perfectly normal
| to pump gas before paying in the U.S. for a very long
| time and still is in many places.
|
| I had a friend who worked at a gas station in high
| school. Filing police reports for people who filled up
| and left without paying was a standard part of
| operations.
|
| This was in a nice area, too. Often people just forgot
| and drove away. They had recourse because they had
| security cameras and people had license plates. The
| cities where you're forced to pay inside first probably
| have police departments that don't respond to non-payment
| as gas stations.
|
| If someone showed up with a gas can or something they
| were instructed to shut off the pump and make them come
| inside to pay. It wasn't as much of an honor system as it
| seems if you're not familiar with it.
|
| You can't have a pay-later business without an amount of
| non-payment, which has to be compensated by higher prices
| (which other customers shoulder).
|
| These are all choices a vendor can make. Something like
| this usually lasts right up until the secret gets out to
| a wider audience where the people who don't care about
| social norms have no problem abusing a system left wide
| open.
| Juliate wrote:
| > You can't have a pay-later business without an amount
| of non-payment, which has to be compensated by higher
| prices (which other customers shoulder).
|
| People who never experienced high-trust and customs
| societies cannot grasp why and how it works infinitely
| better than low-trust ones.
|
| But granted, all it takes is a few determined bad faith
| actors to break high-trust, when they are not vehemently
| and swiftly rejected...
| int_19h wrote:
| For this to work, you need society as a whole to
| participate in enforcement.
|
| But we have created an environment where this kind of
| thing is unthinkable, not even because people won't do
| it, but because they will only create legal trouble for
| themselves if they try. So the modus operandi for your
| average citizen in Western societies in general and US in
| particular is to not get involved and leave it all to law
| enforcement.
| zchrykng wrote:
| 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?
| immibis wrote:
| Can you elaborate?
| Juliate wrote:
| It is totally thinkable, and it does happen. However, you
| get to this by vetting people/customers in.
|
| This is why some things can't be found/bought without
| hetting the right path/contacts.
| HappMacDonald wrote:
| I don't know if I would classify "consume first, pay
| later" as high trust. Example: Hotel "honor bars".
| IIsi50MHz wrote:
| I'd expect the hotel to already have a payment method on
| file, and possibly have pre-cleared a large charge to
| hedge against consumption or damage (with unused portion
| of the charge removed during checkout).
|
| Contrast with the typical restaurant.
| Juliate wrote:
| Hotels generally handle this very graciously, having
| indeed a pre-clearance on a payment method.
|
| Moreover, trespassers, in addition to pursuit, often get
| flagged in a shared << do not host >> book file across
| hotel lines.
| Y_Y wrote:
| > You can't have a pay-later business without an amount
| of non-payment, which has to be compensated by higher
| prices (which other customers shoulder).
|
| The business can just make less money than they would if
| everyone paid (which is, as you say, impossible). Costs
| and prices are linked in some markets, but it's not a
| natural law.
| 4ndrewl wrote:
| til you have to pay for your fuel before filling up in
| the USA.
| femto wrote:
| > brass tacks
|
| An interesting story behind those:
|
| https://blog.lostartpress.com/2023/02/07/john-
| wilson-1939-20...
| thesuitonym wrote:
| > People romanticize businesses like this but there's a
| reason you're not posting the link.
|
| What you're insinuating is true, but more likely the reason
| they didn't post the link is that it's not relevant.
| joseda-hg wrote:
| It's customary to link the example given if relevant to
| the point even if not to the topic in general, otherwise
| you have to trust the person that the example they're
| talking about is real and true
| immibis wrote:
| This type of business works in the small - when you know
| your suppliers and your customers. It doesn't work if you
| have 10,000 customers, or if anyone can email you. For this
| business it's only a spam problem, though - they have to
| reject emails from strangers if they get a high volume,
| exactly the same way they have to reject emails selling
| Viagra.
|
| That's probably alien to HN and a lot of them may try to
| contact him, as if they have a possibility of becoming his
| customer, which they don't.
| phillsav wrote:
| In your case, perhaps a shopping cart could increase
| conversion, perhaps not.
|
| While an e-commerce solution is not always needed, there's a
| good chance that a very simple shop cart facility will
| convert more than an email link, for certain types of
| products.
| cortesoft wrote:
| > 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.
|
| Why do I want "interesting" ways to buy things? I want to be
| able to buy what I want quickly and reliably. I don't get the
| benefit of making me try to figure out how to buy something I
| want
| Juliate wrote:
| Why wouldn't you want interesting experiences options, from
| time to time?
|
| Why wouldn't you appreciate getting out of the (often) dull
| (sometimes) frictionless select-order-pay-receive-use-
| store-forget-discard purchase experience?
| bradly wrote:
| > Why do I want "interesting" ways to buy things? I want to
| be able to buy what I want quickly and reliably. I don't
| get the benefit of making me try to figure out how to buy
| something I want
|
| Understandable view, but try thinking it from the producers
| point of view. They want to create an sell in the way that
| makes sense for themselves and their goals. There are all
| different types of people with all different types of
| goals, so it is really awesome when there is all different
| types of commerce going on. It isn't about eliminating
| something, but the freedom to make something and sell it on
| your terms.
| Cthulhu_ wrote:
| > You can simply not pay if you choose not to.
|
| It's only a matter of time before this seller falls victim to
| a scammer - once they're found. I used to work for a book
| publisher who started doing their own e-commerce, and at the
| time one of the payment methods was a "pay later" one that
| predated the internet ("acceptgiro"). It only took a few
| months (if that) after the first sites went live that someone
| placed an order for a few hundred euros worth of books and
| had it delivered at a storage unit address. We scrapped the
| pay later payment option for orders over a certain amount
| then, and I'm sure later on the pay later option was removed
| entirely in favor of pay in advance methods.
|
| There's newer pay later schemes now (Klarna IIRC) but the
| risk and debt collection falls to this payment provider. Of
| course, they got in legal trouble recently because they're a
| loan / credit company but didn't present the user with the
| right legalese for that.
| cess11 wrote:
| That's just business, you need to price in disturbances
| like an important customer going bankrupt or switching
| suppliers or some customers refusing to pay for other
| reasons, and do a risk assessment before supplying on large
| orders.
|
| It's one of the earliest lessons you'll learn from starting
| a company. Another close one is to not waste time on failed
| sales and annoying customers, replacing them with new
| customers is usually more profitable and enjoyable.
| bradly wrote:
| Unfortunately, fraud is a part of business. During my time
| at Intuit, Apple, and Shopify fraud was a huge part of
| everything I worked on. When I was a teenager working at a
| gas station people would just run out the door with a 24
| pack of beer.
| thesuitonym wrote:
| In another post it was revealed that the owner passed away
| in 2023. While I'm as certain as you that there was _some_
| level of abuse, it doesn 't seem to have been enough to
| make him change his ways.
|
| Consider also that if you have a plumber, electrician, or
| some other tradesperson come to your house, you don't pay
| them until after they have done the work. You _could_
| choose not to pay them, but they have your address, and you
| 'll never be able to do business with them again. On a
| small enough scale, this is all you need to prevent abuse.
| joshvm wrote:
| > 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.
|
| Payment after receipt is very common in Switzerland, but
| fraud is presumably rare. Your name would probably go on the
| debtors register and that's the sort of bad credit history
| you don't want to have. At some point the police/debt
| collection is involved, they get sent to whatever the address
| is and so on. For the average person it's not worth burning
| your name and address for a free spokeshave.
| kiney wrote:
| also kinda common in germany. Used to be much more common,
| but you still see it, especially in b2b, even for high
| value items
| immibis wrote:
| You see delayed payment everywhere in b2b - "net-30" for
| example.
|
| There was a story posted on HN once about a business
| saving money by prepaying. Some guy was working for a
| restaurant and saved 70% (yes, over two thirds) on their
| meat by, instead of ordering each day and settling on
| net-30 as they had been doing and as is typical, calling
| up their meat vendor and committing to a certain minimum
| order every day and paying for it right then. Because
| cash flow is that important to some businesses. The
| vendor said they'd never had a customer so good before,
| and yet it wasn't such a big deal for the restaurant.
| (Yes, they tend to run on thin margins, well, now their
| margins are a little bit fatter and they can afford to
| have mispredicted their meat usage a little, and still
| come out ahead).
|
| It's the same as Hetzner vs AWS. You buy AWS, you can
| ramp up and down your bill any time, but you're
| overpaying by a huge multiple (can even be 10x-100x). If
| you get your servers from _any_ traditional provider that
| 's updated their price in the last five years, they'll
| bill you monthly for your server, and there's a setup
| cost of approximately one month, and you can't scale up
| without a week latency or down without two months, but
| you get the same amount of server for an _incredibly low
| price_ (if you 're accustomed to AWS) which - if you're
| not running a workload as bursty as Amazon on Christmas
| Day - lets you overprovision enough to more than make up
| for the inflexibility.
| kingofheroes wrote:
| Two local businesses I frequent (one for baked goods and
| another for coffee beans) use mailing lists for membership
| and ordering. Only "drawback", if it even is one, is they
| rely on word-of-mouth because I had no idea they existed
| until I saw them mentioned in a thread on a local subreddit.
| stronglikedan wrote:
| There are plenty of people who don't want to interact with
| anyone when making a purchase (me included), and you are
| losing that business, even if it is only a small part.
| landgenoot wrote:
| I moved to south east Asia and the phenomenon of a "hotline"
| openend my eyes.
|
| Every business is basically a phone number that you can
| message. It does not matter if you buy a pizza or furniture,
| book a hotel or need someone to clean your sofa.
|
| No website. No need to fill in forms. No platform fee.
| chenster wrote:
| In south east asia, people dont' have very good phone or even
| smart phone in that matter, txt msg makes sense. The same to
| many african countries where dumb phones are still dominant.
| shark_laser wrote:
| I cannot speak for Africa, but this is not true of South
| East Asia.
|
| Whilst cheap 'dumb' phones do still exist and are used,
| even low income earners in South East Asia tend to have a
| smart phone, and most of the business done as landgenoot
| says is conducted via Telegram, Facebook, or occasionally
| WhatsApp or Line.
|
| There are also ways of paying using nothing but a phone
| number, but usually business is done on a smart phone where
| photos of products are are shared, delivery is arranged,
| and since COVID, most payments are done via QR codes that
| require a smart phone.
|
| In my experience this is not only true of the cities, but
| also even out in the provinces.
| mrheosuper wrote:
| Do you really think that SEA is still stuck in such economy
| ? Man you need to explore the world more
| redandblack wrote:
| this is the storyline that people should ideally
| internalize and realize that they do not know what they
| are talking about when commenting on others without
| having direct experience
| paulmooreparks wrote:
| I live in Singapore and travel to Malaysia, Indonesia, and
| Thailand quite a bit. What you say is certainly not what I
| observe.
| KPGv2 wrote:
| Can it work that way? Of course.
|
| But just because it works that way there, doesn't mean it's
| _right_. There 's nothing about SEA that implies to me the
| pinnacle of operational efficiency.
| EZ-E wrote:
| I'm thinking about why this is not really how we do in the
| west. Would customers even want to get on the phone? I think
| my initial reaction if I was to contact a business through a
| hotline is that on the other side of the phone it will be a
| massive call center rather than the business directly which
| would make me cautious.
| windward wrote:
| Just the fact that you've assumed a phone _call_ highlights
| the difference in culture. It 's done over text!
| AdieuToLogic wrote:
| > 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.
|
| Enabling customer self administration/configuration of a "B2B
| SaaS" system mandates some form of interaction. I would be
| surprised at how many would not expect "touching a browser" to
| do so.
|
| > 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.
|
| If there is no validation of information given nor system rules
| enforcement, then I would question the correctness of said
| sites/applications.
|
| > 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.
|
| This approach obviates the value added by a system enforcing
| core software engineering concepts such as fitness of purpose,
| error detection/reporting, business workflows, and/or role-
| based access control.
|
| In short, while letting customers send Excel files "and then
| load+merge their results directly into the same SQL tables"
| might sound nice, this does not scale and will certainly result
| in a failure state at some point.
| bob1029 wrote:
| > In short, while letting customers send Excel files "and
| then load+merge their results directly into the same SQL
| tables" might sound nice, this does not scale and will
| certainly result in a failure state at some point.
|
| Much of US banking operates almost entirely on this premise
| and has done so forever.
|
| > error detection/reporting, business workflows, and/or role-
| based access control.
|
| I'd take a look at the Nacha (ACH) operating rules if you
| have any doubt that sophisticated business workflows can be
| built on top of flat files and asynchronous transmission.
|
| https://www.nacha.org/newrules
| KPGv2 wrote:
| > Much of US banking operates almost entirely on this
| premise and has done so forever.
|
| I might be mistaken, but isn't banking famous for
|
| (1) the long hours (i.e., processes suck), (2) the drudgery
| of updating said Excel files (i.e., processes suck) (3)
| horribly expensive to access (i.e., processes suck)
|
| I have never once in my life as a corporate lawyer thought
| of banking as a model of operational efficiency.
| SoftTalker wrote:
| Yep an early project of mine was building an import of
| account charges from an FTP file transmission. There was
| plenty of checking and validation, any records that didn't
| pass were rejected and the user got notified (I think via
| email) with the rejected records and the reasons. They
| could then correct them and resubmit.
|
| Granted the only real security was the FTP username and
| password, but it was all internal and at the time (1990s)
| that was good enough.
| AdieuToLogic wrote:
| >> In short, while letting customers send Excel files "and
| then load+merge their results directly into the same SQL
| tables" might sound nice, this does not scale and will
| certainly result in a failure state at some point.
|
| > Much of US banking operates almost entirely on this
| premise and has done so forever.
|
| This is a disingenuous statement as it relates to at least
| credit/debit/gift card transactions. Bank-to-bank and
| _select_ high-volume Merchants communicate in certain
| circumstances with secure file transfers, especially for
| daily settlements.
|
| The _vast_ majority of Merchants do not, and instead rely
| on secure web applications to authorize, capture, and
| settle their transactions.
|
| Perhaps other banking domains rely on Excel and similar to
| do business. I cannot speak to those business areas.
|
| > I'd take a look at the Nacha (ACH) operating rules if you
| have any doubt that sophisticated business workflows can be
| built on top of flat files and asynchronous transmission.
|
| And I'd recommend you take a look at different integration
| - online payment processing using Oribtal as described by
| Oracle.
|
| https://docs.oracle.com/cd/E69185_01/cwdirect/pdf/180/cwdir
| e...
| frontfor wrote:
| > Much of US banking operates almost entirely on this
| premise and has done so forever.
|
| I've had the same epiphany when I worked for a fintech
| startup that interacts with financial institutions. Having
| a website just isn't necessary for some of the day-to-day
| operations vs just sending CSV/Excel files back and forth
| for reconciliation, settlement, accounting purposes.
| AdieuToLogic wrote:
| > Having a website just isn't necessary for some of the
| day-to-day operations vs just sending CSV/Excel files
| back and forth for reconciliation, settlement, accounting
| purposes.
|
| This doesn't end well when there are hundreds of
| thousands of "reconciliation, settlement, accounting
| purposes" to support.
| immibis wrote:
| It kind of does. You still have all the same backend
| logic, but now it doesn't have to run concurrently with a
| user interface. You can take a queue of operations,
| process operations off the queue and send their results
| back. Isn't that a pretty reasonable way for a system to
| behave? More than a few systems do this internally, with
| some kind of central message queue.
| least wrote:
| That the system works does not mean that individual
| components of it are advisable. It works because it must
| and that is with great development effort to keep these
| interfaces working.
| Aurornis wrote:
| > Much of US banking operates almost entirely on this
| premise and has done so forever.
|
| Not literally. Banks have a lot of automations. The reasons
| they're not real-time has more to do with various
| regulations and technicalities of recourse, not because
| it's someone doing semi-manual processing of everything at
| each bank.
| NewsaHackO wrote:
| To me, this line of argument is completely backwards. Are
| you arguing that when people didn't know better, they used
| flawed systems, or are you actually saying that having a
| unified method of interaction between users and systems
| though a web browser app is worse than dark IT excel sheet
| macros?
| thesuitonym wrote:
| Years ago I was working for a company that was having
| trouble with their payroll processing vendor. As I was
| helping them out, I was astounded to find that the final
| step in payroll was to email a CSV file the bank for the
| ACH transfers.
|
| This was a fairly small company (~300 employees) and a
| national bank, so it strikes me as likely that this is how
| a lot of companies do business.
| zie wrote:
| Generally in the excel load process, one does sanity checks.
| However your database can do all the checking if you so wish.
| CHECK() gets you quite far. If you have PostgreSQL(PG) or
| some other advanced SQL database, you can even go forth with
| functions and views and triggers and everything else.
|
| We execute Python in our PG database and do testing through
| PGTAP.
| al_borland wrote:
| I've never felt more useless at work than when I was told to
| integrated with a new React self-service portal. No one
| actually wanted to build things for it or use it. It was the
| pet project of a new CIO. I think it fell over under its own
| weight in under 2 years.
| brodo wrote:
| If that's the most useless thing you ever did at work, count
| youself lucky.
| Aurornis wrote:
| > 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.
|
| > Email and flat files are far more flexible than any web
| solution.
|
| Some times I feel like I'm taking crazy pills when I read HN
| lately. Suggesting that we e-mail requests around and have a
| person on the other end manually do things including merge data
| into SQL tables is such a bizarre claim to see. Every once in a
| while I encounter some business that operates like this and
| it's inevitably a nightmare, either as a customer or a partner.
| Not to mention it's ripe for everything from fraud to the
| company falling apart because the person who normally reads
| those e-mails and does the things for 20 years suddenly leaves
| one day.
|
| This feels like a mix of rose-tinted glasses reminiscing about
| the old-timey way of doing things combined with a layer of
| career burnout that makes everything modern feel bad. Dealing
| with a business that operates this way is not good.
| motogpjimbo wrote:
| Excel files can work surprisingly well in B2B scenarios where
| there's a high degree of trust. At a retailer I used to work
| at, we ran an impromptu Christmas gifts team in December each
| year, where corporate clients could put in a large order of
| gifts to be sent to their employees. Rather than build a
| website for it, we just sent them over an Excel file they
| could fill in with the name and address of each employee, the
| gift they wanted to receive and a message for the label.
| They'd send the file back to us and we had a process to
| validate the data and load it into our system. It sounds
| primitive, but it was much more time- and cost-efficient than
| faffing around with a custom application that we would only
| use for one month per year and which the clients probably
| wouldn't enjoy using anyway.
| briandear wrote:
| For real. The UX matters. Reducing the surface area for
| errors is also valuable. If "overbuilt" means "putting a
| clear UX around an important business process" then I love
| overbuilt.
|
| It was like that one dude on HN that criticized Dropbox back
| in day saying he could have built it in a weekend using rsync
| and a bunch other nerd nonsense that the average person
| doesn't have the time or the expertise to mess with.
| lerp-io wrote:
| no no no.....what you people really need is just an ai chatbot
| that simply generates your crud app/interface/store/whatever on
| the fly, so you don't even need excel or anything at all and
| the internet is just one big open vector database big brain.
| b2b, saas, excel, admin roles?? haha whats that?? and then we
| just relax outside in the grass hugging trees and smoking pot
| or whatever like in the 80s.
| jonathanlb wrote:
| Weirdly this is something similar to what Satya Nadella said.
|
| > Yeah, I mean, it's a it's a very, very, very important
| question, the SaaS applications, or biz apps. So let me just
| speak of our own dynamics. The approach at least we're taking
| is, I think, the notion that business applications exist,
| that's probably where they'll all collapse, right in the
| agent era, because if you think about it, right, they are
| essentially CRUD databases with a bunch of business logic.
| The business logic is all going to these agents, and these
| agents are going to be multi repo CRUD, right? So they're not
| going to discriminate between what the back end is. They're
| going to update multiple databases, and all the logic will be
| in the AI tier, so to speak. And once the AI tier becomes the
| place where all the logic is, then people will start
| replacing the back ends, right?
|
| https://www.windowscentral.com/microsoft/hey-why-do-i-
| need-e...
| beezlewax wrote:
| Except this is pure fantasy and AI is uniquely unreliable
| and error prone.
| addaon wrote:
| > Except this is pure fantasy and AI is uniquely
| unreliable and error prone.
|
| Is this perhaps why Microsoft is in a uniquely good spot
| to take advantage of AI for customer facing software? If
| customer expectation of your software is already that
| it's horribly unreliable and error prone, AI bringing
| more of the same may not really hurt...
| goalieca wrote:
| Microsoft is one of the few mega companies that can
| afford to massively invest in the capital required for
| AI. Few people realize how expensive it is. The business
| model right now is to lose money but gain market. We've
| seen how that game ends up with adtech!
| layer8 wrote:
| It sounds like he's already smoking pot.
| genewitch wrote:
| "Realistic Diction is Unrealistic"
|
| Or
|
| "If you ever want to make someone look dumb, quote them
| _verbatim_. "
| mannycalavera42 wrote:
| <<Wait, it's just a bunch of Excels?>> <<Always has been>>
| int_19h wrote:
| Well, sometimes it was DBF files (of dBase / FoxPro / Clipper
| fame). The first app I ever wrote for money was a thing that
| prompted you to insert a floppy with a .dbf consisting of a
| list of recalled products and append it into a local database
| (another .dbf!) that would let the user query the whole
| thing. The floppies were obtained by means of a person
| walking to the local office of the corresponding government
| entity where they would hand a blank floppy and receive it
| back with the copy of the most recent updates. That was late
| 90s.
|
| This evolved through multiple iterations as the government
| end of it did. At one point you no longer had to walk there
| physically; instead, there was a dial-up endpoint running
| UUCP that could be used to fetch the file. Then they found
| out about Internet, and it became a website with the file,
| now .mdb (MS Access) rather than .dbf. I rewrote the app in
| .NET/WinForms, since it was much easier to do all those
| things from it than to try bolting it onto an old TUI DOS
| app.
|
| But it was still basically the same table with the same
| schema by mid-10s, and my app was still chugging along. I
| wonder sometimes if some iteration of it is still in use
| today; wouldn't be surprised if it were.
| hliyan wrote:
| I think of something similar every time I use the Uber Eats
| 'track order' screen. All I need is a simple textual history:
| 7:40 - Bob was delayed by 5 minutes. ETA 7.45 7:35 -
| Bob is heading your way. ETA 7:40 7:20 - Bob has picked
| up your order from Pizza place
| patrickmcnamara wrote:
| Having a live location of the delivery person makes total
| sense here though.
| hliyan wrote:
| Why? What I would prefer is a "Notify me when the rider is
| [X] minutes away. Use ringtone [R]" feature. X is the time
| I need to go downstairs and open the gate. The customer
| need not have their brains cluttered with logistics
| details.
| Vinz_ wrote:
| Because in a lot of cases, the driver isn't in the
| correct place, and so if you have their location you can
| easily tell them how to get to you. I've had multiple
| deliveries where the Uber Eats app just could not tell
| the driver the correct location for my address, and I
| wouldn't have been able to tell the driver how to get
| there by just them telling me where they were.
| hliyan wrote:
| For that, I would propose a feature where I can mark the
| directions to my home from a well known checkpoint on a
| map, one time. If the rider deviates in the last mile,
| they get notification. If they continue to deviate, I get
| a notification. The solution is not for me not constantly
| monitor the rider's location.
| monsieurbanana wrote:
| As this thread is about over engineering solutions, I
| can't help but wonder if this is satire
| 6P58r3MXJSLi wrote:
| > so if you have their location you can easily tell them
| how to get to you.
|
| So you work in logistics support, but you pay to do it?
| sswatson wrote:
| Yes. I'm happy to do whatever makes the most sense in any
| given situation. I have never in my life thought to
| myself "I could easily help solve this problem and make
| everyone better off, but I will refuse because problem-
| solving is work and work is only for employees."
| 6P58r3MXJSLi wrote:
| > I'm happy to do whatever makes the most sense in any
| given situation
|
| What makes the most sense in this situation: you walk to
| the nearest pizza place, you buy your pizza, done.
|
| To an able-bodied person it shouldn't take more than 5
| minutes.
|
| Bonus points: you know the way back to your home.
|
| > because problem-solving is work
|
| You know who made someone else's problem a
| problem=solving problem? You.
|
| The delivery guy will eventually find your place or he's
| just taking a different route for whatever reason.
|
| How arrogant is it to think that you can tell people how
| to do their job, from your couch?
|
| You obsession for micro managing other people's actions
| it only says that you suffer from high anxiety, it is not
| in any way proof that you _make everyone better off_.
| That 's just what you tell yourself.
| BlewisJS wrote:
| This is a completely unhinged response to the idea of
| getting pizza delivered...
| bondarchuk wrote:
| You want pizza or not?
| 6P58r3MXJSLi wrote:
| I also want to be paid when I work.
| briandear wrote:
| Is that what the average user thinks? HN has nerd bias --
| I bet many people here would prefer a TUI for Uber. My 65
| year old aunt who doesn't speak English very well might
| well prefer a graphical display of where her driver is.
| Plus it's fun and adds to the experience of using the
| app. Not everything should have the succinctness or
| sparseness of an aviation METAR.
| bbkane wrote:
| In fact, I've gone the opposite way- my work has an internal
| cafe with a menu website that takes a lot of clicks to see
| everything.
|
| I originally planned to scrape the data and make my own website
| with better (imo) controls, but v0 turned into pumping the data
| into a Google sheet.
|
| I've never needed v1. The Google sheets "UI" solves filtering
| (i.e., breakfast vs lunch), access control, and basic analytics
| (~7 other colleagues also use this daily).
| invaliduser wrote:
| I have a similar experience with providing users with excel
| files, but would also like to add that in a lot of business,
| the number 1 competition for a web application is the good
| old excel file (or its modern cloud version), and it's
| sometimes a challenge to beat.
| gampleman wrote:
| Yeah, I've spent 2 years in a job trying to build a UI to
| beat an Excel file. Did not succeed.
| thesuitonym wrote:
| I really hate how much work happens out of Excel/Google
| Sheets, but there's no denying that spreadsheets do a lot
| of heavy lifting without having to fuss with putting a DB
| together. Especially nowadays when two people can
| simultaneously work in a spreadsheet.
| mvkel wrote:
| This is some excellent first-principles thinking. Sort of like
| resisting the next team hire until it's unbearable, keeping the
| user out of the browser until it's unbearable
| Alex_001 wrote:
| 100% agree that we've collectively overbuilt a lot of B2B SaaS
| admin surfaces. I've also seen situations where a simple Google
| Sheet + cron + db insert script beat out six months of frontend
| sprinting.
|
| That said, I do think plain vanilla approaches like this site
| describes are valuable--not because everyone should use them,
| but because they remind us what the browser can do without 20
| layers of abstraction. That can be really useful when the goal
| isn't a full app, but something in-between email and interface.
|
| It's less about dogma, more about choosing from a wider
| spectrum of options--including "no UI at all."
| raxxorraxor wrote:
| Some even still use textfiles to exchange order information on
| a jointly used ftp server, where the most common error is that
| access happens simultaneously.
|
| That said, there are b2b exchanges where a simple website is
| perfect. Supplier quality cases where people need to exchange
| short texts or general supplier information exchange.
|
| Also b2b customers are far less concerned about UX style than
| the average retail customer. The former wants a system that
| just works efficiently and everything else is a waste of time.
| Sometimes productivity clashes with modern sensibilities and in
| the b2b case productivity still wins.
|
| I hate mail though for formal processes though. In that case a
| link to a simple website that orderly takes up information and
| it is the better solution.
|
| I also hate putting excel files into tables. There is always
| something going wrong, especially with files created in many
| different languages, and it is still work overhead. But there
| are already solutions for general information exchange that
| aren't necessarily parasitic SaaS services.
|
| Of course there are alternatives, but I wouldn't call the usual
| ERP/CRM software superior to web apps.
| larodi wrote:
| Lets first not forget: 1) people been doing business with these
| "ugly" green textmode screens, long before web; 2) the web
| existed in a very reasonable form pre-www as FIDO, GOPHER, and
| of course IRC & EMAIL.
|
| The fact that this all got hyperlinked is a superb. convenient,
| but also a challenge from tech perspective, and what FAANG did
| in the 30 years to come (after 1992) led to this horror of
| entangled and super-complex technologies we have today. Even
| vanilla web is quite complex if you take into consideration all
| the W3 standardization.
|
| Security or not, you can have an appliance run much simpler
| software given longer product lifetimes,... My only hope is now
| with llm-assisted coding this vanilla approach comes back, as
| the boilerplate pain becomes more bearable (how I really hated
| html at some point...). Besides, it is much more pleasant to
| prompt yourself a website, rather than try to position some
| image on stupid fb/insta pages/events, which is one major
| reason to step back and own your content again.
| astrobe_ wrote:
| > The fact that this all got hyperlinked is a superb.
| convenient, but also a challenge from tech perspective, and
| what FAANG did in the 30 years to come (after 1992) led to
| this horror of entangled and super-complex technologies we
| have today. Even vanilla web is quite complex if you take
| into consideration all the W3 standardization.
|
| With that title I didn't expect Javascript to be part of the
| equation. To me "vanilla" is CERN's HTTP+HTML.
|
| The thing that happened is that FAANG _redesigned_ the web
| for their own needs, then other companies used that to
| fulfill their own needs too. That 's how we ended up with a
| lot of available content, but also user info mining, browser
| monopoly, and remote code execution (JS) as a daily
| normalization of deviance.
|
| There are some secessionists - Gopher is still alive, Gemini
| - but alternatives have a hard time to compete with the
| content companies can provide _apparently_ for free. Most of
| the content we want costs time and /or money. Content
| creators can be fine with contributing from their own pocket,
| but this is not really sustainable. User sponsorship
| (donations via Paypal, Patreon, Kofi, ...) don't work well
| either.
|
| Also, since the supporters of the alternatives are generally
| supporters of freedom (who isn't? Well, people don't reject
| freedom, they are "just" making compromises), they have to
| deal with illegal content and other forms of abuse.
|
| So there are 3 problems an alternative web must solve:
| protocols, moderation and repayment.
| larodi wrote:
| > The thing that happened is that FAANG redesigned the web
| for their own needs, then other companies used that to
| fulfill their own needs too. That's how we ended up with a
| lot of available content, but also user info mining,
| browser monopoly, and remote code execution (JS) as a daily
| normalization of deviance.
|
| and most importantly - we lost our right to search the
| content that the community generates. it is now walled off
| behind FAANG services, that threw us directly in the dark
| ages of internet, when even your own content is out of
| reach.
|
| here's as simple example - a group of friends been throwing
| parties for 20 years, like raves. all these are announced
| on the FB and now-and then on some other services. more
| than 400+ events for 20 years. trying to find these again
| is impossible. google won't index them, fb won't allow you
| to scrape then, insta also. perhaps some obscure snapshot
| lives of it in internet archive, perhaps not. so one reason
| to own the content you publish is to be able to actually
| use it yourself after a while.
|
| Even with JavaScript in the equation, the vanilla web is a
| good option to reclaim all that, and honestly bringing a
| personal site up in 2025 takes... less than a day to setup
| with all the VMs, DNS, CF tunnel, DB, FE/BE hassle that
| stands in the way. It's more available than ever, people
| just need to brave and embrace this... but something tells
| me the majority will not do it.
| jfengel wrote:
| 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.
| dragontamer wrote:
| Excel is more than cells?
|
| If you have certain options, use Excels forms to place
| buttons, menus and selections.
| accrual wrote:
| Fixed drop-down fields are very helpful for shared/inter-
| company spreadsheets too. Highlight them in red until
| they're changed, then enforce the value via dropdown.
| bandoti wrote:
| It could work but there is still a bit of developer overhead:
| (1) Use iron-clad schema validation in the database; (2)
| Provide some forms over top the Excel data like old Access
| applications.
|
| The benefit would be that you have a fixed set of UI
| components available in Excel and don't need to worry about
| styling and whatnot.
| naveed125 wrote:
| It's cool and I wish I had a use case for it.
| nobody42 wrote:
| http://youmightnotneedjs.com
| mwilcox wrote:
| aNd jaVaSCripT
| nickevante wrote:
| With advent LLM driven development,the traditional web frameworks
| may soon be rendered obsolete.
|
| All the framework abstractions we made for humans coding
| productivity will need to be re-visited! I support plain vanilla
| web for this reason.
| dalmo3 wrote:
| In today's episode of I Hate JavaScript Frameworks, So I Built My
| Own...
| eric-p7 wrote:
| I've built a library to make vanilla webcomponents reactive via a
| manual render() call that updates only changed nodes:
|
| https://vorticode.github.io/solarite/
|
| I was planning to improve performance more before announcing it.
| But even as is it beats React and approaches Lit.js on the JS
| framework benchmarks.
| drysart wrote:
| I've done something similar to this for my own internal
| applications, making use of snabbdom to handle the DOM updates.
| Snabbdom is tiny, robust, proven, and unopinionated; so I
| didn't see any particular need to reinvent that wheel.
| eric-p7 wrote:
| Nice. I used the open source udomdiff for my domdiffing,
| since my approach didn't use a virtualdom.
| gcau wrote:
| If you do this with no build step, how can you have cache busting
| of your component files? or is there an alternative solution that
| doesn't sacrifice on performance (but also doesn't serve stale
| files or an inconsistent version between files)?
| Joeri wrote:
| There's an article explaining the options on the blog section:
| https://plainvanillaweb.com/blog/articles/2024-12-16-caching...
| webprofusion wrote:
| Ironically the style of this site lets it down, the 2006 look
| (post-css, pre-gradients and big buttons) makes it feel like it's
| an outdated framework.
| webprofusion wrote:
| Literally use WebFontPicker and choose Raleway or something.
| webprofusion wrote:
| Although I'm liking the use of javascript classes, not for
| any technical reasons just that it's a defiant middle finger
| to the React crew (who you now no longer hear from) that
| cancelled classes.
| typedef_struct wrote:
| Some good patterns here. An Event with a callback (what you're
| calling [context protocol](https://github.com/webcomponents-
| cg/community-protocols/blob...)) I think will prove useful.
|
| My main gripe with web components is that while they expose the
| first half of the tree traversal (from the outside in, via
| connectedCallback), they don't provide access to the second half,
| after child elements have been created. (akin to Initialize and
| Load events from ye olde .NET)
| fitsumbelay wrote:
| I always appreciate a reminder of this site
| namuol wrote:
| Lost me at Web Components. There are many things the web does
| great, but Web Components is not one of them. Can we move on?
| vaylian wrote:
| Why do you think web components are not great?
| solumos wrote:
| I know not with what tools Web 3.0 will be built, but Web 4.0
| will be built with vanilla HTML, CSS and Javascript.
| cadamsdotcom wrote:
| This website covers a fair bit of React - in particular, it seems
| Web Components can be used to create components with both state &
| props.
|
| One can imagine a cross-compiler so you could write React, but
| have it compiled to React-free javascript - leaving no React
| dependency in production.
|
| Would be a lift, but looks superficially possible.
|
| What are the blockers to this?
| cube00 wrote:
| I suspect that's where the new React Compiler will eventually
| head where based on your code it will try and remove as much
| React runtime as possible if it's not needed.
| cadamsdotcom wrote:
| Took a look - after the pain of React memoization, that's a
| super exciting development.
|
| Thanks for the pointer!
| est wrote:
| SPAs are generally not worth it nowadays. Why a >20MB .min.js
| just for few lines of text content?
|
| Yeah I don't need your shitty onclick hijacks. Thanks.
| umvi wrote:
| 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
| deepriverfish wrote:
| my issue with doing web development without frameworks is how to
| best manage the app state. In react things like redux help with
| this, but in my experience state management becomes a mess
| without frameworks, maybe it's a skill issue on my side I don't
| know.
| ardleon wrote:
| You can use Redux outside of React, you also have this option,
| RxJS.
| quantadev wrote:
| There's another solution to the "Plain Vanilla Web". It's called
| Markdown.
| Julesman wrote:
| GPT agrees with me.
|
| The site positions itself as advocating for simplicity and
| minimalism in web development--stressing plain HTML, CSS, and
| JavaScript--but then pivots into building the entire project
| using React. That's a contradiction.
|
| If the goal is truly "plain vanilla web," introducing React (with
| its build tools, dependencies, and abstraction layers) runs
| counter to that ethos. A truly minimalist approach would skip
| frameworks entirely or at most use small, native JS modules.
|
| So yes, it's philosophically inconsistent. Want to dig into a
| better alternative stack that sticks to that principle?
| docuru wrote:
| I've learned that people use what they familiar with.
|
| At first, I learned and use plain HTML/CSS/PHP and I thought that
| was good. At college, they taught .NET framework and for some
| years, that was my go to techstack. Then I started to learn about
| more languages and frameworks. At some point, it's hard to switch
| between them
|
| Now I stick with one thing, unless that platform doesn't support
| it. This also allow me to be a lot more productive since I know
| most of the thing needed to be done
|
| Sure I can start with vanilla web, or some new framework but
| it'll take a lot more of time and just not worth it
| hsnice16 wrote:
| I had built a component library with HTML and CSS, and had named
| it "Vanilla Web" :)
|
| https://vanilla-web.netlify.app/
| moron4hire wrote:
| The section on Web Components is... teeechnically correct.
| Unfortunately, it's missing a lot of information on hidden
| pitfalls of doing things in certain ways
|
| As an example, the examples on `connectedCallback()` don't guard
| against the fact that this callback gets called every time the
| element gets inserted into the DOM tree. This could happen
| because you've removed it to hide it and then added it later to
| show it again, or it could happen because you've moved it to a
| new location in the tree (different parent, or re-ordering with
| respect to its siblings). Or maybe you're not manipulating this
| object at all! Maybe someone else is moving around a parent
| element of your custom element. Whatever the case, if you're
| element's ancestor path in any way gets disconnected and then
| reconnected from `documentElement`, `connectedCallback()` gets
| called again.
|
| That means that you have to spend extra effort to make sure
| anything you do in `connectedCallback()` either gets completely
| undone in `disconnectedCallback()`, or has some way of checking
| to make sure it doesn't redo work that has already been done.
|
| There are some other pitfalls involving attributes, child
| elements, styling, behavior with bundling, etc., that they never
| really get into. And generally speaking, you're probably only
| going to find out about them from experience. I don't think I've
| seen anywhere that goes into Web Component best practices.
|
| Which is a shame, because they are incredibly powerful and I
| enjoy using them quite a bit. Now that my company has decided to
| go all in on React, I think they've only really seen the beginner
| path on both. Web Components as a beginner look harder than React
| as a beginner. Once you start actually building apps, I find they
| actually end up having to do largely the same level of manual
| shenanigans. But I find that I'm doing manual shenanigans to work
| _around_ React, whereas with Web Components there isn 't any
| magic to work around, but there also isn't a lot of "help" that
| you'd end up ignoring in most cases anyway.
| sneak wrote:
| I'm tired of SPAs and webpages that don't render without
| JavaScript.
|
| The web is supposed to degrade gracefully if you are missing
| browser features, up to and including images turned off.
|
| Now, web developers give you a blank page if you don't run a
| megabyte of their shitty code.
|
| No thank you.
| zzo38computer wrote:
| > The web is supposed to degrade gracefully if you are missing
| browser features, up to and including images turned off.
|
| I agree. (This should also include CSS, TLS, cookies, and many
| other things; I often disable CSS, and it should work just as
| well if CSS is disabled just as much as if pictures or
| JavaScripts or cookies are disabled.)
|
| However, there are some uses where JavaScripts may be helpful
| e.g. if a web page has a calculations or something like that
| implemented by JavaScripts; but that is not an excuse to
| prevent the documentation from being displayed if JavaScripts
| are disabled. They should really make documentation and as much
| other stuff to work even if JavaScripts are disabled (and,
| depending on what it does, may provide a description of the
| calculation or of the rules of the game being implemented, or a
| link to API documentation, or something else like that).
|
| Pictures also might be useful in some articles (but are often
| overused); but even then, if the picture is not displayed you
| could use an external program to display them. However, if it
| can be explained in the text, then it should be explained in
| the text if possible so that even if you do not have a suitable
| program to display that picture (or do not want to display that
| picture, e.g. the file size is too big; or maybe you are using
| text to speech or a braille display or something else like
| that) then it will still work.
|
| TLS also should not always be mandatory, either. For things
| that require user authentication, and for writing, it can be
| useful to be mandatory (especially if you are using X.509
| client authentication; this will be better than using cookies
| or other methods for authentication, anyways); but for read-
| only access to public data, TLS should be optional (but the
| server should still allow it in case the client wants to use
| TLS for read-only access to public data too).
| sneak wrote:
| No, TLS should always be required. We should be moving away
| from plaintext anything on the wire, if for no other reason
| than privacy (but also for integrity, injecting scripts into
| an HTTP response is a nasty attack surface).
| tzebco wrote:
| I feel the same way, although I do struggle with excluding
| people who use older technology. I suppose TLS 1.2 is
| fairly old at this point ...
| int_19h wrote:
| TLS shouldn't be required for as long as it remains a
| heavily centralized thing; to require it would give undue
| power to root certificate authorities.
| vaylian wrote:
| Do you have an idea how this could be decentralized?
| int_19h wrote:
| It would have to be some kind of web of trust thing. But
| no, I don't have any specific suggestions to that effect
| (which is why I believe that HTTP should remain an
| option).
| vaylian wrote:
| What about self-signed certificates? That's still better
| than plain HTTP.
| int_19h wrote:
| 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.
| sneak wrote:
| TLS is not centralized, there are many different root
| CAs, and you can additionally install your own.
| zzo38computer wrote:
| A lot of people argue about this both for and against.
|
| However, TLS does not entirely help all of these things,
| especially with the way it is commonly used with HTTPS
| (although it can be used in a more secure way, it usually
| isn't). Although it prevents spies from injecting scripts,
| it does not prevent the server operator from modifying them
| from what the user expects (and it is not necessarily the
| software the user intends to run), nor does it help against
| someone taking over the domain name and then legitimately
| putting something else there instead (and stealing cookies,
| etc; X.509 client authentication would prevent theft of
| authentication though). To verify that a file is not
| modified, cryptographic hashes will help much better
| (whether or not TLS is used; TLS still prevents spies from
| seeing which files you are looking for though, and prevents
| spies from obtaining a copy of a file that is intended to
| be secret). However, these are not inherently problems with
| TLS; they are problems with the implementation, problems
| with HTML, problems with HTTPS, and problems with the
| expectations.
|
| Another issue with TLS is proxies; if you want to
| deliberately run a proxy on your own computer (so that it
| is protected from spies, etc), you will have to decrypt and
| encrypt the data twice. This is also a problem with the
| implementation, and not an inherent problem with TLS
| itself; an implementation could easily allow unencrypted
| proxies of encrypted connections, but doesn't.
|
| Self-signed certificates are commonly used with Gemini
| protocol and can be used with other "small web" protocols
| that support TLS. If you know the server's certificate from
| some other source (TOFU is a common way, but you could have
| another way), then self-signed will work, although it
| should be possible for the end-user to specify to require a
| specific server certificate (and adding this information
| into the URL would make it possible to pass a URL that
| includes this information, which may sometimes be helpful).
|
| Web of trust for X.509 certificates is something that I had
| thought of, and I had some ideas to make up a file format
| for that purpose. This will be a DER file which has a
| digital signature, and specifies hashes (and possibly other
| details) of certificates that you are aware of and will
| contain details about what parts of the certificate you
| trust and in what ways you trust them (e.g. you can say
| that you trust the common name, or that you understand a
| specific extension but have been unable to verify it, etc),
| as well as optional comments. Note that this can be used
| whether or not the certificate is self-signed; certificate
| authorities can still be used too (which still have uses,
| e.g. if the authority is partially being delegated).
|
| Another problem with certificates is securely superseding
| them (especially self-signed certificates). X.509 does not
| allow to add an extra field of unsigned extensions after
| the signature (and an extension inside of the certificate
| clearly cannot sign the certificate itself, since it would
| interfere) (although an extra field could be added,
| implementations that do not understand it may reject the
| extra field), so this could be done in two other ways
| instead. One is to add an extension into the certificate
| specifying the superseding key (for security, this can be
| different than the certificate's own key, and the
| corresponding private key may be stored on a separate
| computer that is not connected to the internet and may also
| be passworded for additional security), and optionally
| links to sources of the superseding file; the superseding
| file is then a DER file that lists the certificates being
| superseded and what they are superseded by. This means that
| even if the keys (or other details in the certificate, such
| as names, or expiry dates) are changed, trusting someone
| else is not necessary, and no other third-party authority
| is needed to verify if it is actually the same
| person/organization, or if it is someone else who has taken
| over the domain name, or if spies are changing the
| certificate, etc.
|
| Web of trust can be used together with superseding
| certificates.
|
| DANE would also be a good thing to use, although it won't
| help by itself, for many reasons. For example, in case the
| domain name is taken over by someone else or if the DNS is
| not itself secure (or whoever owns the DNS tampers with
| it). However, it can be used in combination with other
| methods in order to improve security.
|
| However, I think that allowing unencrypted connections is
| just simpler anyways; if the user does not need or want
| this privacy and security compared with wasting extra
| computing power or whatever, or wants to use older software
| that does not support this version of TLS, or is connecting
| only to other programs on the same computer (which will
| have its own security mechanisms, making TLS unnecessary
| (except for testing purposes)), or for whatever other
| reason, then allowing unencrypted connections is helpful,
| especially for read-only public data. Integrity can often
| be verified better in ways other than TLS anyways, as I had
| mentioned. I think there are many reasons why unencrypted
| connections should remain an option where possible;
| however, servers and clients should be made to allow TLS
| where possible, too, in case you do want this security, but
| it should not normally be mandatory (especially for read-
| only public data).
| anhtran wrote:
| No one cares how many pedals you have on your guitar pedalboard.
| But if you hit one wrong note, everyone in the audience will hear
| it and talk about it. Playing pedals is primarily for you and
| your team, not your audience.
| Uptrenda wrote:
| If every website did this I wonder if there would be a measurable
| impact on things like: battery life, performance, and bandwidth
| usage.
| Ygg2 wrote:
| I'm seriously starting to wonder do we even need JavaScript. Or
| images. How much could you do with UTF-8 web page.
| dmje wrote:
| This entire endless conversation would be made SO much easier if
| we spent some time thinking about the difference between web APP
| and web SITE. They get conflated all the time and although there
| is of course a Venn diagram where there's a bit of crossover,
| they're basically entirely distinct beasts that require entirely
| different technical approaches.
| klaushougesen1 wrote:
| Personally have had great experience in high throughput, complex
| paas / saas webapps by rigourously only adding things when it was
| clearly needed.
|
| Recommend you try to start with webcomponents + a well thought
| out design system -> move on from there and you're pretty sure to
| have a solid base from which you can always add react, lit, vue
| or whatever else cooks your noodle.
|
| the other way around is near impossible
| TimTheTinker wrote:
| Yeah, vanilla HTML is a difficult approach when a corporate
| design system and component library is thrown into the mix of
| requirements.
|
| From where I sit, Lit looks like one of the best ways forward.
| Here's an _awesome_ design system someone built using Lit:
| https://nordhealth.design/
| red_admiral wrote:
| Once you're building custom components in JS files, aren't you
| basically writing your own microframework?
|
| Sure you don't need bundlers and compilers (such as TS to JS),
| but at some point you might need async updates on `fetch()` of
| components that also share state with other components. At this
| point you're into framework territory, whether using your own or
| someone else's.
|
| Producing a framework with those features that still fits in a
| single small size JS file would be great, especially if it can do
| component updates to shared state (without updating the DOM each
| turn, hence shadow DOM).
| oxcabe wrote:
| Just checked what's there for libs implementing local state
| management + server-side sync in vanilla JS. The best options I
| found were `@tanstack/query-core`[1] and `@signaldb/core`[2].
|
| The former packs no dependencies, with a total size of 89.18 kB
| if you were to put all the module JS code together, unminified,
| on a single file. Which could be even smaller with an
| optimising bundler that tree-shakes and minifies the build.
|
| [1]: https://www.npmjs.com/package/@tanstack/query-core [2]:
| https://www.npmjs.com/package/@signaldb/core
| sebak82 wrote:
| 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 Boot or
| other JVM frameworks, this creates a cohesive Java application--
| no complex build pipelines, no split repos, and no friction
| between frontend/backend roles.
|
| What I personally enjoy most is the smooth developer experience:
| you see your changes reflected in the browser instantly -- no
| manual builds, reload fiddling, or sluggish toolchains - just
| java and a bit of maven. For many internal business apps, it
| feels just as "plain" as the old-school server-rendered apps--
| just with modern capabilities like Web Components and security by
| default.
|
| (Full disclosure: I work at Vaadin, but I'm genuinely a fan of
| the approach because it saves developers a lot of headaches.)
| EmilyHughes wrote:
| 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.
| sebak82 wrote:
| So a pattern is not mandatory with Vaadin, but you can make
| the UI "simple" changeable with a corresponding pattern of
| your choice. MVP and MVVM would be good examples of this.
|
| Debugging in the frontend is not trivial, but can still be
| done with the appropriate setting in the properties (https://
| vaadin.com/docs/latest/flow/configuration/developmen...)
| int_19h wrote:
| 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).
| myfonj wrote:
| 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 merely shows "enable scripting to view
| ../XYZ.html" in place of all code examples and demos. Better than
| having no fallback at all, I suppose, yet still not "navigable".
|
| The fact that it does not even bother to build these custom
| components on any native element with a similar purpose--like,
| say, a link that users could follow to see the text document (*),
| or a plain old iframe (**)--is grim.
|
| Web components are indeed useful for prototyping and personal
| testing, but are they really beyond the threshold where it is
| safe to serve them in the wild, potentially harming some users?
|
| (*) I know, view-source: links and embeds are sadly blocked by
| browsers nowadays. Makes very little sense to me. Someone likely
| managed to exploit it for some nasty purposes, so now we are
| "protected", I suppose.
|
| (**) See? In the olden days even iframes were said to have a link
| fallback inside, for user agents that did not support them.
| tzebco wrote:
| You're not the only one. I block most subresources by default
| and was disappointed to see empty figures peppered throughout
| their articles. I'm learning to not automatically equate
| advocacy of "vanilla" with advocacy of robustness.
| int_19h wrote:
| 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.
| myfonj wrote:
| This is quite fair point, yet I'd argue that still most so
| called web _apps_ could (and should) use basic old-school
| HTML forms as the underlying technology, and progressively
| enhance from that baseline, up to the "app-y" look and feel
| we know and ~~ha~~__love__.
|
| Obviously, there are some limits where application built with
| bog standard HTML forms becomes too cumbersome or makes no
| practical sense, as you say, but I think that that threshold
| is far higher than what current web-app landscape exhibits. I
| think the threshold is around video editing software, or
| real-time multi-user collaborative spaces perhaps. But for
| the rest, following three old steps Make it
| work -- just HTML. Make it nice -- add some CSS.
| Make UX slick -- add JS.
|
| still makes sense to me. In context of the
| plainvanillaweb.com it would mean just moving the content
| from non-semantic attributes of custom components to their
| semantic initial content, such as adapt
| <x-avatar src="https://i.pravatar.cc/150?u=a042581f4e29026024
| d"></x-avatar>
|
| to get the data from its contents:
| <x-avatar><img
| src="https://i.pravatar.cc/150?u=a042581f4e29026024d"
| alt></x-avatar>
| Abishek_Muthian wrote:
| I'm using HTMX and Hyperscript exclusively for interactivity and
| I'm loving the simplicity of it.
|
| Problems of FAANG are not our problems, yet they've somehow
| convinced majority of software architects that complexity is
| good.
|
| My only concern is when I use HTMX/Hyperscript in my FOSS
| projects will others be comfortable contributing to it even
| though it has very little learning curve but they have to empty
| their React cup.
| montag wrote:
| There are caveats and warnings already by the time we've added an
| `<x-header>`, and the attribute boilerplate seems onerous right
| from the start. It pains me to say that almost a decade on, I'm
| still not a fan of web components.
| montag wrote:
| Spend five minutes on webcomponents.org for a depressing ride.
| Broken links, broken demos, ghost town community and shuttered
| chat servers. Sponsored and abandoned by the Google Polymer team,
| or so it appears. Just sad.
| LAC-Tech wrote:
| Of what relevance is this?
|
| Custom elements are very well documented and work in every
| browser. Get your server to render html with your own elements
| in them - your own "island architecture", no vercel necessary.
|
| That some site promoting them is moribund doesn't change the
| fact they work - and are widely used.
| staticelf wrote:
| I tried to build an app with web components but honestly, the DX
| is quite bad and I abandoned the shadow DOM for light dom until I
| abandoned the vanilla tech stack entirely and moved the project
| to React. It is just so much faster to develop in React in
| comparison. Also when stuff goes wrong with components they many
| times just fail silently with no errors given to the console.
|
| You have such a great community with big, very well thought out
| libraries like Tanstack Query that is pretty nice to work with. I
| can have backend and front end code in the same repository in a
| simple way and reuse code.
|
| I also have the project in Phoenix Liveview which is also a much
| nicer way of using components. The thing is I don't really know
| which tech stack is gonna win so I made a small prototype in both
| to see different advantages / disadvantages.
|
| One thing is clear tho, pretty much everything is better than
| using vanilla components and it's really sad because I really do
| want to use vanilla components and I want them to be good.
| Meneth wrote:
| Nice, but it's no https://motherfuckingwebsite.com/
|
| See also http://bettermotherfuckingwebsite.com/
|
| and https://thebestmotherfucking.website/
| coxley wrote:
| Thank you! This is the resource I've been wanting to hand-feed
| web components to me.
|
| Looking forward to playing around with some personal projects. :)
| NoSalt wrote:
| 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#, JavaScript, Python, etc.)
| I feel like frameworks are only as popular as they are because
| product owners and managers like to tick-off the number of tools
| their developers use; makes them look important, knowledgeable,
| and efficient.
| dandelion9 wrote:
| 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.
| archarios wrote:
| I think a big advantage of a framework is that the team(s)
| don't end up arguing over architecture as much because the
| framework made those decisions for us. Also the framework has a
| proven history of this architecture working well for xyz
| problems. Also it makes finding compatible talent much easier.
| If you're using a framework, finding someone who has worked
| with that same framework for years makes it a safer bet that
| they will start being useful quickly. If you have your own
| bespoke system, it could be years until a new hire feels
| comfortable with the existing system's quirks and nuances and
| stops breaking things as much.
| frollogaston wrote:
| Big corps and certain teams need some standard to agree on. The
| problem is that often times, someone in charge pushes the wrong
| framework without due diligence, and either nobody speaks up or
| they ignore the feedback.
|
| Oh and it's way worse when said framework is home-grown. They
| can make something totally broken, and they don't take
| criticism well.
| jdlyga wrote:
| Who else considers plain vanilla web to be writing websites in
| pure html like it's 1995?
| kingbob000 wrote:
| As I work on personal projects I often have this internal battle:
| "Do I really need to use react for this small project? Doesn't
| this make it more bloated than it needs to be?" ...and then I
| create a vite react app and get up and running quickly while I
| still have the inspiration for the idea. There's something to be
| said for having an opinionated framework that just removes a
| large amount of extraneous decisions that can slow progress. I
| want a lightweight page but that is secondary to just wanting the
| thing I'm trying to make.
| lozzo wrote:
| I am so very pleased to see a site called "plain vanilla web dot
| com" being almost at the top of hackernews in 2025.
| frollogaston wrote:
| Am I misunderstanding something, or is the routing example
| suggesting I put an entire HTML webpage inside a JS string? This
| doesn't look like a reasonable alternative to React with JSX.
|
| https://plainvanillaweb.com/pages/applications.html
|
| Also, "the hash-based routing approach is effectively invisible
| to search engines."
___________________________________________________________________
(page generated 2025-05-12 23:01 UTC)