[HN Gopher] Plain Vanilla Web
___________________________________________________________________
Plain Vanilla Web
Author : andrewrn
Score : 526 points
Date : 2025-05-11 16:31 UTC (6 hours 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?
| 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.
| 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.
| 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.
| 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...
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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!
| 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?
| 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
| 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
| 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
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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...
| 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.
| 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.
| 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.
| 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
| 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
| 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.
| 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.
| 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 new 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.
| 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.
| 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 ?
| 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.
| 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.
| 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.
| 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.
| 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.
| 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
| 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
| chuckadams wrote:
| My problem with the "back to basics" people is it's always
| _their_ "basics" that they insist we go back to, and invariably
| those basics are decades-old practices because by golly it was
| good enough for them... To me, reactivity is one of the basics,
| as is static type checking of my templates.
| 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.
| 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.
___________________________________________________________________
(page generated 2025-05-11 23:00 UTC)