[HN Gopher] Ask HN: What happened to vanilla HTML/CSS/JS develop...
___________________________________________________________________
Ask HN: What happened to vanilla HTML/CSS/JS development?
I'm not a web developer, but I dabble in it because I find it
interesting. I went through some courses like The Odin Project and
others to learn the basics of HTML/CSS/JS, and I thought it made a
lot of sense: HTML structures the page, CSS handles the style, and
JS handles the functionality. However, after working for software
companies for a few years, it seems like almost nobody uses these
technologies in the way they're presented on websites like
w3schools to make web applications. Instead, they use component-
based frameworks like React. To me, these frameworks seem way more
complicated than HTML/CSS/JS, and I don't understand what problem
they're trying to solve. What makes the trade-off of all that extra
complexity and abstraction worth it? Aren't HTML/CSS/JS perfectly
fine and time-tested tools for web development on their own?
Author : silent_cal
Score : 245 points
Date : 2022-09-09 15:12 UTC (7 hours ago)
| TekMol wrote:
| I build the frontend of all my projects with plain HTML/CSS/JS.
|
| Every time I talk to developers who use frontend frameworks, I
| challenge them and say: Let's sit down and build the same
| application. You build it with React or whatever, I build it with
| plain JS. Let's see which one is leaner and more logical.
|
| Every time the answer is the same: The benefit of a frontend
| framework will not become visible in a small app. Only in a big
| app.
|
| Then I ask: Ok, where is the cut off? What is the smallest app,
| where React will shine? And I never get an answer.
|
| When I see React examples like this calculator ...
|
| https://github.com/ahfarmer/calculator
|
| ... which use 70 files (without dependencies!) to build something
| one could do in a single HTML file, I am afraid that those "big"
| apps the React proponents talk about will be _very_ big when
| implemented with React.
| Jabbles wrote:
| Another way to ask the question is how small are your projects?
| How many engineering-years do you put in each of them?
|
| If the cutoff is something like 10 years, what would your
| response be?
| ozim wrote:
| Parent poster is aiming at calculator app as "something
| people do in react and should be complex" - calculator app is
| still graduate level thing of limited scope and quite well
| defined. I assume he have not seen any project that grows for
| 5+ years has 20 dev working on it (20 because of team
| rotation maybe 3-5 working at the same time).
| potatoz2 wrote:
| The benefit of React is that it's declarative. Vanilla JS is
| imperative/procedural.
|
| If you build anything semi-complicated, you'll build your own
| declarative framework.
| naet wrote:
| I use both frameworks and non frameworks on different sites,
| some extremely large and some small. You can shoot yourself in
| the foot with either and I wouldn't make a blanket statement
| that one way is better than the other.
|
| I don't like the trend of using React to build a brochure level
| website with near zero ui interactions or api calls, it usually
| ends up bloated and a pain to try to split code, reduce bundle
| size, etc. for no real gains.
|
| On the other hand, when I work on a complex stock brokerage
| dashboard with tons of data, tons of fancy ui that needs
| frequent updating, and a massive internal state with tons of
| user data and stock data (also being frequently updated), React
| is a pretty good choice.
|
| One of my other sites is a legacy property with all UI powered
| by a single 6000 line jQuery and javascript file. It's very
| easy to break something without realizing trying to make
| changes there, so people keep adding new stuff at the bottom to
| minimize potential breaking changes. Definitely not the ideal
| vanilla JS setup but it isn't a good fit for the organization's
| needs.
|
| At the end of the day, react is javascript and you can make any
| react site with plain javascript... but it is sometimes a
| useful abstraction for highly complex environments with many
| people working on them.
| confidantlake wrote:
| Can you build Microsoft word or google maps or any of the 100s
| of other moderately complex web apps without a framework?
| wiredearp wrote:
| The top complex component in Word is the text editor while
| the tricky component in Maps is the map. Neither of those can
| be made with the frameworks we're dealing with here, so that
| is a go. We can make the traditional UI with a simple view
| library like lit-html [1] and we'll want to keep some state
| around, but most state managers can be rigged to Vanilla. I'd
| totally prefer Web Components to any popular framework for
| the particular apps you suggest.
|
| [1] https://lit.dev/docs/libraries/standalone-templates/
| Existenceblinks wrote:
| Funny thing is the two should be built with vanilla js and
| canvas. No popular framework is going to do better.
| potatoz2 wrote:
| The inaccessible to non-sighted users, non-computer
| interpretable canvas? The one where we'd need to reinvent
| text flowing, resizability, the box model, etc? That's what
| you think we should use to build our Web apps?
| busymom0 wrote:
| Obviously not Microsoft word but I built my resume builder
| using vanilla JS, html and css:
|
| https://resumetopdf.com/
| frumper wrote:
| That's a nice looking project
| pier25 wrote:
| Yes it's possible, the problem is dev time.
|
| Of course some sort of framework will naturally occur as a
| project grows.
| PaulDavisThe1st wrote:
| parent has already essentially admitted that the answer is
| no. they asked "where is the cut-off?"
| ozim wrote:
| * _Imagine that the biggest body of water you've ever seen is a
| dinky little pond and you think, "Yep, that's about as much
| water as there can be! There's nothing deeper or wider than
| this. Seeing water that stretches onward to the horizon, water
| that can turn into tidal waves, water that hides giant whales
| and creatures that have never seen the sun, that's just a bunch
| of tall tales."
|
| And maybe you can be happy sitting next to your pond, so long
| as you never see an ocean. Maybe when you meet people who tell
| you about the magnificent oceans they've seen, you figure
| they're just exaggerating what it's like to see a pond. "Ah
| yes, I remember seeing my first pond," you chuckle. But
| somewhere deep in your brain, there's a little twinge of
| doubt.*_
| pier25 wrote:
| > _Let 's see which one is leaner and more logical._
|
| Leaner, yeah, I'm certain a vanilla app will produce less KBs.
| What about dev time? I've been writing JS since the late 90s
| and I'd never use vanilla for anything other than trivial
| projects, quick tests, etc.
|
| More logical, that is 100% subjective.
|
| > _Ok, where is the cut off? What is the smallest app, where
| React will shine? And I never get an answer._
|
| Of course you won't. It's an impossible question. Could you say
| with certainty at which point it's better to use or not use a
| framework? (any framework with any language) You can't.
|
| Once you're deep into the swamp you may realize you should have
| used a framework... but it's often not obvious a priori.
|
| > _which use 70 files (without dependencies!)_
|
| Honestly that's kinda ridiculous. You could build a calculator
| with a single file and a couple of components. This is not a
| problem with using React or any other of the modern libs but
| with that particular programmer.
| culi wrote:
| > Honestly that's kinda ridiculous. You could build a
| calculator with a single file and a couple of components.
| This is not a problem with using React or any other of the
| modern libs but with that particular programmer.
|
| Yeah I'm trying to figure out how someone could possibly
| reach this number of files if you're not counting
| dependencies...
|
| If I make the app with the explicit goal of having as many
| files as possible I can think of:
|
| ~6 config files and dotfiles. Maybe make it TypeScript so we
| have a tsconfig.json as well and maybe we'll have a README
| and LICENSE as well for good measure
|
| In our public folder we'll have the index.html, a _redirects,
| robots.txt, a favicon, logos of different sizes, a manifest
| just in case, a sitemap because why not. Maybe a dozen files
| in total?
|
| But for the actual source files? index.tsx and App.tsx (I
| usually make these two the same file). Maybe we're keeping
| our jsx and css in different files so let's just double the
| number of components by 2. I'm struggling to think of why
| this might have to be more than one component but let's just
| say it's 2. So 4 files in total. Let's even say there's a
| custom hook for some reason so that gives us another file.
|
| That's like 7 files for the source code if we really stretch
| things out. Maybe you're one of those people that likes to
| have separate files for your routing or maybe you have some
| Layout.tsx business going on. Still can't imagine it
| stretching passed 10 files.
|
| I'm up to 28 with a ton of rounding up...
| ffhhj wrote:
| In my day job I work with frameworks, and do vanilla
| development for all of my personal projects. But then I realize
| that in the end I'm just building my own frameworks (DB,
| states, UI), that I might use or fragment and reuse in other
| projects, because it all becomes boilerplate, and the top level
| logic is what's different and actually matters.
| towaway15463 wrote:
| The web is now a virtual machine combined with a content delivery
| service and "web dev" companies are actually just building
| software that runs on it. If this were 1994 all of these
| companies would be shipping disks in boxes instead.
| replwoacause wrote:
| What is the easiest way for someone with HTML, CSS, and Ruby
| programming skills to add JS interactivity to a site? Would that
| be something like HTMX?
| krapp wrote:
| The problems that technologies like React, Typescript, NPM, etc.
| solve are mostly only relevant to startups and corporations
| needing to write business logic and correlate complex projects
| between teams. The point of front-end frameworks, for instance,
| is to reduce the roundtrip cost of requests and server-side code
| by compiling and rendering as much of the site as possible within
| the browser - an optimization that doesn't matter for most
| people, but matters when you're "web scale."
|
| Unfortunately, because the web is _serious business_ , all of
| that complexity became the standard for the entire ecosystem.
|
| Just using HTML/CSS/JS is considered either regressive or niche.
| It's called "vanilla js" which only shows how utterly locked in
| to the enterprise paradigm javascript has become, when what
| should be the default needs its own genre identifier to
| differentiate it from "the norm."
| an1sotropy wrote:
| Interesting point that "vanilla js" is kind of judgemental, or
| at least framework-centric. Maybe we should start saying "pure
| js", or "sparkling, refreshing, clean js", or whatever
| companies that sell bottled water call it.
| umvi wrote:
| IMO for things like static sites, or sites that only have some
| landing pages and a bit limited interactivity behind a login
| portal, vanilla HTML/CSS/JS is perfectly fine.
|
| The complexity of vanilla gets out of hand when developing web
| _applications_ (websites that feature menus and tools and widgets
| and state that the user interacts with - think JIRA or Gmail or
| Google Docs, etc)
| jamal-kumar wrote:
| I like to build things in ways where I try and avoid the use of
| JavaScript if I can, using vanilla typescript for most things
| that do need that. I really like seeing what is possible in pure
| CSS for stuff like animations if I can completely avoid doing it
| in JS/TS while still looking fresh. The component based
| frameworks make a ton of sense for when your project gets large
| and worked on by a ton of people though. Personally for most
| small things I don't think you need them, and a lot of more
| novice developers really rely on ridiculously fat npm packages
| which impact site performance - often what I end up doing is
| finding alternatives in that ecosystem which are smaller and more
| well written, it's not all hot garbage but a ton of it is
| unnecessary bloat. Most of these frameworks are very similar and
| easy to adapt to once you have learned one or two of them but
| they definitely can lead to a website that weighs like 5
| megabytes for no reason.
|
| I once inherited a project where the front end was split between
| like +20 different react projects across that many git repos
| which we really had to twist the arm of the original developer to
| get access to. That's definitely an example of doing it wrong.
| spapas82 wrote:
| Still going strong, I do it exclusively every day, maybe with a
| little splash of jQuery when needed!
| vdnkh wrote:
| ITT: non-web developers whining about JavaScript (a favorite
| pasttime of HN)
| hbn wrote:
| Or bragging about a pet project they made with vanilla
| HTML/CSS/JS that's any or multiple of:
|
| * not particularly impressive in terms of UI requirements
|
| * likely took them 10x the amount of time it would have taken
| if they just used a framework
|
| * doesn't make any API calls
|
| * doesn't manage any/much state
|
| * is composed of code that no one else would be able to easily
| hop into and refactor if working in a team scenario
| chrisweekly wrote:
| Great question. I'm short on time (and using my phone to comment)
| but TLDR, there's a spectrum from
|
| (A) "SPA by default" and piling on layers of abstractions
|
| to
|
| (B) properly leveraging the web as a platform, and mentoring the
| browser instead of micromanaging it
|
| ...and the trend is finally starting to move (back) towards (B).
|
| There's also a significant role played by the "document-based
| web" vs "web applications" paradigms' semi-dichotomy.
|
| You'll see plenty of (frankly sophomoric) takes like "webdevs are
| rediscovering that server-rendering HTML is a good idea, LOL,
| sounds like PHP or my cgi-bin Perl scripts from 1999" -- which
| ignore the need for client-side interactivity and responsiveness
| and the profound changes in the capabilities of clients,
| networks, servers, languages, and tooling over the intervening
| years.
|
| I highly recommend a close look at https://Remix.run and
| https://every-layout.dev (and probably https://Astro.build) for
| examples of frameworks and techniques that thoughtfully leverage
| the best of what's new as it continues to evolve, while being
| firmly grounded in from-first-principles foundations that enable
| creation of magic comprised of sane primitives.
|
| I've been building and improving web-related sites and apps for a
| living since 1998, and without reservation urge anyone involved
| in webdev to read up on both Remix and EL's "axiomatic CSS". They
| provide a profoundly well-informed and -reasoned perspective that
| answer your question and help show the way forward amid all the
| froth and churn and nonsense. It's the signal in the noise.
| mejutoco wrote:
| IIRC the email client https://www.hey.com/ and other 37signals
| projects use vanilla js.
|
| I did use Typescript without a framework to implement this ios
| calculator clone (https://getcalculator.app/) and it was not a
| bad experience at all.
|
| I wrote about it here (https://mejuto.co/the-ipad-did-not-have-a-
| calculator-so-i-po...)
| pengo wrote:
| I still write static sites which are hand-coded in HTML and CSS
| augmented by a (very little) javascript. They're quick to build
| and easy to deploy and, for some clients, they're all that's
| needed.
|
| I've used frameworks for twelve years, and covered most of them
| across various projects. I particularly like the direction of
| recent frameworks like Svelte and Vue3.
| gwbas1c wrote:
| One thing to point out: "web," as a UI platform, is very weird
| compared to Windows/Mac/iOS/Android.
|
| These frameworks bring in concepts that we take for granted in
| most other platforms.
|
| More specifically: When I "do web," I prefer generating HTML on
| the server. Working with text that way is very simple, but the
| paradigm breaks down when the page needs to update itself from
| Javascript.
|
| Javascript+html+css alone isn't nearly as powerful as the kind of
| UI tooling that I'm used to for Windows/Mac/iOS/Android. That's
| where the frameworks come in.
|
| The reason why they change so much is that so far, no one's
| really come up with a good one. I personally think we'll get
| there if we can replace HTML, because that's the real obstacle.
| For representing a document; it's really cool, but for doing true
| UI, HTML just makes everything over complicated.
| jraph wrote:
| Two things:
|
| - adding interactivity to a web page vs building an application.
| Those are not the same thing, and what you read applies to the
| first
|
| - there's a widely accepted belief that vanilla js is not
| suitable for building apps. I don't buy into this belief. I have
| a built networked Scrabble game with vanilla js. Both the backend
| and the frontend. This simplicity allowed external contributors
| not well-versed in the modern web stack to contribute. I also was
| able to enter the code of Pianojacq (from jacquesm) [1] and
| contribute quite easily because he also chose vanilla js. This
| simplicity is very valuable, and lost with modern framework, and
| nobody is really concerned about this.
|
| I've done some React development, so I know my way in a modern
| app. I've also contributed to a frontend written in Vue. I think
| they solve problems but bring complexity to the table, in
| particular the tooling (bundlers, minifiers, etc), the
| dependencies and the debugging being much harder.
|
| It seems DOM manipulation through native browser API scares many
| people, but when it's what you are familiar with, your usual
| "framework", it's manageable. You need to be disciplined to avoid
| things getting messy (a discipline frameworks partially enforce),
| but I really believe you can go far with vanilla js.
|
| I believe React & Co are often picked to ease beginners'
| contributions, but they actually do require expertise. I'd rather
| touch vanilla js code from a beginner or an experienced developer
| than a React code from a beginner.
|
| It's a matter of taste. Vanilla JS has the taste of fresh air to
| me. It's zen. You write the code and it runs. No tools, no slow
| compilation, no minification that complicates the debugging.
| Minification which is only useful because with those frameworks
| you bundle an awful quantity of code in the first place. Yes,
| source maps exists but they don't do everything.
|
| But today you won't have access to the whole ecosystem of
| existing React components with vanilla JS. It might be a curse or
| a benediction.
|
| [1] https://gitlab.com/jmattheij/pianojacq
| miragecraft wrote:
| It's still here, just no longer profitable.
|
| Frameworks are needed for web apps, especially single page
| applications (SPAs), if you just want to build traditional
| page/document based sites the traditional methods work just fine.
|
| However SPAs is where the money's at for developers, so
| developers tend to abuse it due to resume-driven development
| (RDD) in order to get themselves into better paying
| positions/companies.
|
| That's why tutorials and articles are all about frameworks now,
| just follow the money.
| theihor wrote:
| > resume-driven development (RDD) I love this phrase. Going to
| steal it. Thank you.
| francisofascii wrote:
| I recently started two small web projects (one personal, one
| work) using ViteJs, Html, Vanilla Typescript, CSS, and a .Net
| Core Web API. It has been a great dev experience compared to
| React and Angular, IMHO. Of course I have this sense of guilt
| that I should be using a framework. And if these web apps were to
| suddenly explode with unexpected screens and features, then it
| would get complex. But right now, it is a fast and pleasurable
| development experience.
| mrzimmerman wrote:
| I don't see anyone specifically talking about CSS, but that is
| something I still generally just write without any libraries or
| tools. I do use SASS at times because I like the nesting, but I
| don't always bother.
|
| In my 20 years working on the web I've found that a lot of
| styling libraries and tools like Bootstrap and Tailwind are great
| for getting off the ground quickly with a passable UI, and there
| are benefits for large teams to have a shared syntax and coding
| style that is well documented which these provide out of the box.
| But when it comes to overrides and general customization they can
| lead to people writing exotic selectors and using !important.
|
| People often get frustrated with CSS, especially when the page
| loads and things start to interact. I've always found that less
| is more with styling and I've fixed more problems in my career by
| removing and simplifying style declarations.
|
| CSS with variables, (and soon native nesting of selectors),
| animations, pseudo classes, and pseudo elements is quite powerful
| on its own. As long as there's internal documentation for code
| styles and encapsulation of classes to components (even outside
| of a JS framework/library) its very scalable.
| tkpremier wrote:
| Interesting. I love using SCSS, and personally won't write CSS
| without it. It's also not just for nesting but also for
| variables, mixins, and extend functions. SCSS, to me, has made
| css become more of programming rather than just markup rules,
| allowing OOP prototypal concept via mixins.
|
| Absolutely agree re: depending on Bootstrap. Unless you're
| heavily leveraged in BS (no pun intended) either cuz 1) you're
| at an "early" phase in your product or 2) you've bought into
| yet another framework and are stuck with it :), you should
| start creating your own scss mixins to encapsulate these
| components.
|
| My personal fave is to use scss w/ bem. The naming conventions
| coupled with nesting selectors also help real well to create
| long class names without having to type it all at one time
| [deleted]
| weard_beard wrote:
| TL;DR - People started using their mobile devices not just for
| apps, and not just to view static pages, but to spend money. They
| started expecting websites to behave like apps started spending
| money on websites that behaved like apps.
|
| We have frameworks instead of static HTML because it is really
| complicated to make a website behave like an app and it takes a
| LOT of javascript. We started out with jQuery ajax calls and
| media queries. We moved on to AngularJS to start swapping content
| in the page in larger chunks and maintain state and code better.
| We've now moved most/all of the site functionality into
| Javascript via React to better manage caching and state of the
| application for the best performance and more manageable code.
| bdcravens wrote:
| Remember that once upon a time, there were options outside of
| Javascript for high interactivity, most prominently Flash. At the
| time there was no need for Javascript to be more complex. So
| harkening back to a "golden age" when Javascript was simple is
| only telling half of the story.
| nightski wrote:
| Nothing happened there's just no need to talk about it every day.
| ranuzz wrote:
| To build an application a framework was always a requirement.
| Developers either used an existing one or created their own. And
| I believe it is true for any application development, the code
| you see in tutorial or courses are not the same in a professional
| environment.
|
| Same goes for HTML/CSS/JS, in fact, CSS and JS are the answer to
| the limitation of HTML and static page serving which was the
| vanilla www. As for your question, I don't see HTML/CSS/JS going
| anywhere, they are the building blocks of web development and are
| written as such.
| ggregoire wrote:
| I worked on a "web app" in the early 2010s, 10k lines of vanilla
| JS and jQuery, and it was a nightmare.
|
| Adding basic features or fixing the many bugs we discovered every
| day took hours or days. Any refactoring took weeks. We had to
| invent new abstractions on top of existing abstractions to keep
| everything more or less understandable and maintainable. Just
| splitting the code into different files (like to achieve some
| sort of frontend MVC and avoiding to have 5k lines of code in a
| single file...) and loading everything in the correct order was a
| puzzle. Making or changing any kind of edit forms was a real
| challenge too and prone to just adding new bugs to the list.
| Between loading all the data in AJAX, adding an id to each input
| and filling every input one by one with jQuery by copy/pasting
| their ids from the HTML, generating the selects and selecting the
| correct option(s) and adding them to the DOM, dealing with all
| the buggy jQuery modules like date and time pickers and their own
| ways to initialize and return data, showing or hiding parts of
| the form depending of the selected options, extracting the new
| values one by one from the DOM with jQuery once the user submits
| the form, validating the data and toggling the classes of the
| inputs to "error" with jQuery and adding error messages at the
| correct spots inside the DOM, revalidating the data and
| formatting it and sending it to the backend, refetching the
| values just to be sure everything is in sync and updating the
| values inside the DOM again with jQuery by copy/pasting ids and
| classes from the HTML... We take all this stuff for granted
| nowadays because the frameworks do it for us but it was so
| artisanal back then.
|
| Eventually I pushed to rewrite the app when Backbone.js came up,
| and we started using tools like grunt, and it was already a huge
| step forward. Then some years later we migrated to Angular 1, it
| was another big win in productivity. Eventually React came out
| and I started experimenting with it and I thought it was
| revolutionary. Its component paradigm allows to break the app
| into small manageable and reusable pieces and this makes
| everything simpler. And then Microsoft released TypeScript and
| now we have code safety and autocompletion on everything,
| including external packages. And we also have JS export/imports,
| fetch, async/await and so on... And tools to test all the logic
| and interactivity in our apps.
|
| Nowadays frontend development is just so much easier than before.
| I can't believe that people who think the opposite have actually
| worked on any sort of real life big frontend projects in an
| enterprise environment (1 or several teams working on the same
| codebase, new non-trivial features to implement every day).
| davidn20 wrote:
| If you don't understand the problem they are solving, you're
| still very green in the field. Try to implement a basic data bind
| input field and display the value in the DOM with react vs with
| just "vanilla js". You'll see the difference right away.
| julianlam wrote:
| https://jsfiddle.net/craqvoxz/
|
| 3 mins... or were you looking for a server-side component as
| well?
| silent_cal wrote:
| I already said I'm not even in the field - I just dabble in it.
| But thanks for your input.
| davidn20 wrote:
| Sorry, I missed that part
| [deleted]
| fullstackchris wrote:
| How are you going to manage interantionalization, testing,
| sessions, etc. with just these tools?
|
| (In before people say, "but that's all I need for my blog!" Fine.
| go ahead and do that then. I'm talking about international huge
| scale applications)
|
| What you'll do if you stay the purist and need to implement
| aformentioned services is that you'll eventually end up with some
| sort of quasi-framework, but bad in the sense that only you (or
| perhaps your team) know how it 'works'. With most frameworks
| there are at least opinionated ways to go about implementing all
| these things, and you can find other teams and consultants who
| speak this 'language' so to speak.
|
| Being a purist is fine, but it really grinds my gears when people
| assume vanilla is ALWAYS the solution, and it can 'easily' be
| applied to things like e commerce shops, huge shared tools, or
| big social apps. Hint: it can't, unless you like a lot of pain.
| rozenmd wrote:
| JS development in particular is relatively verbose, so folks
| started writing little helper libraries to get things done
| faster.
|
| Folks open-sourced their libraries, others contributed, and we
| eventually wound up with frameworks.
| LEDThereBeLight wrote:
| I think there's a core difference between helper libraries and
| frameworks like React. JQuery is a helper library, but the
| purpose of React etc are more to manage state, improve
| efficiency, and pave over security and browser inconsistency
| issues more than they are to reduce lines of code.
| [deleted]
| Existenceblinks wrote:
| I have a half-serious way to fix _symptom_ here: everyone gets
| into javascript is required to implement their own `ui=f(state)`
| framework, maximum size is 10kB minified.
|
| 80% of them will be amazed how easy it is. I bet 20% of those
| implementation each would cover 80% of application use case
| today.
| awb wrote:
| The same reason frameworks are popular in any language:
| convention over configuration.
|
| In a native lang there is are near infinite choices to make in
| implementing a solution and no two developer's native code
| typically looks the same. Jumping into a vanilla JS codebase can
| sometimes take more time because you have to discover and
| understand the choices the developer made. The code is highly
| configurable but lacks a common convention.
|
| With a framework, _some_ of those choices have been made for you.
| So, jumping into a framework codebase is sometimes easier and
| simpler for those that understand the framework. The code adheres
| to a public convention at the expense of being less configurable.
| [deleted]
| nfw2 wrote:
| The thing I've found about working with React (and the web
| frameworks like Vue and Svelte), is that once you embrace a
| component-centered model, it makes virtually all web development
| easier, even relatively simple projects.
|
| There certainly is a decent subset of web development work where
| HTML/CSS/JS is still reasonable and viable, but it tends to be
| less complex, and low-code/no-code tools like Wix or Retool are
| quickly taking over that space.
| pjmlp wrote:
| SSR always supported components.
| P5fRxh5kUvp2th wrote:
| hush now, that's supposed to be a secret they only learn once
| they start working outside of node.
| pjmlp wrote:
| You're right. :)
| nfw2 wrote:
| The purpose of a React component is more than just rendering
| HTML nodes. Furthermore SSR can only do so once per page load
| pjmlp wrote:
| Just like SSR frameworks have been doing for 20 years,
| including JavaScript integration.
|
| https://www.primefaces.org/showcase/index.xhtml
| nfw2 wrote:
| What I originally meant by the "component-centered model"
| of React is not that it gives you a prefab list of
| elements to include on a page. I meant that it gives a
| framework for organizing custom logic to coordinate the
| behavior of some DOM subtree.
|
| Also the library you linked can hardly be considered
| vanilla HTML/CSS/JS
| pjmlp wrote:
| Just like JSF was doing 20 years ago.
|
| It surely is more vanilla, as originally it was designed
| to work with JavaScript disabled, if so desired.
| nfw2 wrote:
| If JSF has abstractions that encapsulate arbitrary units
| of logic running on the client, then it is a frontend
| framework, by definition of frontend framework. If it
| doesn't, then we aren't talking about the same thing.
|
| Also vanilla HTML/JS does not mean html that works if JS
| is disabled. It means you are literally writing out the
| document that is delivered to the user without
| transformations or a huge runtime library included.
|
| This JSF is not vanilla HTML: <p:commandButton
| value="Update event2" update="@obs(event2)" icon="pi pi-
| check"/>
| potatoz2 wrote:
| I don't understand your comment completely. The "traditional"
| SSR frameworks (PHP, Rails, Express) didn't make it easy to
| componentize things, instead trying to divide logic by broad
| category (MVC, etc.). I don't know whether it's orthogonal to
| Web development or caused by its complexity, but the
| emergence of components as a primary unit of abstraction is
| meaningful IMHO.
| IYasha wrote:
| But you also get yourself dependent on fw devs. And they most
| certainly don't care about you, your needs and your customers.
| Wix? That Wix that broke support for all old browsers and
| devices? Lost views and customers? Thanks, but NO, THANKS. And
| you, as a site owner, can do NOTHING. You rely on what you're
| offered. They break it - you're screwed.
| nfw2 wrote:
| If you mean framework devs, I disagree that they don't care
| about you. Frameworks are generally free and open-source, so
| creating a valuable product for the community is arguably all
| they care about. Maybe meeting the specific domain needs of
| an individual user is not compatible with their
| implementation or roadmap, but it's not because the devs
| don't care.
|
| I was not recommending Wix, and obviously there are plenty of
| downsides to using something like it. The fact remains that
| it has captured a lot of the market that would have used
| vanilla HTML/CSS in the past. That is what the OP was asking
| about.
| edmcnulty101 wrote:
| Doesn't the browser now have native web components and this
| will replace React as time continues?
| lelandfe wrote:
| Ya, but you gotta roll your own process for the stuff React
| and co. provide easy methods to do. It's just a lot of
| boilerplate for small projects. I don't know if web
| components will really be a "library killer" in the same way
| browser APIs have done with jQuery.
|
| https://github.com/mdn/web-components-
| examples/blob/main/pop...
| dbxkcichhdfufu wrote:
| Octoth0rpe wrote:
| React is about a whole lot more than just web components.
| It's also a strategy for state management, life cycle, etc. I
| don't expect web components will ever replace react, but I
| think it's possible we'll see a new generation of react-like
| competitors that use web components under the hood.
| tkpremier wrote:
| This isn't a one-or-the-other situation. A web developer should
| and would choose the right path depending on the scope of the
| website. Mainly, is it a web page or a web app? If it's a landing
| page or even a blog, i'd say vanilla HTML/CSS/JS is just fine.
| It's when you get to data manipulation, state manipulation, and
| user interaction that React is very helpful...
|
| Same with BackboneJS and Angulars of the past, and if society has
| taught us anything, it's that there always be a NEW and IMPROVED
| one-framework-to-rule-all the other frameworks.
|
| Also, the state of JS in browsers are way more "consistent" than
| the IE wild west of the 90's and 00's, which was why jQuery was
| so popular. And that began our dependency on plugins to provide
| consistent dev codebase in between browsers. So if you REALLY
| think about it, it's the browser vendors' fault for why "vanilla"
| HTML/CSS/JS seems to have so much tooling.
|
| In the end...figure out what you're trying to build, and know
| that if it gets too complicated in straight up HTML/CSS/JS,
| there's plenty of frameworks to help you organized.
| asadkn wrote:
| I'd say that most of the websites still use HTML/CSS/JS and are
| server-side rendered - well, at least 40%+ of the web does
| (WordPress).
|
| The distinction mainly is in the apps. Yes, web apps almost
| always use a framework like React now. Others have already
| explained the whys.
|
| However, it's still possible to do webapps the traditional way,
| with the server-side approach, adding only a little interactivity
| via JS - techs like LiveView and HotWire: https://hotwired.dev/
| asiachick wrote:
| I want to add, I like typescript, I think React is okay. What I
| hate is the build steps.
|
| I tried create-react-app and it's basically on mimimal support,
| updates broke stuff, outdated deps, devs unresponsive, ...
|
| What is the simplest, least likely to break, minimal dependency,
| live update tool chain for typescript, and or typescript + react?
| treis wrote:
| It's only relatively recent that you could write vanilla
| HTML/CSS/JS & have it work. There were inconsistencies across
| browsers and browser versions. Frameworks like Jquery came about
| to paper over those inconsistencies.
|
| It's similar for CSS with the added twist that it's a fair amount
| of work to get something non-hideous. Much better to start with
| something reasonably good looking and tweak from there.
| vagrantJin wrote:
| They are being used. Its just that frontend is a moshpit.
| Everyone wants more overhead and complexity, mostly to justify
| the high salaries.
| nfRfqX5n wrote:
| Nobody wants more overhead or complexity. Users expect
| complicated features as a baseline experience.
| vagrantJin wrote:
| Ofcourse. It's the users fault.
| oxff wrote:
| I'd say 80% marketing and "monkey see, monkey do" effect.
| unity1001 wrote:
| I blame Facebook/Twitter/Social for this.
|
| With their rise in mid 2000s, having a framework with which you
| could manipulate the entire dom real-time to reflect the state in
| the backend have been accepted as obligatory.
|
| Whereas in reality, aside from the neat templating that
| frameworks like React bring to the frontend, there is absolutely
| no need for the majority of web applications to be able to send
| micro updates to the client like how it is obligatory for social
| networks or other apps that are heavy in user interaction.
|
| The least thing that you would want to do when a user is going
| through an ecommerce checkout process is to manipulate the dom
| and change stuff that could distract the user from the checkout
| process, for example. If you need to update some info with the
| changing quantities in the cart or address, that could as well be
| done with simpler stuff like jQuery - considering that your site
| does not have such features that will cause your jQuery to bloat.
|
| There is even less need in the majority of the web where only
| content is consumed - how much interactivity do you need for a
| news article at the guardian or even your local-news blog? The
| user will just want to read the article. He or she may not even
| bother to comment (and likely wont), and when they comment, you
| definitely don't need a full fledged framework manipulating the
| dom to post and refresh the comments section. HTML and the
| browser already sort that out.
|
| ...
|
| The overall idea is sound, yes. A better form of presenting and
| manipulating the dom is a good thing. But, the bloated frameworks
| and the dependency hell that we created for ourselves do not look
| like the way to do it.
| Aperocky wrote:
| Self promoting plug:
|
| It still works fairly well on the relatively small scale if you
| just want to write a frontend app (i.e. simulations):
|
| https://aperocky.com/cellular-automata
|
| https://prehistoric.tech
| softcactus wrote:
| Wow that cellular automata sandbox is almost identical to
| something I wrote a while back! You might find this article
| interesting for running arbitrary code in a browser sandbox:
|
| https://blog.risingstack.com/writing-a-javascript-framework-...
| Ambolia wrote:
| Pure HTML/CSS/Js either devolves into spaguetti code very fast,
| or requires you to put very hard conventions to avoid it.
|
| Component Frameworks give you more structure that organize the
| projects in more sane ways.
| spaghettiToy wrote:
| I make little JavaScript stuff on my WordPress site, does that
| count?
|
| No react needed.
| [deleted]
| weard_beard wrote:
| TL;DR - People started using their mobile devices not just for
| apps, and not just to view static pages, but to spend money. They
| started expecting websites to behave like apps started spending
| money on websites that behaved like apps.
|
| We have frameworks instead of static HTML because it is really
| complicated to make a website behave like an app and it takes a
| LOT of javascript. We started out with jQuery ajax calls and
| media queries. We moved on to AngularJS to start swapping content
| in the page in larger chunks and maintain state and code better.
| We've now moved most/all of the site functionality into
| Javascript via React to better manage caching and state of the
| application for the best performance and more manageable code
| that leverages APIs for most of its data and content.
| adamredwoods wrote:
| Security, scaling of development, and progression of language
| features.
|
| The larger a code base gets, the more complex it can be, and
| frameworks help abstract ideas (like design systems), rather than
| having to repeat component code, css, each time it is needed.
| Also, if more developers are being added to the code base, the
| scaling of a project can get quite large. We have over 50
| developers working at my company coding on the website.
|
| Security is another. When updating a list of items (for example)
| from a fetch, vanilla js will require direct modification of the
| html, whereas a framework like React will handle that, with best
| security practices applied, as the code has been written and
| production tested.
|
| I'm not going to deep dive on language features, can be quite
| subjective, for example how great Typescript is (compiler errors
| > runtime errors), or how SASS fills in a lot of missing features
| for CSS, etc.
|
| I think some websites could be done in vanilla JS/HTML/CSS, but
| as the site scales, I feel at some point a developer would build
| their own framework to make things easier and streamlined. It's
| what developers do.
| softcactus wrote:
| I kind of sought to answer this for myself in a roundabout way.
| My first experience with web dev was React. I never learned "why"
| so on a recent personal project I figured I'd start from the
| ground-up.
|
| First I wrote a little 'RTS' game in Javascript where the player
| writes code for the units in game and runs the code in the
| browser. But the player/programmer needs more info about the
| game's state. Which means I need dynamic html components to
| display the changing state of the game. Easy enough, I used a
| lightweight library called slim-js to give me the functionality I
| needed minus the ugly boilerplate of the Shadow Dom. But now my
| dynamic components were re-rendering every single frame, since
| they were tied to a callback that was triggered when the game re-
| rendered. Ok, I'll just save the state of the game into a map and
| only update when there's a missing value or a new value. But all
| of this state management and custom component logic is overhead
| that makes the page harder to maintain.
|
| I also wanted to use typescript to make sure I was passing the
| right values back and forth, which means transpiling every time I
| make a change. I also need to serve the index.html with a
| webserver, so I can import ES modules. Http-server works well
| enough for this, but what if I want to add another page to my
| site for watching tournaments run on the backend?
|
| It was a nice exercise to learn /why/ frameworks like React
| exist. Moving forward I'm definitely going to move to a React-
| based page since I'm already starting to outgrow my vanilla-ish
| stack.
|
| Here's the game if you'd like to check it out: https://ai-
| arena.com/
| jppope wrote:
| I actually have to disagree a little bit... The rise of static
| site generators have filled a void there of where you can have
| reuse but you don't need to head off into framework land. I do a
| lot of projects now (using SSGs) where most of the work is plain
| jane html/css/js
| jtolmar wrote:
| There's a few parts to it.
|
| javascript used to be awful. Using JQuery was more or less
| required to have a decent API and not have your entire app full
| of polyfills. Those days are behind us, but the precedent
| remains.
|
| Some javascript APIs are still pretty bad. Fetch and
| XMLHttpRequest are both really warty in their own ways, to the
| point where you're probably writing a wrapper function. Common-
| enough collection operations are missing, you'll need to write
| some sort of utils file. So you're definitely going to want at
| least some sort of small library for the missing stuff.
|
| The DOM forms a parallel, persistent tree to your application
| state, and you need to manage the relationship between that and
| your app. Parallel state trees just always suck (I've also dealt
| with them in Box2D, some game engines, SVG renderers...), it's
| probably an antipattern. It's not that big of a deal for a small
| app, but for larger ones it starts getting hairy. And it
| certainly feels like you should be able to write a better API
| easily enough, but because the problem is that the entire DOM is
| based on a parallel state tree model, your wrapper library ends
| up getting large before you know it.
|
| There are good technical reasons to use some sort of build system
| for your web content. Concatenating and minifying all your
| javascript helps a ton. But to do a really good job of minifying
| you basically need a whole compiler, and at that point you might
| start pulling in all sorts of clever transformations that seem
| like a good idea.
| PaulDavisThe1st wrote:
| > Parallel state trees just always suck (I've also dealt with
| them in Box2D, some game engines, SVG renderers...), it's
| probably an antipattern.
|
| Just to reinforce this ... this is the case even with native
| desktop GUI toolkits. Take the example of GTK. You build a
| model for a tree/list view using the "nice" data types GTK
| provides. In Gtkmm (the C++ bindings) it's even easier and
| actually feels very idiomatic.
|
| However, if you already have a model data structure somewhere
| in your code for other reasons (for example, your "backend"
| code isn't allowed to use GUI toolkit objects or APIs), you now
| have parallel state trees, and they suck just as much here as
| anywhere else.
| txdm wrote:
| In my experience, just having the ability to "modularize" the
| common elements on pages of a site (navbar and footer, for
| example) is the biggest task for most simple websites. There are
| lots of frameworks out there that do this, at the expense of
| making everything else on the website "html with extra steps".
| React comes close to solving this, but there's not a "react lite"
| that does it more elegantly that I know of.
| AngeloAnolin wrote:
| I think the reality that there's little (to none at all) job
| posting which would only require application development in
| vanilla CSS/JS/HTML is the main reason why frameworks dominate
| the land.
|
| While I see the value of using vanilla stuff, the complexity of
| software requirements, ever evolving browser APIs and features
| and increasing ease of using libraries (i.e. date-fns, lodash,
| etc.) has definitely increased the appeal of frameworks.
| lofaszvanitt wrote:
| You have to somehow employ more people and slow down corporate
| growth, so React was introduced, plus google idiocies like WEB
| VITALS... oh my friggin god, web development went full retard
| mode in the last 5 years.
| cyral wrote:
| Web vitals were created specifically to address the user
| experience issues often caused by slow JS websites: things
| jumping around as they are loading, things being unresponsive
| until some script initializes, etc. Using these metrics for
| search placement now incentivizes website owners to take them
| seriously and fix them.
| have_faith wrote:
| > I don't understand what problem they're trying to solve
|
| Building highly stateful / interactive web apps. If your web app
| is sufficiently complex enough then your vanilla js solution will
| just become an undocumented framework in disguise. When you build
| a homegrown system that manages components and their lifecycles
| (reacting to state changes) then you've written a framework that
| no one else has experience or knowledge of.
|
| > What makes the trade-off of all that extra complexity and
| abstraction worth it?
|
| Interactive UI's that react to state changes are hard to manually
| manage as complexity increases. Your UI and state are connected
| by an undocumented large state machine. These frameworks
| essentially allow you to define how your state, in any shape it
| may take, should be reflected in the UI (DOM).
|
| > Aren't HTML/CSS/JS perfectly fine and time-tested tools for web
| development on their own?
|
| Sure, but all of the frameworks are written in JS and you write
| plain JS to use them. You might use something like JSX or
| TypeScript for convenience, but these are turned into plain JS.
| They're also not required, they've just become standard because
| of how convenient they are.
| giaour wrote:
| The HTML/CSS/JS platform offered by modern browsers is very
| powerful and approachable, but the web's security model prevents
| most platform customizations. Browser-managed navigation, form
| submission, control appearance, etc, is largely a take-it-or-
| leave-it proposition.
|
| JS frameworks allow front-end developers to get around this
| limitation by rebuilding parts of the platform as a JavaScript
| application. For example, if you want to customize how navigation
| works on your page, you can either use the few, limited hooks
| offered by the browser (e.g., registering window.onunload
| callbacks), or you can make navigation an application concern by
| writing your site as a single-page app. There are plenty of
| things you just can't do with a framework-less multipage site
| (like animate transitions between pages) that are possible once
| you make navigation an application rather than platform concern.
|
| I can understand why many enterprise teams choose to use front-
| end frameworks like React even when it would arguably be faster
| and easier to just use vanilla JS, as there's a risk someone may
| need to add functionality that is not supported by the native web
| platform. For personal projects, though, I use vanilla JS and
| HTML.
| jjcm wrote:
| FWIW, I chose to make my side project I've been working on for
| the last couple years an entirely vanilla js SPA. The biggest
| downside I've noticed vs using something like React is my speed
| of development is much slower. The upside though is the code
| itself is extremely efficient / packages sizes are small.
|
| For my own project this is great - I have no deadlines, and half
| of the process is me just enjoying writing the code. For an
| existing company the demands are different. Not only are there
| time pressures, but aligning on something like React means you're
| introducing convention into the code. Hiring people who already
| know this convention is easy.
|
| Vanilla js, even with webcomponents, just isn't quite there as
| far as convention and speed go, and there isn't a rich community
| around it. Is it perfectly able to do the task at hand?
| Absolutely, but at a price most companies aren't willing to pay.
| React is the easier of the two.
| bcrosby95 wrote:
| Where these basic technologies really start to fall down is when
| your pages become increasingly dynamic. You start running into an
| issue where you have to define your structure multiple times:
| once in HTML, and at least once in JS since that's where you're
| dynamically updating things.
| superkuh wrote:
| It still exists and it is the best form of website. The UK
| National Health System (NHS) use it extensively for their health
| infrastructure and it supports all devices intrinsically. This
| was a huge boon during the earlier pandemic where many other
| government websites were having to roll back their advanced
| features and re-enable older protocols to cover all citizens.
|
| Corporations generally can ignore the majority of people and only
| concentrate on their target market. If their target market can be
| coerced into using SPA and other application based weapon design
| then that's easier and cheaper for teams of paid developers to
| do. If only because most modern web devs are trained to make such
| JS applications.
|
| But everyone else, individual humans, institutions, governments,
| they should try to make their websites accessible to all. It's a
| shame that few are.
| frosted-flakes wrote:
| Why do you think JS frameworks can't be used to create
| accessible websites?
| superkuh wrote:
| There's this assumption by for profit business that all
| people will have modern software with modern JS support.
| They're wrong and the tools they use to measure such things
| are implemented in a way they won't ever know they're wrong.
| What JS is in terms of what features are used to write those
| frontends changes far faster than the software that resides
| on a great many people's computers.
| caeril wrote:
| The _real_ meta-question here is why does everyone want to write
| SPAs in the first place?
|
| This is an era of ubiquitous 100mbps+ connections, CDNs, and
| edge-computing-two-hops-from-the-customer hosting. The whole
| reason we invented SPAs (bandwidth savings and latency)
| predicated on AJAX has been obviated.
|
| We can return to serverside HTML/CSS and forms with no loss of UI
| quality.
| yakkomajuri wrote:
| The key reason web frameworks dominate these days is that it's
| very hard to keep the UI in sync with state.
|
| That's it - that's the problem they solve. People started writing
| vanilla HTML/CSS/JS and struggling to make "reactivity" (hence
| React) work well when web applications got complex with a lot of
| state to manage. So we started building frameworks on frameworks
| and abstractions on abstractions and ended up where we are today.
|
| It's gone a bit far but the overall purpose is a valid one.
|
| (From someone who has used React professionally but uses vanilla
| HTML/CSS/JS for his personal website)
| [deleted]
| masswerk wrote:
| Personally, I find it easier and faster and more flexible doing
| it vanilla style. However, you still have to come up with your
| own abstractions (those you actually need), meaning, you have
| to own the stack. This may be a good thing, but is it is also
| challenging regarding human resources.
|
| As I see it, frameworks are really about making code
| accessible, while owning as little as possible of it, by this
| favouring sharing and the interchangeability of work force.
| Also, they establish a code policy and the kind of general
| approach, which is again favourable with regard to human
| resources. (Now you can have multiple phases of development,
| where neither team knows anything of the other, which would be
| hardly possible, if you had to own and maintain the stack. In
| the old paradigm of art versus engineering, it's a massive
| shift towards the latter. Which certainly is in line with the
| general trend.)
| jcpst wrote:
| I think it's a great exercise to come up with declarative
| abstractions over the DOM API. I had quite a bit of fun doing
| this. It only took a few hundred lines of JS to make a core
| for a useful web app.
| masswerk wrote:
| Moreover, `Object.handleEvent()` allows you to handle any
| events centralised inside an object and in its specific
| context since the days of Netscape 4.0.
|
| (Which is something many frameworks try to fix, ignoring
| that it's already in the core language. Admittedly, IE
| didn't support this before IE6, but by now this is really
| cargo cult. If there is `addEventListener`, there's also
| `handleEvent` and no need for extra bindings.)
| alfonsodev wrote:
| I'm in web development since 2000s, at that time there was
| pretty good web authoring tools like Macromedia Dreamweaver.
| Everything got complicated because a fundamental limitation of
| the HTML document model: having dynamic pages. Imagine creating
| and maintaining a catalog by having a single .html file for
| each item in the catalog.
|
| I believe with Dreamweaver MX you could have sort of a template
| and generate the static pages.
|
| I think this solution wasn't massively adopted because you had
| to rely on Macromedia server side ( Cold Fusion ).
|
| That was when PHP and ASP entered the scene allowing you to
| have dynamic pages in a linux or windows server.
|
| At that time, javascript implementations and rendering engines
| had massive discrepancies, Internet Explorer, Mozilla .., and
| to solve that emerge the first (that I recall) massively
| adopted javascript libraries, jQuery & Motools.
|
| Then Ajax[1] became popular because it made posible to interact
| with the server without refreshing the page, and that's when
| managing state became a problem in the browser as SPA started
| to become more and more complex.
|
| It's amusing seeing how we went full circle when SPAs have
| gotten so heavy and slow that now static page generation it's
| sold as a killer feature in Nextjs.
|
| When we could do this in 99's version of Dreamweaver with a
| nice UI. Maybe it's not a fair comparison, but you get my
| point, >20 years and see where we are.
| rcarmo wrote:
| $DIVINITY, how I miss Dreamweaver and Fireworks. Dreamweaver
| was good, but the way Fireworks let you edit images in both
| bitmap and vector mode and saved it all as extended info in
| PNG files you were always able to view everywhere...
|
| So sad that Adobe killed them off. I would still be using
| Fireworks today if I could.
| pier25 wrote:
| > _to make "reactivity" (hence React)_
|
| You put it in quotes but some might be missing the point you're
| making which is that React is not reactive.
|
| See this quote from the docs:
|
| > _There is an internal joke in the team that React should have
| been called "Schedule" because React does not want to be fully
| "reactive"._
|
| https://reactjs.org/docs/design-principles.html#scheduling
| pier25 wrote:
| Another point I'd like to make is that you don't really need
| reactivity.
|
| Frameworks like Mithril or Imba are not reactive, at all, and
| they work just fine for many use cases. The advantage is that
| state can be just vanilla JS. No need for any abstraction.
|
| For example Mithril re-renders everything to the VDOM after a
| user event (click, etc) automatically. You can also tell
| Mithril to redraw [0] eg if you have a WS handler or
| something state change not related to user input.
|
| I think Imba works very similarly but I don't have much
| experience with it.
|
| It's a super simple mental model which I like a lot more than
| anything else. I'm mainly using Svelte now though for other
| reasons.
|
| [0] https://mithril.js.org/redraw.html
| jraph wrote:
| > The key reason web frameworks dominate these days is that
| it's very hard to keep the UI in sync with state.
|
| I think that's it. I wonder how far we could go with vanilla js
| + a dead simple central store implementation that would help
| update the UI at different places when a value changes.
|
| You might end up re-inventing Svelte by attempting this though.
| CraigJPerry wrote:
| Someone posted this here a while back:
| https://github.com/1Marc/todomvc-vanillajs-2022/tree/main/js
| - i bookmarked it because i thought it was well done
| jraph wrote:
| Very interesting indeed. That's some food for thought.
|
| Though I should note that if this code has a "store.js"
| file, this is not the kind of store that I had in mind.
| More like the Svelte store [1], or Redux (which I find
| awfully complex).
|
| I didn't know the "storage" event on Window [2] (which, for
| the record, triggers when localStorage is modified from
| another page. Does not trigger when modified from the same
| page, which makes localStorage not sufficient as-is to
| build the kind of store I'm referring to).
|
| [1] https://svelte.dev/tutorial/writable-stores
|
| [2] https://developer.mozilla.org/en-
| US/docs/Web/API/Window/stor...
| CraigJPerry wrote:
| >> Does not trigger when modified from the same page
|
| I'm thinking that's the purpose of
| https://github.com/1Marc/todomvc-
| vanillajs-2022/blob/main/js... - without dispatching that
| custom save event, there wouldn't be a way to react at
| any other locations on the same page to the store
| updating.
| fknorangesite wrote:
| > You might end up re-inventing Svelte by attempting this
| though
|
| And then in the next breath make some joke about the
| proliferation of so many different js frameworks.
| mmcnl wrote:
| Indeed you will re-invent React/Vue/Svelte.
| gremlinsinc wrote:
| That's how it starts... React/Vue/Svelte are too
| big/bloated for what I want to accomplish...
|
| 1000 hours later and 200k lines of code... I just built the
| next React/Vue/Svelte, now there's even more options to
| choose from, with same amount of bloat,just different
| because 'my way' is better than 'their way' - maybe.
| ak39 wrote:
| And Svelte is a "reinvention" of Knockout, just requiring a
| precompile. (Not complaining at all, thank goodness we have
| such choices.)
| numtel wrote:
| In a recent project, I wrote my own template class that works
| kind of like Lithtml but without any kind of magic
| reactivity. It just rerenders when properties are updated
| through the "set()" method.
|
| https://github.com/numtel/democratic-
| capital/blob/master/src...
|
| An example template:
|
| https://github.com/numtel/democratic-
| capital/blob/master/src...
| ak39 wrote:
| Well explained, thank you.
|
| When did "data binding" become "reactivity" (why the need to
| create a whole new lexicon for the same ol' thing)? A lot of
| this confusion (as per the OP) could have simply been explained
| away by saying we needed frameworks to _bind_ HTML (visual
| components) to data. Two-way binding existed in many desktop
| frameworks before SPAs were even thought of.
| [deleted]
| xmonkee wrote:
| >The key reason web frameworks dominate these days is that it's
| very hard to keep the UI in sync with state.
|
| This isn't wrong, but going one level down, this is how it
| bites you:
|
| - The imperative DOM api just suuuucks. Please try it for
| yourself to see. Even if you're writing a very limited bit of
| reactivity in your app, you will be forced to invent your own
| declarative framework very soon.
|
| - Very hard to make reusable components (at least before
| webcomponents, which I haven't used personally)
|
| If you want to stay close to vanilla, I recommend one of the
| following solutions:
|
| 1) https://htmx.org/ 2)
| https://github.com/hyperhype/hyperscript 3)
| https://github.com/vuejs/petite-vue
| dxchester wrote:
| We developed El to be as minimal as possible, while still
| solving the problem of keeping state and interface in sync:
|
| https://github.com/frameable/el
|
| It's just ~150 lines / 2kb, and leverages existing browser
| functionality to accomplish most of the hard parts. Has
| observability, reactive templates, scoped CSS, no need for a
| build process, etc.
| hilti wrote:
| Interesting - looks pretty similar to Framework7 components
|
| https://framework7.io/docs/router-component
| acqbu wrote:
| This looks very interesting, I'll give it a go
| amadeuspagel wrote:
| If you want to stay close to vanilla, I'd recommend lit:
| https://lit.dev/
| BenoitEssiambre wrote:
| I sometimes use an even closer to vanilla option based on
| just the Lit templating engine:
| https://benoitessiambre.com/vanilla.html
| Existenceblinks wrote:
| Or https://github.com/WebReflection/uhtml
| tgflynn wrote:
| I'm still learning modern web development but here's a simple
| demo app that I wrote using only plan vanilla HTML/CSS/JS:
| https://tgflynn.github.io/AlgoVis/ (github link:
| https://github.com/tgflynn/AlgoVis).
|
| The fact that this works, didn't take long to write (though
| I'm very much still learning this stuff) and is very fast
| leads me to question your statement that "The imperative DOM
| api just sucks".
| wonnage wrote:
| I'm always amused at people who spend like a month learning
| something new and all of a sudden have opinions on the
| entire state of software development.
|
| They are of course the valid opinions of a neophyte but
| don't expect anyone to take you seriously.
| guilherme-puida wrote:
| > simple demo app
|
| I don't think you can judge if the DOM api sucks if you are
| using a "simple demo app" as your baseline, though.
| tgflynn wrote:
| All software is built from simple primitives. If the
| fundamentals are solid scaling up should be just a matter
| of managing complexity in your own code. I'm aware that
| performance problems that I don't have direct control
| over could occur at some point, but would that be the
| fault of the DOM API itself ?
| arbitrage wrote:
| so, yes, you are not wrong. the issue here is the
| differential of 'managing complexity' with regards to
| time.
|
| as the functionality of the app progresses beyond a
| certain complexity (admittedly, this is nebulously
| defined), increasing changes to complexity require more
| time to effect.
|
| beyond a certain point of functionality, the need for a a
| framework to manage these things becomes emergent. at
| that point, a single coder can resume making more complex
| changes with the aide of the framework, than she could do
| without it.
|
| you're not wrong, you just are not considering a big
| enough scope over which to evaluate what the manual
| manipulation of software primitives is worth.
|
| in the end, frameworks aide results beyond the ability of
| a single coder to implement on their own.
| guilherme-puida wrote:
| If the DOM api is not expressive enough, you end up
| having to wrap it with your own custom abstractions. At
| that point, is it not better to use a battle-proven
| abstraction?
| tgflynn wrote:
| Only if they're clearly better than the abstractions I
| would come up with. Which is rarely the case, especially
| if most of these frameworks were developed in an ad hoc
| manner without deep consideration of what the fundamental
| problems are that need solving, and even more so if they
| had to incorporate workarounds for browser issues that
| are no longer very relevant in 2022.
| wonnage wrote:
| sounds like someone has a bad case of not-invented-here
| joshstrange wrote:
| Ok, but surely you see the difference between this very
| simple/straightforward "demo app" and a real webapp?
| Something like Zillow, Facebook, Doordash, Spotify, etc. I
| looked at your code and you had to write your own render
| loop to accomplish this which would break down if you had
| interactive stuff that you were rendering out (I know, I've
| done this before). As it stands your interactions ("New
| Data", "Run", "Step", "Reset") are completely separate from
| the rendered data. Once you start combining those it gets
| harder. It's still possible but you are reinventing the
| wheel.
|
| For a small demo like this vanilla JS might make sense but
| scaling this up does not work (once your rendered HTML
| reaches a certain size it's jarring when it re-renders,
| same deal if you have interactive UI that you are rendering
| out) and if you need to make 10x of these demo sites you
| are copy/pasting a bunch of code versus leveraging a
| framework that handles that stuff for you. Yes, frameworks
| raise your "floor" of code-size but they provide an
| excellent foundation to build on and skills you can reuse
| across projects instead of them all being one-off or having
| to copy/paste a bunch of code.
| tgflynn wrote:
| > Ok, but surely you see the difference between this very
| simple/straightforward "demo app" and a real webapp?
| Something like Zillow, Facebook, Doordash, Spotify, etc.
|
| Yes and no. What are those apps really doing that's
| fundamentally so much more complicated ? Obviously
| there's a lot more to their UI's and you'd need to be
| careful about doing full re-renders. I suspect anything
| that affects global page layout could become problematic.
| But I think it should be possible to predetermine the
| page layout (unless the viewport size changes, then you'd
| need to re-render everything, but that should be
| uncommon) and only re-render within div's of preset size.
|
| > I looked at your code and you had to write your own
| render loop to accomplish this which would break down if
| you had interactive stuff that you were rendering out
|
| You mean like generating forms/controls ?
|
| I have some other code I'm working on that does that and
| also doesn't seem particularly hard. For example I'm
| working on a chrome extension with an options page that
| updates another page and the local storage as soon as a
| user changes an option setting.
| joshstrange wrote:
| > Yes and no. What are those apps really doing that's
| fundamentally so much more complicated ?
|
| They have more views, more data, more data that needs to
| be kept in sync across multiple views. You cannot
| rerender (and inject/replace) every time the underlying
| data changes. It works up to a point but once you cross
| that rubicon it because very painful. I don't know how
| better to say this or explain it. I write webapps
| professionally and for side-projects, maintaining any of
| them in vanilla js would be a non-starter. I have even
| tried that for "smaller" webapps that "don't need a build
| step", it doesn't work. SCSS is vastly superior to CSS,
| TS is superior to JS, and templates that support things
| like `v-for="item of items"` or `v-if="condition"` or
| `@click="doTheThing"` are superior to HTML templates with
| event handlers, loops spitting out html, and conditional
| rendering of blocks.
|
| > You mean like generating forms/controls ?
|
| Yes. Those things make this all more complicated. I've
| built exactly what you have in the past and at a certain
| point it falls down hard. There is a noticeable lag when
| you change data and go to re-render. If the user is
| focused on an input and you re-render they lose focus
| unless you make sure to reset the focus after the render.
| If you wanted to do something like "As the user types re-
| render an element to show what they typed" (think
| example/preview, or even something like putting the name
| you are typing into the UI as a header) it gets really
| gross really fast. So you might start having smaller
| render areas "I'll just re-render this 1 part" but that
| also gets complicated very quickly and at the end of the
| day you are just building a worse framework without the
| benefit of the community.
| gremlinsinc wrote:
| I remember trying to do this with jQuery and
| localstorage, and was amazed it work, but so frustrated
| the many times it broke or caused issues. Built an entire
| shopping cart w/ a team in jQuery and localStorage as the
| store with some handlebar templates. In retrospect it was
| horrible code. This was in 2015 though, so react/vue were
| less wide spread and I was much more junior.
|
| Now it's so much better/easier to use Vue, or react or
| even Svelte or the smaller similar stacks like alpine,
| htmx, etc that at least make state management easier than
| it ever was dealing with jQuery. the only thing jQuery
| had going for it was the ease of using selectors,
| honestly I think a jquery lite package that just has all
| the selector stuff would be nice, I sometimes forget all
| the document.getElementById stuff, but $('#id') is a much
| (imho) better syntax anyways. There probably already
| exists something like that - haven't looked but maybe I
| will later now that my interest is piqued.
| tgflynn wrote:
| > You cannot rerender (and inject/replace) every time the
| underlying data changes.
|
| OK, so how do the frameworks do it then ?
| Kiro wrote:
| This is a good start:
|
| https://reactjs.org/docs/faq-internals.html
|
| https://reactjs.org/docs/reconciliation.html
| tgflynn wrote:
| Thanks.
| joshstrange wrote:
| They do pathing/differential rendering. They don't all do
| it the same way but one example is they build the DOM "in
| memory", render it out, and then when they re-render they
| compare they old/new html and inject only the diff. They
| also have built in things to make sure you don't lose
| focus when you add an attribute to the input (or change
| it in some way).
|
| There are lighter-weight shadow dom frameworks out there
| (than Vue/React/Angular) so why would you want to write
| one yourself?
| tgflynn wrote:
| > There are lighter-weight shadow dom frameworks out
| there (than Vue/React/Angular) so why would you want to
| write one yourself?
|
| Mainly because I prefer working with my own code to
| working with other people's. Another advantage is
| reducing the amount of new information I have to learn
| (which with the whole vanilla HTML5 stack is already
| vast), but maybe I'm hopelessly out of date.
|
| Thanks for the insights though, I wasn't aware they were
| doing all of that.
| gremlinsinc wrote:
| > Mainly because I prefer working with my own code to
| working with other people's. Another advantage is
| reducing the amount of new information I have to learn
| (which with the whole vanilla HTML5 stack is already
| vast), but maybe I'm hopelessly out of date.
|
| The problem here is - if you need to bring in other
| developers. Finding react/vue devs, or devs w/ htmx,
| alpinejs, etc - it's going to be super easy to onboard, a
| custom framework you built yourself - not so much. Maybe
| it's easy, maybe it isn't but you will have to train new
| devs who work on your stuff, where otherwise you could
| save time/money by not having to train on things, plus is
| your framework well tested using jest or other testing
| frameworks? There could be lots of bugs that some of the
| bigger more established frameworks have already worked
| out, and especially security issues.
|
| Right now my favorite stack is laravel + alpinejs +
| livewire + filamentphp (admin dashboard) -- i can
| prottype in a week what used to take 3 months.
| nuancebydefault wrote:
| > I prefer working with my own code... Every programmer
| prefers to work with their own code. This is the biggest
| dilemma, it boils down to a lot of "make/buy" decisions.
| Rule of thumb after 20+ years of experience : do not
| reinvent frameworks. The framework you are thinking of
| already exists, and, even when not perfect, solves a lot
| of problems you hadn't even thought of.
| naasking wrote:
| > There are lighter-weight shadow dom frameworks out
| there (than Vue/React/Angular) so why would you want to
| write one yourself?
|
| You can even avoid a shadow DOM or vDOM entirely and
| differentially render using the DOM itself:
|
| https://github.com/WebReflection/domdiff
|
| https://github.com/WebReflection/uhtml
|
| The JS framework benchmark shows these two are among the
| top performers.
| posterboy wrote:
| > items"` or `v-if="condition"` or `@click="doTheThing"`
| are superior to HTML templates
|
| The html syntax as a matter of taste is horrible, but
| that doesn't need a whole turing complete language to fix
| matt_s wrote:
| I suspect some of the JS frameworks started with a set of
| JS functions, etc. to do things dynamically on a page.
| And it grew. And then someone comes by and says "hey
| we're building a new app, mind if we use that?". And it
| was cloned and morphed. And it grew. Maybe that repeated
| a bit, and then someone created a framework of generic
| tools.
|
| Then this happened in multiple places. Or hackers didn't
| like how something worked so they came up with their own
| spin. I believe React came out of or is strongly
| influenced by FB, which makes sense - a Single Page App
| is the design and progressively loading more ads, ahh I
| mean content.
|
| And here we are building client/server apps with a
| technology invented for document sharing.
|
| There are 2 frameworks solving the "keep track of state"
| problem on the server and allowing for dynamic/reactive
| UI via web sockets instead of XHR: Ruby/Rails 7 and
| Elixir/Phoenix LiveView. They still use JS but you can
| limit it to client-side things and maintain state and
| validations on server.
| posterboy wrote:
| This is hilarious. Those web apps are single page
| applications, more application than page. The most of
| what face book does in the background has nothing to do
| with what the user can see, for example. A chat might
| require interactivity, but static designs with push and
| pull work well enough for many use cases, with sparse
| scripting. The bespoke tutorials might rather target a
| geocities homepage, admittedly.
|
| It's funny to see how responses in this thread jump
| immediately to reactivity or "skills you can reuse across
| projects" but without making the case: why?
| solardev wrote:
| Why what?
|
| Facebook is pretty complicated already, once you factor
| in: * infinite scroll
|
| * different sorting algorithms (top vs new, do they even
| still have that?)
|
| * real-time commenting and post updates, with responses,
| reactions, edits, deletions
|
| * dynamic image uploads, resizes, rotations, captions,
| etc.
|
| * auth
|
| * multi-device sync
|
| * real-time customizable notifications
|
| * real-time sharing
|
| And then it gets even more complicated when you throw in
| other features like:
|
| * ad management, posting, analytics, event tracking
|
| * chat
|
| * marketplace
|
| * page management and all the permissions and delegations
| that involves
|
| There's nothing really "static" about Facebook. And even
| it was designed as a mix of PHP and clientside JS,
| probably due to its history... if they started from
| scratch today, who knows what architecture they'd use,
| but probably not vanilla JS and HTML...
|
| I think the "why" should be aimed more at vanilla, as in
| "why would you want to reinvent the wheel when there are
| so many battle-tested solutions to choose from, each made
| by a team hundreds of times more resourced than you"
| gremlinsinc wrote:
| wow thanks for this, I'm fullstack with tons of vue exp but
| have been 90% backend for the past 6 months or had my head in
| a hole or something -- this is the first i've heard of
| petite-vue. Looks pretty cool, maybe somewhat akin to
| alpinejs, which I have been using more lately also. I'd also
| put that on the list as it's a nice framework with a bit less
| footprint than vue/react etc.
| BenoitEssiambre wrote:
| On top of these options, with modern browsers, it's quite
| easy to make reactive components in plain vanilla (
| https://benoitessiambre.com/vanilla.html ). I find this
| approach very usable for smaller simpler projects where you
| don't need a full framework.
| athrowaway3z wrote:
| I'll throw in https://caldom.org/
| nisegami wrote:
| Working on a project right now with htmx, hyperscript,
| tailwindcss (all new to me) and it's impressive how low the
| cognitive load is in a lot of cases.
| gremlinsinc wrote:
| htmx and tailwindcss are great but hyperscript looks crazy
| evil. I hate mixing html and js though, even jsx rubs me
| wrong.
|
| This looks like pug/slim and other templating to remove xml
| from pages but instead of just something like
| body p | This is a test
| of the text block.
|
| you get something like: var h =
| require('hyperscript') h('p', "This is a test of
| the text block")
|
| and I want to know why would you want the entire page in JS
| objects?
|
| personally I like the way htmx, vue, alpinejs do things
| with basically embedding actions/events on the existing xml
| structures. It's more an abstraction over existing html,
| than totally redoing or replacing html. That seems like a
| case of 'we knew we could do it, but never stopped to ask
| ourselves if we should' ...
|
| Turbolinks + stimulusjs is also another great stack for
| mini-frontend frameworks. Also super fast.. turbolinks can
| go well w/ anything though including htmx or alpinejs, but
| there's a lot of tutorials on stimulus+turbolinks.
| soulofmischief wrote:
| If you like hyperscript, it's worth checking out mithril.
|
| https://mithril.js.org
| gzer0 wrote:
| What about adamant? I heard that is the next level above
| mithril.
| Legion wrote:
| This sequence of comments is the JS ecosystem in a
| nutshell.
|
| Hear about something new, then immediately hear about its
| multiple successors/replacements.
| testplzignore wrote:
| Nah. orichalcum.js is the hot new thing. It's a fork of
| adamant with support for monads, generics, and native
| blockchain integration.
| charrondev wrote:
| For anyone wondering what are these new JS frameworks:
|
| - mithril.js is an actual web framework. I've not tried
| it myself. - the next comment referenced adamant as being
| better. There is an MMORPG called RuneScape in which
| weapons and armour can be smithed of various metals, and
| treats adamant as 1 tier better than mithril. - similarly
| orichalcum is a couple of tiers above mithril.
| dbxkcichhdfufu wrote:
| Browsers already managed state just fine. We just didn't like
| the way it looked.
| have_faith wrote:
| Browsers do nothing to help us manage state outside of
| individual elements.
| hellcow wrote:
| That's actually all I use for state management. Elements
| pass data to children through attributes and bubble data up
| through events. It's worked well for us on a complex front-
| end using native web components.
| have_faith wrote:
| This is called prop drilling. It technically works for
| any size or complexity of app if you're willing to make
| every intermediate component have knowledge about every
| possible piece of state that might be wanted by a
| component lower in the tree. It's extremely cumbersome
| though.
| P5fRxh5kUvp2th wrote:
| Back in my day we could search for child elements with
| specific attributes without needing the intermediate
| elements to know anything about it.
|
| What REALLY happened is the shadow DOM. People decided it
| was too slow and created an intermediate representation.
| That then created all kinds of OTHER problems that
| started resulting in solutions that wouldn't have been
| necessary without the shadow DOM.
|
| A shadow DOM is basically a cache, with all the problems
| that entails.
| dalmo3 wrote:
| > Note that the shadow DOM is not a new thing by any
| means -- browsers have used it for a long time to
| encapsulate the inner structure of an element.
|
| https://developer.mozilla.org/en-
| US/docs/Web/Web_Components/...
| bornfreddy wrote:
| That's basically a home-made React (& co.) duplicate
| (which is great). This simplifies development
| considerably, because you break the original problem into
| a) updating the state and b) translating the state into
| UI elements, and the framework (hopefully) automatically
| updates UI as needed.
| ozim wrote:
| Which state are you referring to? I feel parent poster is
| talking about different state than what you have in mind.
| tgflynn wrote:
| > The key reason web frameworks dominate these days is that
| it's very hard to keep the UI in sync with state.
|
| That's a very interesting comment, but it is rather abstract. I
| think it would be very helpful if you (or someone else) could
| provide a simple example that illustrates the problem.
| samwillis wrote:
| > keep the UI in sync with state
|
| This is absolutely true, however there are some newer tools
| that are appearing that make this much easer with vanilla html
| - htmx, hyperscript, alpine.js for example (links below).
|
| These newer tools are all made possible due to the "new"(ish)
| MutationObserver api, it allows you to intercept new dom
| elements being placed into the document. These libraries let
| you simple decorate your "real" html with extra attributes
| enabling easer client side state management. No build step
| required.
|
| My hope is that a combination of these type of tools, js
| modules and web components will result in dropping all js build
| tools. With http2/3 we don't really need bundling. In many ways
| it the bundling and transpiling process that has contributed
| the most to the friction with JS development.
|
| My other observation would be that as js frameworks have
| evolved they have become more "enterprise" ready, adding
| tooling (complex central state management, strict typing) to
| make working in large teams on very large codebases easer. Much
| of this isn't really necessary for the majority of we
| development.
|
| https://htmx.org/
|
| https://hyperscript.org/
|
| https://alpinejs.dev/
| shafyy wrote:
| To that list I'd add Hotwire (especially Stimulus:
| https://stimulus.hotwired.dev). I use with Rails, but it's
| framework/backend agnostic.
| xmonkee wrote:
| It's crazy that we posted almost the exact same thing at the
| same time: https://news.ycombinator.com/item?id=32781674
| potatoz2 wrote:
| I hope these succeed, but we still need
| transpilation/bundling:
|
| - TypeScript needs transpilation and it's very popular
|
| - Bundling is still beneficial with H2/H3, if only so that
| compression can work well
| symlinkk wrote:
| But if you're going to use a framework like HTMX and the
| others you mentioned, why not just use React? Vanilla JS is
| great because it's universally available, if you're choosing
| to drop that advantage I would just go with React.
| Existenceblinks wrote:
| because `react-dom` is bloat [minified]
|
| - hyperscript@2.0.2 [3.7 kB]
|
| - htmx.org@1.8.0 [36.5 kB]
|
| - alpinejs@3.10.3 [38.1 kB]
|
| - react-dom@18.2.0 [130.5 kB]
|
| Right now my whole (everything js) _really complex_
| application is 150 kB minified. Imagine adding React ..
| urghh unreasonable.
| vi2837 wrote:
| Just try Preact
| yCombLinks wrote:
| With react you need a build / transpile stage and have to
| handle webpack / babel / whatever. You can just use plain
| tags in html to use htmx and alpine, you just have to
| include them
| alwillis wrote:
| Thanks for these links! They look like the next logical step
| for HTML/CSS developers instead of React (or similar) which
| are overkill.
| tantaman wrote:
| Hits the nail on the head.
|
| Client side frameworks are still missing it, however, when it
| comes to: 1. Supporting persistent client side state 2. Syncing
| local state to the server and back 3. Variation of (2) but
| collaborative state
|
| Aside -- Reactivity could be straightforward in vanilla js with
| some tweaks to event handling and in-browser support for dom
| diffing. I made this reactive vanilla js todomvc in ~200 sloc
| to explore the idea: https://tantaman.com/2021-02-12-Todo-
| MVC.html
| gremlinsinc wrote:
| okay, sure you did it.. congrats... but I could do in much
| less work/lines of code the same:
|
| see: https://jsfiddle.net/patrickcurl/zoastuLr/11/
|
| html: 104 lines css: 39 lines js: 62 lines.
|
| The major difference is I can easily 'read' and understand
| and 'grok' what my code is doing, yours needs more brain
| power to tie everything together. The majority is layout,
| css, etc.
|
| Sure vue/react are overkill but alpinejs, etc makes closer to
| vanilla options viable that still at least have some eye-
| candy/syntactical-sugar that makes coding sweeter. But, I
| hate ugly code - I'll abstract away ugly code just to have
| code that's self-documenting and easy to understand.
| daveslash wrote:
| Re >> _From someone who has used React professionally but uses
| vanilla HTML /CSS/JS for his personal website_"
|
| What a refreshing perspective. My personal site is also vanilla
| HTML/CSS/JS on a self hosted server. I constantly catch flak
| from all of my software engineering friends for it too, and I'm
| a little burned out on it.
|
| Edit: I'm a bit burned out on the flak and defending my
| position; not burned out on the approach :-)
| jraph wrote:
| Please don't burn out for this. Vanilla HTML/CSS/JS is just a
| very right way of building a website. I don't know how we
| ended up having to even debate about this.
|
| Don't worry, just enjoy the simplicity, the zen and the
| lightness of this.
|
| (from a professional web developer, if it even matters - but
| the web, especially JS, was not targeted at professional web
| developers, which is the reason why JS is so "forgiving" - or
| was intended as such, but that failed miserably if you ask
| me)
| daveslash wrote:
| I've updated my comment to reflect that I'm burned out on
| catching the flak, but not the work itself. Personally, I
| _love_ basking in the zen of the simplicity! I used to be a
| professional web developer in a former life, but these days
| I 'm more medical-device and embedded focused. I moved out
| of the web space around the time that AngularJS was
| becoming the hot-new-thing, for better or worse.
| rodolphoarruda wrote:
| Yes. Some things should be designed as simple as possible
| so they can last.
|
| https://jeffhuang.com/designed_to_last
| DanAtC wrote:
| A good engineer knows which tools are right for the job.
| lolinder wrote:
| For a web _site_ the vanilla tools are exactly right--it 's
| what they were designed for and they still do a really good
| job at it.
|
| The frameworks are only really worth their weight if you have
| a web _app_. I 'd only consider a web framework if there's
| going to be >2x as much JS as markup.
| kaeruct wrote:
| Those are some strange friends. Who cares what you use on
| your own website?
| anotheracctfo wrote:
| I'm amazed at how many developers need ridiculous complexity
| to feel like they've accomplished something. I feel that too
| many people are focused on building resume keywords than
| solving problems.
|
| If you can solve it in 20 lines of CSS / JS then do it.
| oxff wrote:
| You don't get hired for, say, a role that requires Svelte /
| React expertise by pointing out "I did it in vanilla JS!" -
| so you are correct, industry sets the rules and your CV if
| you want a job from them, needs to reflect this.
|
| There are also software engineering (not programming)
| reasons, mostly because they set standards for stuff like
| state management, for why they're useful - helps with
| future maintenance, documentation etc. when you don't have
| to interpret a custom self-made framework and teach it to
| hires.
| dieselgate wrote:
| Yep my thoughts as well. It's great to use vanilla js for
| a personal website (I do) but if one is seeking
| employment knowing a popular framework (both backend and
| front end) is also critical.
|
| It also seems worthwhile from an Org standpoint because
| then they can target "react" or "vue" developers in job
| postings who can presumably hit the ground running
| productivity wise.
|
| (This is basically just echoing everything parent comment
| was saying)
| Existenceblinks wrote:
| Poll
|
| - Job market sucks
|
| - Industry sucks
|
| - JS framework sucks
|
| - Developer sucks
| jcpst wrote:
| I remember reading a similar HN thread in the past where
| someone didn't understand how you build a html form without
| React, and that it seemed wild that someone would consider
| it.
|
| Framework, no framework, whatever works. I'm a fan of your
| approach. But it's interesting to see how abstractions like
| react have created a class of web developers that may not
| know their HTML / DOM fundamentals.
| codyb wrote:
| Wow, what an interesting response. If someone told me they
| were trying different approaches to similar problems on their
| own time I'd say "Sounds like you'll probably learn something
| someone using the same approaches or not solving the problems
| on their own time wouldn't".
|
| Those engineers sound like the kind I don't like to work
| with. Giving you gaff for wanting to tinker on your own time
| is downright haughty.
| francisofascii wrote:
| Yep, and honestly this is why people don't see as many
| vanilla sites. Fear of flak, or being labeled a cowboy from
| the pro-framework, declarative is better, crowd.
| karaterobot wrote:
| I got burned out by all the frameworks. It's one of the main
| reasons I left web development. I love the web, and I still
| do personal web projects, even though I don't do them for
| work anymore. I just exclusively use vanilla JS, and make
| sure the scope doesn't get big enough that I need to
| construct a giant mech suit of frameworks and libraries and
| climb into it every time I want to make an app!
| yuan43 wrote:
| Redux is a simple, framework-free pattern for achieving this
| synchronization. You can use a library that implements, but the
| pattern is simple enough that you can (and probably should)
| implement it yourself.
|
| https://egghead.io/courses/fundamentals-of-redux-course-from...
| seydor wrote:
| A bunch of people started overcomplicating things in order to
| impress their peers so they will hire them to BigShinyCorp Inc.
| Things went on for 15 years and ended up with an abomination in
| which everything has 53 levels of virtual machines behind it.
| Because i guess virtual machiens are fun.
|
| Yes they are perfectly fine, dont waste your time
| IYasha wrote:
| Yeah, things got messy, laggy and sad. Because there are no
| longer "sites" - there are "apps". Because why spend money on
| expensive servers while we can run JS garbage on client side?
| Because why our corp has this boring page? We need something more
| splashy-flashy than our rivals have! Because why keep old bugged
| codebase? Let's write a framework! Because can I haz animated
| website with no skillz? I heard I only need a few clicks with
| some "frameworks"...
| gabrielsroka wrote:
| > I don't understand what problem they're trying to solve
|
| I don't use React. I learned a little bit of Vue. I'm definitely
| not an expert, but I think there are (at least) two problems that
| they solve: consistency and reusability.
|
| Consistency: I think the hope is that if you're a React
| programmer and you see a brand new site written in React, you'll
| understand it, whereas if it used vanilla JS, it might be written
| in any number of ways.
|
| Reusability: if you start writing your own reusable functions in
| vanilla, you'll eventually build your own React -- it's the build
| vs. buy decision.
| solumos wrote:
| Vanilla html/css/js are great for static sites, but once you
| start building an application it gets more difficult to manage
| state: both on the page, and with the backend that stores user
| data.
|
| What you're saying is similar to saying "I don't understand why
| someone would use Django, can't I just use the python http.server
| for an API and psycopg to connect to postgres?"
|
| The answer is yes, you can do that, but over time you'll find
| that there are pitfalls with a bare-bones approach that are
| easily avoided by using higher-level frameworks. Mostly the
| spaghetti that someone else mentioned, but also getting caught up
| in technical details that the frameworks have mostly already
| abstracted away.
| neon_electro wrote:
| The trouble is that even with _good_ definitions for "web
| site" and "web app" (the distinction clearly matters, right?),
| non-developers always want their web sites to be more
| interactive, to the point that using React somewhere you
| shouldn't feels like the "easiest" choice.
|
| I hate this.
| telman17 wrote:
| When you went through the Odin Project, did you do all the
| modules? Asking because there's a huge chapter on React that the
| vanilla JS course helps prepare you for. (To answer your question
| though - HTML, CSS, and JS are absolutely valid ways to go on a
| simple website that doesn't require a lot of interactivity. You
| use the tools you have in situations that benefit from them)
| [deleted]
| dageshi wrote:
| They're the assembler of web dev, especially css. People move to
| the equivalent of higher level languages to escape the tedium of
| dealing with them.
| lofaszvanitt wrote:
| The tedium? The tedium is with React et al.
| dageshi wrote:
| I frankly think all front end is tedious to be honest. It
| doesn't matter what you use, it's fundamentally annoying to
| build in my opinion.
| IceDane wrote:
| Spoken like someone who has never built a non-trivial web
| application using vanilla JS or jQuery.
| kgwxd wrote:
| Every time I've started a new vanilla project, it's not long
| before I figure out I need a lot of stuff that's already been
| done better in a framework. It's usually about the time I start
| writing a helper function to build up dynamic DOM elements.
| jeanmayer wrote:
| This. Also, these frameworks increase our productivity
| significantly
| throwaway0asd wrote:
| Frameworks solve for architecture.
|
| When a choice is made to use a framework the choice declares the
| stakeholder(s) trust the framework to provide a better
| architecture than the assigned developers. How prolific a given
| group of frameworks become understates how little faith the
| decision makers have in developers to write an acceptable
| solution.
| manv1 wrote:
| The fundamental problem is that HTML is technically stateless but
| a web app is not.
|
| So to do anything that needs state (think google maps, or a
| responsive website) you need to either build or buy a way to
| manage that state, while working inside the confines of
| HTML/HTTP.
|
| In many ways you can look at react, vue, etc as javascript
| applications that use HTML/DOM to render. The problem is that
| they don't really see themselves like that, so the way they
| present stuff is sort of fucked up. And even after all these
| years the DOM handling stuff hasn't adjusted to the reality of
| web 2.0...because presumably the devs want to keep backward
| compatibility with hand-written css/html/js.
|
| The DOM is another one of those hacky things that survived and
| thrived.
|
| If browser makers, the standards people, framework makers, and
| web devs got together, they could theoretically simplify a lot of
| this shit going forwards, but they don't because it's too hard.
| Instead, we have these sort of layers of bullshit that live
| forever.
| sebringj wrote:
| Some of the better ones do most of the thinking for you in a
| clever and minimal way and seem to reset the status quo of giant
| dependency trees that take a long time to install and update and
| deploy (relatively to your scenario). deno fresh for example is a
| reset coupled with deno deploy. Its better to not have to worry
| about manually updating the dom and think of updating state
| instead just like updating a variable ideally. As long as it gets
| out of your way and speeds up results, it is a win IMO. It gets
| even better when its a super fast deployment baked in. Not fun to
| FTP as I remember long time back. FYI coming from simple user-
| land and I do think things are getting better when those resets
| happen, not worse.
| LEDThereBeLight wrote:
| The web was originally created to share documents, so
| interactivity and extra functionality was an afterthought. As the
| web became more popular, websites started to add more
| functionality similar to traditional software programs.
|
| Eventually, the original guideline of HTML for structure, CSS for
| styling, and JavaScript for interactivity started to not really
| make sense anymore for many websites, because as pages became
| more interactive, the lines became blurred. If you look at a site
| like GMail, where does the page structure end and interactivity
| begin?
|
| With large parts of a page being interactive, it becomes
| difficult to manage all the state involved, especially if it's a
| "live" page that updates in real time and may have several people
| viewing it.
|
| Frameworks were introduced as a way to manage state and allow
| websites to re-render efficiently without hard page refreshes.
| twic wrote:
| > Eventually, the original guideline of HTML for structure, CSS
| for styling, and JavaScript for interactivity started to not
| really make sense anymore for _many_ websites
|
| My emphasis added.
|
| There are still absolutely tons of sites for which the
| classical model works fine, and indeed works better than React
| at al, because pages load faster and behave more normally.
|
| Some of those sites are now built with React et al anyway, for
| some bad reason (cargo culting, resume-driven development,
| etc). But still, most are not, i suspect. Classical web
| development is still a very useful skill.
|
| However, i suspect that although a majority of web sites don't
| involve React et al, a majority of web development jobs do -
| because the fraction of sites that are complex enough to need
| React et al also need a lot more developers!
|
| (a fact i think is fun: a majority of stars are in binary or
| multiple star systems, even though such systems are a minority
| of star systems)
| at_a_remove wrote:
| I think you've got the building blocks, but to really capture
| the "sometimes evolution is stupid" feel, you have to mention
| stuff like Javascript was created in ten days under some stupid
| deadline, with a stupid insistence that it have "Java" in the
| title. Or CSS being -- if not orthogonal to, at least wildly
| unparallel with -- against the grain of basic design principles
| like Contrast, Repetition, Alignment, and Proximity, then that
| awkwardness causing generations of table-based alignment
| solutions. And demands unforeseen, like piping video over HTTP.
| Take a step back for a second and think about that: we've got
| all of this _stuff_ layered atop what was originally just a
| handful of specs on how to push barebones scientific papers
| around. Let 's give a nod to Ports 80 and 443 uber alles,
| because of convenience, for video. And then the reaction --
| well, how do we throttle this properly? We'll have to _inspect_
| , when before we just throttled the video ports for whatever
| video protocol we were working with.
|
| It's a history of one decision after another, made hastily,
| often in anger, and it's how we got ... here.
| IYasha wrote:
| > If you look at a site like GMail,
|
| Ouch! As a google mail theft victim, "right in the heart" :(
|
| > efficiently without hard page refreshes.
|
| And completely destroying the "Back-forward-refresh"
| functionality.
| skadamat wrote:
| IMO this is the best answer. A clear, history-contextualized
| summary of the reasons why vanilla is often not enough for some
| use cases.
| krapp wrote:
| For some use cases, sure.
|
| But most sites aren't GMail. Frameworks and typescript should
| still be the exception, and the rule should still be
| independent, modular libraries like JQuery.
| kitsunesoba wrote:
| As someone who's become most comfortable with strictly
| typed languages (primarily Swift and Kotlin), I find that
| TypeScript makes my dabbling in web dev much more tolerable
| and even somewhat enjoyable, even for simple projects with
| zero dependencies. Plain JS becomes frustrating quickly as
| project complexity ramps.
| joshmanders wrote:
| > But most sites aren't GMail. Frameworks and typescript
| should still be the exception, and the rule should still be
| independent, modular libraries like JQuery.
|
| People always say this but it's so hollow. Most sites
| aren't Gmail, but we're not building most sites. We're
| building applications that work in similar fashion to
| Gmail, thus need similar stuff like all these frameworks
| provide.
|
| "Oh but everyone's using React to build their blogs instead
| of writing new posts for them and that's overkill"
|
| Let me stop you before we get to this point. People use
| their personal blogs as a way to test new concepts they
| want to learn, so of course it's gonna be over engineered
| to hell.
| neon_electro wrote:
| So what about when product management starts demanding
| even more interactivity on a marketing site built without
| React?
|
| I pushed back hard on introducing React when the site
| already had jQuery. Another developer said they could do
| what was needed with React.
|
| The marketing site started shipping _both_ jQuery and
| React.
|
| I hate the JavaScript/React ecosystem so damn much for
| its complexity.
| joshmanders wrote:
| You hate a valuable ecosystem because your company
| product managers listened to someone else?
|
| I hope you find a new job. That's like saying you hate
| bananas because someone asked for a pie and you said
| you'd make an apple pie and they said they'd make a
| banana pie and they decided to choose the banana pie
| instead of your apple pie.
| neon_electro wrote:
| I hate the complexity of the ecosystem. The benefits that
| make it valuable are obvious to us all. You _do_
| understand the downsides of shipping both jQuery and
| React on the same site, right?
| klibertp wrote:
| You're being uncharitable for no good reason. If you're
| not sure if your interpretation of what GP said is true,
| ask for clarification and stop at that. Your first
| paragraph is ok, the second was uncalled for.
| joshmanders wrote:
| Uncalled for? I was explaining in a metaphor how I
| interpreted OP's reason for not liking React/JavaScript.
|
| I don't like PHP/Laravel ecosystem because I recommended
| we use vanilla PHP and my co-worker recommended we use
| Laravel and my manager decided to use Laravel.
|
| I don't like Python/Django ecosystem because I
| recommended we use vanilla Python and my co-worker
| recommended we use Django and my manager decided to use
| Django.
|
| Swap it with literally any framework in any language vs
| using vanilla-<lang here>. It all sounds just as
| ridiculous.
| [deleted]
| alpaca128 wrote:
| > typescript should still be the exception
|
| And JS shouldn't be exceptionally bad but here we are, and
| people use TypeScript as alternative to stay sane.
|
| I agree that modern web development comes with far too much
| complexity on average, but people started adopting those
| frameworks for a reason. The web is kept backwards
| compatible with obsolete standards which have been created
| in a different time for different purposes, and at some
| point it becomes easier to build abstractions over that.
| For example TailwindCSS adds another "compilation" step and
| configuration file but in return makes styling much more
| tolerable than standard CSS. Is it necessary? No, but when
| you build a large website all those little things add up.
| shadowgovt wrote:
| Agree here. TypeScript is a bit of a Godsend even when
| using the vanilla DOM API because (a) the DOM API uses so
| many different abstraction patterns that it's easy to
| lose track of which one you're using (and passing the
| wrong arguments with no static typechecking is a runtime
| error) and (b) JavaScript itself has so much wat
| (https://www.destroyallsoftware.com/talks/wat) in its
| implicit value coercions that it's invaluable to have
| types narrowly-scoped in code so you have any hope of
| predicting what the output of operations will be.
| potatoz2 wrote:
| I don't think JS is much worse than other dynamically
| typed languages to be honest. In Ruby you'd get an
| exception instead, which is mildly better than `NaN` in
| your user-visible text, but not much.
|
| The DOM though is definitely complex and built of
| accretion over time. The Web resists refactoring because
| we can't break websites from the 90s.
| shadowgovt wrote:
| > I don't think JS is much worse than other dynamically
| typed languages to be honest.
|
| I agree; it's a plague all dynamically-typed languages
| face. I've yet to meet one that doesn't hit me with some
| kind of powerful pain-in-the-ass corner cases as a trade-
| off for the power of its terseness.
|
| I fell in and out of love with Python over the course of
| a decade or so. Initially very excited about doing so
| much with so little code; fell out of love when I used it
| in an industry setting and realized 100% unit test
| coverage was mandatory because the lack of variable
| declaration means every line of code is a potential
| runtime error in waiting due to a simple name typo.
| smm11 wrote:
| Lots of hammers, when few actually need one.
| oneplane wrote:
| It's because you can't scale up without modularisation and
| component re-use. This applies to pretty much anything. You can
| find this 'problem' in other languages, markup methods etc. all
| the same, for the same reasons.
| silent_cal wrote:
| Okay, but can't you do that with HTML/CSS/JS? You can save
| collections of JavaScript functions, CSS class definitions, and
| HTML templates pretty easily. Re-using them is just a matter of
| copying them over to a new directory.
| robertoandred wrote:
| And what happens when you want to modify one of those html
| templates?
| [deleted]
| MH15 wrote:
| How do you keep said copied JavaScript functions, CSS class
| definitions, and HTML templates in sync?
| joshstrange wrote:
| > Re-using them is just a matter of copying them over to a
| new directory.
|
| And you lost me.
|
| Is it possible to write reusable JS/CSS/HTML? Yes but the
| overhead is very frustrating and you will quickly find
| yourself building a custom framework to manage everything.
| Best to start with a framework from the start if you plan on
| having rich interactions. The speed at which I can move in
| VueJS is nothing short of amazing and the amount of reuse I
| get is extremely high, all without me having to manually
| manage a bunch of files/includes. With 1 TS import I can get
| all the HTML/CSS/JS for a component and safely use it in
| another component. At a minimum that would take 3 http calls
| in "vanillaJS" to fetch the html/css/js that I would need to
| maintain and update myself. SFC's are a game changer. Sure
| the browser might eventually support what I need but by that
| point I have no doubt that VueJS (or similar) will have lept
| further ahead.
|
| It's the same reason I jumped on the 6to5/babel train early,
| it let me write my code in ES6 but still deploy to older
| browsers without waiting on everyone to upgrade.
| silent_cal wrote:
| Okay, so if I understand the main benefit is that you get
| to use a package manager and import statements? Also, don't
| you still need to manage tons of files, directories and
| config files in a React project? The React websites I've
| seen have way more complex directory structures than your
| average HTML/CSS/JS site.
| joshstrange wrote:
| I understand that at the start a pure HTmL/CSS/JS site
| appears easier (and to a large degree it is) but as soon
| as your project grows to a certain complexity the
| frameworks make life a million times easier. Also, once
| you've seen what the frameworks can do (handling the
| annoying stuff for you) it's hard to go back even for
| simpler sites. Especially since we rarely know if a
| "simple site" is going to grow and need more
| functionality in the future at which point it would make
| sense to switch to a framework. Why not just start with
| the framework?
|
| I've tried to go back to plain html/css/JS before and
| it's a huge pain. I'm constantly thinking "ugh, this
| would be 2-3 lines of code in Vue but instead I have to
| manage all this stuff myself and it's going to take 10's
| of lines if not more. I'm not a fan of reinventing the
| wheel, also my skill set can be used everywhere if I
| write all my stuff in Vue instead of needing to context
| switch between smaller and larger projects (and again,
| small projects almost always grow so why not set them up
| for success?).
| julianlam wrote:
| You certainly can, and we did, with NodeBB. We use plain
| html, css, and js (with jquery) and a couple of bespoke
| components that work for our needs (templating engine, i18n,
| utils methods, etc.)
|
| We call out to libraries when doing things that are better
| handled via a library.
|
| Guess what, when you use a bespoke solution for common tasks,
| you end up with something that blows past every other
| competitor's benchmarks, without even trying.
|
| e.g. take a look at Benchpress, our templating engine:
| https://github.com/benchpressjs/benchpressjs/
| oneplane wrote:
| You could, but you'd be reinventing the wheel. You might
| start with some snippets you copy around, and every now and
| then you have to go back to all your previous projects to fix
| some change required in new browsers. So you might start
| using version numbers on your snippets you can figure out
| what you used when. But then you figure some HTML and CSS go
| really well together, so you try to put those snippets
| alongside each other and bundle them up. Your JavaScript
| probably needs to know which one of those HTML and CSS
| snippet bundles you are using, so you'll want to make sure
| that you specify which one you are using in your JavaScript.
|
| At this point you're building a crappy version of a module
| and package manager, but all by yourself, nobody else is
| using your stuff, and you can't use their stuff either
| because it's not in your bespoke format.
|
| All of the examples and concepts here are just inter-project
| related, but this applies within a project all the same.
| [deleted]
| bullen wrote:
| I built my multiplayer web client with vanilla:
| http://fuse.rupy.se
|
| There is nothing like being on the lowest common denominator, but
| you can understand why browsers are not evolving past this point.
| fabfabfab wrote:
| Grug develop doctor's appointment website, grug use jQuery +
| Flask/Django.
|
| Grug try develop Notion or Google Sheets competitor, grug use
| React/Vue framework.
| shadowgovt wrote:
| It's easy, I think, to forget how _bad_ the basic HTML / CSS /
| JS behavior is from a modern aesthetics standpoint.
|
| So I'm currently maintaining a totally static blog I build in
| Hugo. It's almost nothing but plaintext, one static CSS file, and
| some images. One time in a hundred, when I select a new story,
| the lightly-shaded background of the page blanks through white
| because loading a couple resources takes too long.
|
| For my personal blog, for fun? That's fine. For _most_ corporate
| sites? Unacceptable. Looks unprofessional. This is 2022; we 're
| not using teletypes and command-lines anymore where the user can
| feel the individual bytes coming over the wire.
|
| So to prevent just that one visual hiccup, I'd need to do dynamic
| fetching of page content and a hollow-and-replace of the content
| div instead of reloading the entire page when the user navigates
| around, but I _also_ need to support direct navigation to the
| page loading the full page content, _and_ I need to do this all
| correctly from Google et. al 's point of view so search crawling
| doesn't break. And at that point? I'm definitely using a
| framework (probably with both client and server-side components).
| All because the aesthetic of the end-user has evolved and your
| page looks unprofessional if it navigates like a traditional
| '90s-era page.
| redeeman wrote:
| > For most corporate sites? Unacceptable.
|
| im not nessecarily disputing this, but if so, they clearly are
| stupid, given all the crap they will put up with
| shadowgovt wrote:
| You're underestimating how much money corporations have to
| throw at problems, as well as the fact that they compete on
| look-and-feel with other corporations willing to do the same.
|
| At their scale, the cost is worth it; it's just business.
| redeeman wrote:
| and yet they tolerate total pieces of garbage that loads a
| gazillion scripts taking an eternity
| umvi wrote:
| > It's almost nothing but plaintext, one static CSS file, and
| some images. One time in a hundred, when I select a new story,
| the lightly-shaded background of the page blanks through white
| because loading a couple resources takes too long.
|
| That doesn't sound right to me. Why isn't the "one static CSS
| file" cached? It should load instantly because it's already in
| your browser and doesn't need to fetch anything. I've
| created/maintained static sites as well and I've never run into
| this visual hiccup you are describing.
| petilon wrote:
| > What makes the trade-off of all that extra complexity and
| abstraction worth it?
|
| For most applications the extra complexity is not worth it. React
| started off as a simple library but now it has bloated with Redux
| and ReactRouter and Hooks and all that nonsense.
|
| You can do plain HTML/CSS/JS development for most projects.
| Here's an example: https://github.com/wisercoder/eureka It uses a
| couple of 500-line libs, that's it. No complicated framework, and
| yet you will be more productive.
| altilunium wrote:
| Most of my side projects are written in plain HTML/CSS/JS. Of
| course, it's deemed "not acceptable" by current industry
| standards. But i work for myself, so i dont care.
|
| https://github.com/altilunium/
| ozim wrote:
| Not acceptable if you would have 4-8 people working on it -
| where any of these people stay with company around 2-4 years on
| average.
|
| Not acceptable if each person working for 2 years builds his
| own abstractions that new hires have to learn - but you make it
| easier by using framework and hiring devs for that framework.
|
| Not acceptable if you would have 20 of such teams and you would
| have to have UI/UX standardized.
| silent_cal wrote:
| Very cool, thank you for sharing
| novoreorx wrote:
| I always love vanilla HTML/CSS/JavaScript, here's a site I made
| recently, using Vite as the development tool, and SCSS as the
| preprocessor, no JavaScript involved. https://cht-
| colors.pages.dev/
| romellem wrote:
| For small sites, I always reach for vanilla rather than a
| framework. For example, [a super simple QR Code website][1] I
| made uses less than 100 lines of JS (minus the QR code library of
| course :)), plus regular HTML and CSS.
|
| Anything larger, however, and using a library just makes things
| easier: HTML partials and helpers, nesting in Sass, and data flow
| and component composition in JS frameworks are just easier when a
| project is large enough.
|
| [1]: https://github.com/romellem/easyqr-codes
| paxys wrote:
| Every non-trivial web application that starts of writing
| "vanilla" code will eventually evolve into something resembling
| React, Angular, Vue or whatever else, just with a lot less
| thought and resourcing put into it. So unless you truly want to
| build a mostly static web page with HTML content and minor
| styling it makes sense to just start off with one of them and
| prevent a painful migration down the line when your dev velocity
| has slowed down to a crawl because of the complexities of the
| codebase.
| r3trohack3r wrote:
| There are two forms of "the web"
|
| There is the document web - in which HTML/CSS/JS is more than
| sufficient.
|
| Somewhere between Web 1.0 and Web 2.0 we started experimenting
| with delivering application experiences to a web browser -
| arguably an abuse of the document web. This is the application
| web and it is a distinct use case. HTML, CSS, and JS on their own
| provide a pretty poor application development experience. At the
| very least, building a full application in HTML/CSS/JS is non-
| trivial. Rewind 10 years and many of the tools we take for
| granted on the backend were missing from web development, notably
| composability and dependency management. Scaling UI work up to
| teams of dozens of engineers is difficult. Companies with
| multiple UIs have a hard time re-using code between those UIs.
|
| Tools like React, Storybook, npm, and Webpack are addressing that
| gap. If you don't use them, given sufficient time and growth,
| you'll end up with your own patterns trying to address similar
| gaps in your code base.
|
| Arguably the industry took a pretty windy and awkward path to
| "on-demand sandboxed applications delivered over the wire," but
| that's just what happens with incremental development I guess. We
| started with a web browser and the document web, abused it to
| deliver some interactive applications, found it was "good
| enough," and then pushed it as far as it could go. We ended up at
| a local optimum. There are likely other optimums out there.
| azeemh wrote:
| I agree with your perspective on separation of concerns as that
| was the intent of the html5 standard.
|
| The reason react was invented was to enable real time update of
| items on the page -- to update when someone liked your item, or
| send you a notification update instantly instead of polling the
| server.
|
| It was the idea of pushing code to the webpage. So they made a
| component in javascript that updates in realtime -- the state or
| prop determining the content or how many likes the post had.
| However this ended up requiring a huge Redis instance which is
| also very expensive, so now they need to sell more ads. In order
| to figure this out they realize emojis on the like button allow
| people to choose a sentiment of their reaction to the content.
| Their ML uses the sentiment to group and sandwich ads between
| content the ML knows or thinks you will react favorably.
|
| So for example, a comedy central ad will be shown after a meme or
| story that is similar or something you reacted Haha to because
| the advertiser's desired reaction is a Haha as well.
|
| Thus the name React. Plus it makes that div/element/part of the
| page defined as a "component" in js that will update or "react"
| in realtime -- anytime they push an update to the server everyone
| viewing that page sees it change in realtime.
|
| Essentially a combination of a push notification or pubsub and
| ajax request.
|
| Honestly, when jsx goes out of style like it should because its
| idiotic, and gross, and a violation of those separations of
| concerns, it could just be an html page where you write a js
| function to add a realtime update to an id or class...
|
| Svelte uses that style of approach to the DOM.
|
| If you don't have a realtime data store like Redis or any type of
| realtime data streaming going on, React or any other component
| based framework is a waste of time.
|
| The ability to update the page without reloading or building as a
| single page app is not SEO friendly unless you use SSR which you
| already would have created in your normal seo friendly html
| files.
|
| also name your files consistently and clearly.
|
| unless you need to change the page in realtime without reloading,
| react and these other component frameworks have no use case.
|
| If you want a clean css3 framework to help build a web front end
| that works neatly in html5 check out Bulma.
|
| Bulma.io
|
| You are exactly right, the js developer scene is like a herd and
| people wanted to work at facebook or look smart so they learned
| it.
|
| It's useful for making single page applications, however all
| framework interactivity can be written in normal js, so if you
| take your time you'll have much cleaner, unbloated code, yielding
| pages that run better and faster...
| [deleted]
| tzm wrote:
| It's still there: http://vanilla-js.com/
| vbezhenar wrote:
| I think that most JS developers don't have experience writing
| code without React, so they just use tools they know.
| Sujeto wrote:
| I use vanilla html/css/js exclusively. I made some helper
| functions to manipulate DOM. I do everything manually, including
| saving state. And it works just fine. I find React and others
| confusing.
| ilaksh wrote:
| For my own startups that I work on as a solo developer over the
| last few years, everything is currently in vanilla JS and CSS.
|
| I have been programming for decades and used many different
| component systems on the web and desktop, such as React, Angular,
| Vue, WPF, wxWidgets, some more that I dont remember.
|
| For projects involving several designers and developers, some
| kind of component model might be necessary to be able to easily
| reuse and integrate code. Also designers or backend programmers
| may not factor in the complexity of certain design or
| architectural decisions such as state changes that are supposed
| to cascade to other items on the page.
|
| Since I am controlling all of those decisions, I can for example
| simplify so that either only state relevant to one small element
| is updated, or an entire tab panel is re-rendered. And then can
| ensure there is time to optimize the panel rendering.
|
| With that amount of control, usually the extra cognitive load for
| the component system etc. seems to not be worthwhile.
|
| But for example many years ago I had a complex web front end
| given to me on a shoestring budget, with subpanels etc.
| supposedly automatically reflecting every other type of state
| change that occurred. He insisted that I use a plain version of
| something called Knockout.js which did not have facilities for
| tracking and updating based on so many dependent state changes.
| Then he kept adding more and more panels and components, with
| more cascading or interacting state changes that caused bugs when
| I tried to manually keep them up to date.
|
| So that was kind of a "setup" in terms of the architecture
| required of me by the contract and the design decisions and there
| were lots of bugs and was especially rough to do in a small time
| frame. At the time things like React and related state management
| did not exist or were not known to the client, who thought he
| knew better about architectural decisions anyway and so that
| wasn't something I had room to negotiate or in the budget to
| research.
|
| You either need a good concept for handling all of these
| potentially interacting state changes such as what happens with
| component and state flow systems, or you do what I do. The whole
| design avoids it where possible, and when necessary I set it up
| so I can just re-render that whole section, making design
| decisions to avoid something causing annoying latency or other
| problems. It's a lot easier for me to do this stuff as a solo
| developer where I have end to end control.
|
| Also one thing that has changed in the last several years I think
| is that Firefox and Chrome have gotten significantly faster at
| re-rendering HTML through various optimizations. So actually some
| teams may want to reevaluate complex state or component
| frameworks to see if they might be overkill.
| sysadm1n wrote:
| Honestly, I'm turned off by these frameworks. Javascript is an
| easy language, and these frameworks raise the bar to entry. Many
| will say they make things 'easier' but that's not my personal
| experience. Some context: I wrote a _lot_ of JS in the early
| /late 2000s (Anyone remember WebFX by Erik Arvidsson?). His
| follow-up gig became WebOS[0]
|
| Back then it was called DHTML or Dynamic HTML and then evolved
| into the HTML5 standard later on. The syntax of React & Vue is
| just too _weird_ for me. Frankly I 've reached a framework
| fatigue after learning jQuery inside out which was a hard-won
| battle, and then having to learn React/Vue/Svelte just to stay
| 'in the game' is too much for me. Excuse me if I'm biased here.
|
| [0] https://newmedia.fandom.com/wiki/Web_Operating_System
| bornfreddy wrote:
| I can relate to that. I got "lucky" that I had to learn React
| in a few weeks, and while I grumbled a lot in the beginning, I
| came to love it (not js packages ecosystem though, that simply
| sucks). Huge thanks to my coworkers at the time who took me
| through the speed course!
|
| You need to look at ES6 as a completely new language, almost
| completely unrelated to JS. Once you learn it, React is easy -
| and genius in its simplicity. I can't imagine building even a
| medium sized webapp without some way of building UI
| declaratively. Maintaining a classical jQuery / native JS
| webapp is a nightmare, while these frameworks break up the
| problem into manageable pieces.
|
| Highly recommend biting the bullet and learning one of them, it
| really is worth it (not necessarily React, there are lots of
| others too).
| solardev wrote:
| Javascript is an easy language only for trivial use cases. Once
| you start having to deal with real-time async state across
| multiple components, it becomes very much not so easy.
|
| These frameworks aren't meant to do what basic DHTML did back
| in the day. Those use cases are still served just fine by basic
| scripting or serverside interactivity.
|
| What these frameworks allow are entirely new classes of
| featureful client-side applications (think Google Workspace,
| Maps, Earth, dashboards, games, sketching programs, photo
| editors, etc.) that would be HELL to write in vanilla JS.
|
| If you're not building something like that, nobody is forcing
| you to use those frameworks. But at a certain level of
| complexity, those frameworks are worth their tradeoffs. Beyond
| that, at an even higher level of complexity, they become
| necessary... or you end up writing your own framework.
|
| The reason these see such adoption isn't because devs are
| getting easier, but web apps are getting orders of magnitude
| more complex than back in the day.
|
| I don't think the bar to entry to has necessarily gotten much
| higher; rather, the skill ceiling has increased a
| thousandfold... you can still be a basic JS dev to add a basic
| form validation and submission or whatever, and you don't need
| React for that. These days vanilla is plenty powerful for
| simpler use cases. But you can't easily scale that up to the
| level of modern web app interactivity. Or if you can, well,
| build it and show people and see if you succeed in convincing
| them "this is better than Vue/Svelte/React/Angular". People are
| always saying that, but I've yet to see a complex web app NOT
| written in some sort of abstracted framework. If you manage to
| do it, it would be very impressive and way more convincing than
| just saying "frameworks are unnecessary" -- because as far I
| can tell, along with thousands of others of web devs, they are
| not.
| tkpremier wrote:
| I hear you...another level is that building javascript files
| has gotten so obfuscated with build processes such as webpack,
| babel, and typescript, that it adds a layer of confusion just
| to output code that you know is valid code, but all these darn
| build processes may give you problems under the hood....then
| you gotta research all that nonsense and find that some
| packages weren't updated.
|
| THAT is the fatigue part to me. I don't really mind learning
| new frameworks, cuz let's be honest, most of them are all doing
| CRUD operations and repainting the browser with new html.
| However, under the hood stuff that potentially arises with
| misaligned, packages, or configs...ughhhhh
| wruza wrote:
| Webpack specialist became a _position_ recently. I miss these
| good times when you could simply %.o: %.c $(CC) -c $(CFLAGS)
| $(CPPFLAGS) -o $@ $ < and feel great for the rest of the day.
| tkpremier wrote:
| Hahah, I'm not surprised. Them config files have created a
| niche FE DevOps Specialist role.
|
| To be fair, while the hours of painful medium articles and
| gists research, the knowledge gained has given me a better
| understanding of Webpack, and I do feel more confident when
| taking on various tutorials which all have different
| approaches to fit the config to my needs. But still, as a
| newcomer to JS or someone in OP's position, the build game
| is certainly a lot more complicated than your command!
|
| ....btw, I have no idea what your command does/says :D.
| Linux (Ubuntu) CLI syntax has been something I've tried to
| improve on over the years.
| wruza wrote:
| Yep, the blogspam only adds to the complexity because you
| can not be certain of an author's level of knowledge
| until you become an old sailor yourself.
|
| This command is a Makefile rule for building .o out of .c
| source files. It is var-heavy, but results in something
| like: gcc -c -std=c99 -Wall
| -I/path/to/headers -o file.o file.c
|
| I have no idea what my usual webpack config results into
| and how to debug that mess.
| joshmanders wrote:
| I find this interesting because the string you just
| provided you feel is something so ubiquitous that everyone
| knows what you're talking about.
|
| It may as well be a foreign language to me, but webpack?
| Webpack is easy... To me.
| balls187 wrote:
| I think the parent commenter's script was posted with
| tongue in cheek.
| pier25 wrote:
| > _Back then it was called DHTML or Dynamic HTML_
|
| Well that was rather during the 90s, no? Like a decade before
| HTML5.
|
| That was what it was called when I first started using JS in
| the late 90s with IE3 or 4 IIRC.
| dukoid wrote:
| You may like notemplate1 O:)
|
| 1) https://github.com/stefanhaustein/notemplate
| xtracto wrote:
| I second this. I started writing HTML/Javascript since _before_
| CSS existed. Nowadays I mainly do backend, but keep doing JS
| /CSS/HTML for some small pages.
|
| I recently started to work in React for some work stuff, and I
| just hate it. Actually, both the "class oriented" and the newer
| "hook oriented" versions just suck. They amount of abstraction
| crap that get over a website is amazing. And Redux with the
| dispatch state change ... Angular is a bit more sane but still
| similarly bloated.
| vi2837 wrote:
| That is just because you worked for long time with backend.
| Angular looks better for you - because it was developed to be
| easy adoptable by backend devs. But React is great, it just
| use different paradigm than is used for backend development.
| PS.I have also stared from those web early times.
| [deleted]
| rwalle wrote:
| Spotted a non front end developer.
|
| I'm being honest here -- there are things you need to learn.
| You may not like them at a beginner or someone new to the
| stack, but they are here as industry standards for good reasons
| (which I won't go into here).
|
| By the way, JavaScript is not necessary a language as "easy" as
| you think is. I have seen plenty of bad code written by
| professional software engineers. Seriously, you need to put a
| lot of effort into becoming a good front end developer.
| umvi wrote:
| Some of the very best websites I've had the pleasure of
| visiting and interacting with use vanilla (like
| https://ciechanow.ski/ for example). Using React for every
| frontend solution is like using K8s for every cloud solution.
| Great if you know it, but a huge complexity headache for
| literally everyone else.
| potatoz2 wrote:
| React is orders of magnitudes simpler than K8s. You can
| write your own React in a day probably.
| nso95 wrote:
| Or you can avoid frontend work
| neon_electro wrote:
| You are not alone. I've done exactly what you have and have
| faced 7 months of job searching headwinds this year just
| because (at least it feels like this to me) my employer didn't
| put me in front of enough React code (because they put me in
| front of other legacy code that needed more attention!!).
| rglover wrote:
| You'd dig Joystick: https://github.com/cheatcode/joystick.
|
| I designed it to be a natural transition from learning the
| fundamentals of HTML, CSS, and JavaScript into full-blown,
| component-driven UI development. Dirt simple API, no syntax
| tricks, no specialized knowledge. Just plain ol' HTML, CSS, and
| JavaScript organized into a system that's more productive than
| standalone files.
|
| It works on its own in the browser or as a part of a full-stack
| framework.
| Aperocky wrote:
| Same here as a backend engineer.
|
| I went into js/ts because I wanted to create something that I
| can interact with graphically, I don't really care about DOM.
|
| Worked out for me mostly:
|
| https://aperocky.com/cellular-automata
|
| https://prehistoric.tech
|
| These are built with typescript and compiled to js, with
| HTTP/CSS being static. And basically no framework usage. All of
| the complexity are essentially the simulation themselves.
| mamcx wrote:
| > I don't understand what problem they're trying to solve
|
| Certainly, not building a website. MAYBE building certain kinds
| of apps, like a game or a paint app (see: most action is truly on
| the client-side).
|
| ---
|
| I found a simple stack that is super-productive & efficient:
| https://tailwindcss.com + https://htmx.org.
|
| This is, IMHO, the best way to do "normal" websites, even the
| ones some are tempted to get nuts with stuff like React
| (eCommerce, blogs, chat app,...).
|
| The best is that it actually embrace the web as-is and not
| requiere anything to degrade correctly.
| mkl95 wrote:
| Abstraction. If you use HTML/CSS/JS to solve some problem there
| is a high chance you are reinventing some package that's freely
| available via npm or Yarn. Even a leaky abstraction can be better
| than reinventing the wheel.
| pie_flavor wrote:
| They make everything faster to develop and maintain. Same reason
| you'd use a framework for anything in any other language. When
| was the last time you saw a web _server_ implemented with a HTTP-
| parsing library, instead of a framework for defining endpoints?
| voidfunc wrote:
| Go's vanilla HTTP server lib gets pretty close to being not
| much more than an HTTP parsing library. Some people pull in a
| routing library, but a lot of times its all done manually by
| processing off the incoming http.Request struct.
| giaour wrote:
| > When was the last time you saw a web server implemented with
| a HTTP-parsing library, instead of a framework for defining
| endpoints?
|
| This is not unheard of in languages that have an HTTP server
| and router built into the standard library (Go is the most
| prominent example here, but I've seen many node.js web services
| written w/o 3P frameworks). You could argue that the stdlib
| functionality _is_ a framework, just not one that you need to
| install, but the same could be said of vanilla HTML /CSS/JS.
| wruza wrote:
| Regular non-ui programming is different from ui one.
|
| In a regular straightforward program you apply a change and read
| it back only when it is needed. Even if that change is
| cached/computed/transformed/etc, there is only need to observe it
| when your program execution comes to that part.
|
| In a ui program after doing a change you have to somehow update
| all the relevant elements/controls that are currently visible on
| a screen, i.e. replicate the whole state of a program into a
| graphical context at once (regardless if html or not). This
| process has associated costs and is pretty error-prone if not
| addressed systemically. All these frameworks spin around some
| idea of optimization of it. Since it can't be done without
| tradeoffs, they invent new ways of thinking about a problem,
| offloading parts of it via methodological contracts to a
| developer, who pays their half of the price. Different developers
| have different opinions on how high the price should be and which
| trade-offs they should take.
|
| Is it worth it? Sometimes yes, sometimes not really. In my
| opinion, ideas behind some frameworks are useful by themselves,
| but in general all this tends to become more religious rather
| than technical. E.g. if you weigh what "cost" is or how error-
| prone the straightforward approach is, you may find that for some
| cases it doesn't really matter.
| balls187 wrote:
| It's hard not to read many of these comments as "Old man yells at
| cloud."
|
| I've been lucky enough to experience development across many
| different types of systems over my 20-year career, and web
| development has come a long long way to the point that Vanilla
| development is viable.
|
| Generally speaking, I prefer to spend my time solving problems,
| not reinventing the wheel with boilerplate. Using a framework
| like react aids me in that goal.
| lewdev wrote:
| I have enjoyed writing HTML/CSS/JS (vanilla) apps on my personal
| projects and use React for large apps at work. When my apps get
| large, it gets harder to manage, whereas when using React, each
| component is contained, so I don't have to worry so much about
| what's going on around it. That's not a good description, but
| it's easier to built on top of a large React project, than it is
| on a large vanilla project.
|
| Frameworks also establish a common way of doing things like
| tracking state. For example, in vanilla projects, one developer
| might implement it in a unique way that no one else understands.
| You want to work with code that works well with multiple
| developers on larger projects.
|
| It's still fun and interesting using vanilla for personal
| projects. I built a bunch of apps with just a CSS framework and
| JS was vanilla. (my apps: https://lewdev.github.io)
| lhorie wrote:
| Disclaimer: I'm the author of one of the frameworks mentioned in
| this thread.
|
| Yes, HTML/CSS/JS are perfectly fine tools for web development.
| But just like it's not as efficient to use a hammer as a nail
| gun, using HTML/CSS/JS alone might not be the best choice if
| you're trying to build something highly interactive or if you
| have other concerns (e.g. a very large team that consistently
| steps on each others' toes on accident).
|
| I'd encourage that you try to actually take HTML/CSS/JS as far as
| you can take them, if nothing else to experience the pain points
| of using them at high levels of complexity yourself. This can
| give you an appreciation for _why_ frameworks do things the way
| they do. For example, routers are patterns that every framework
| dealing w / parameterized pages eventually lands on because it's
| a pattern that makes it easier to manage page parameterization.
|
| It can be argued that some frameworks land on seemingly strange
| or overly complicated APIs sometimes, but that's just the
| realities of engineering. We try to make the best decisions with
| the known information at the time, and then we have to consider
| maintenance costs after the fact. Nobody is perfect and sometimes
| we only see flaws in an approach through hindsight. There's also
| such a thing as using the wrong tool for the job. Frameworks
| usually have scope and an idiomatic way of being used. These
| indicates which use cases the frameworks are strong for, and
| which aren't.
|
| Most self-respecting frameworks will have some sort of tutorial
| that you can follow to get a feel for what type of tasks they are
| trying to optimize for. Try them out to see if that's what you
| need. If it's not, that's ok, there are plenty of other tools
| that could fit the bill better. My recommendation would be to try
| different "categories" of frameworks. For example,
| React/Vue/Svelte are very similar in scope, so trying one should
| give you an idea of what all three are more or less all about.
| You could try htmx, or GWT or even jQuery to experience
| completely different flavors of "framework-ness", maybe one of
| those will "click" better. Maybe you'll find that vanilla
| HTML/CSS/JS is all you need after all, and that's ok too.
| ckz wrote:
| These frameworks have emerged for historical reasons. There was a
| time when HTML/CSS/JS was much less capable and much more fiddly
| to use. Libraries and frameworks gradually evolved to both smooth
| the wrinkles and provide dev-workflow-oriented abstractions
| (components, etc.).
|
| They do, of course, add their own wrinkles, but at the time of
| adoption ostensibly the juice is worth the squeeze--at least for
| whatever real-world challenge a given team (or the broader dev
| culture) is facing at the time.
|
| ---
|
| I'll still use pure HTML/CSS/JS for client projects, depending on
| the context. Usually for static sites or interactive UI/UX
| prototypes, both in freelance and day-job (agency, bigcorp)
| contexts. So far, folks are very happy with the outcomes, but I
| do vet the fit first. :)
|
| In other contexts like enterprise/SaaS apps, Shopify builds, etc.
| I won't insist on no-JS or avoiding React/SPAs, as much as I'd
| secretly like to, but I will advocate for self-hosting and
| minimizing 3P JS dependencies where we're not necessarily gaining
| a huge increase in capability in exchange for dev convenience,
| etc.
|
| It's a balance.
| reducesuffering wrote:
| I notice that the distribution is heavily skewed where the
| HTML/CSS/JS camp is using it for their blog or 1-person project
| and has been doing it like this for a decade, where the
| React/framework camp are the people who have done both and are
| working on large projects.
|
| The basics of React are learned by 1-month novice programmers in
| 2022. You don't even need a build system (which is even setup for
| you with Next or create-react-app). At it's core, it's just a
| file which contains "super"-html that you can update state more
| easily.
| avgDev wrote:
| I am a solo dev.
|
| I wrote a complete warehouse management system. I wouldn't be
| able to accomplish this in a relatively short time frame without
| help of frameworks and libraries. Instead of using vanilla SQL
| queries I used LINQ. For UI, I used bootstrap, because it made it
| easy to handle desktop/mobile. For async calls I used old jquery
| because it worked well enough with .NET and was well documented.
| Additionally .NET allowed to scaffold models and identity.
|
| I can write a site in JS/HTML/CSS, however, why? I would rather
| do things quickly with proven frameworks. Size of websites is
| less of an issues these days. There may be use cases for going
| pure vanilla but often not the case from a business perspective.
| temp_account_32 wrote:
| Using pure HTML/JS/CSS is so unopinionated that it's very easy to
| create spaghetti, and hard to onboard new developers because you
| have to teach them a lot of 'this is how we do stuff here'.
|
| Don't get me wrong, it's perfectly possible to create spaghetti
| in React, but it just makes large codebases so much more
| manageable, and the tooling and ecosystem around it is massive.
|
| Typescript with React and a bundler, linter etc. is just an
| amazing developer experience, compared to the mess those of us
| who did front end development in the past remember.
| tstrimple wrote:
| I agree with this. It's especially important to use opinionated
| frameworks (Angular being more opinionated than React) when
| working with a lot of contract developers who rarely care about
| internal development culture or standards. With Angular, there
| are a lot of prescribed ways to accomplish common functionality
| which you could solve any number of ways in React or even more
| ways in vanilla JS. A cohesive and experienced development team
| can do amazing things with whatever tools and frameworks they
| decide to use, but less cohesive teams benefit from opinionated
| frameworks.
| typingcyclist wrote:
| Depending on what you want to build and how many people will
| contribute, the answer might vary. HTML/CSS/JS can be enough, but
| mostly you will need to handle streamlining browser differences
| etc. explicitly. Frameworks are popular because they can help to
| streamline these issues. Also there is mostly an eco-system built
| around these frameworks, so you don't have to build every
| component from scratch for example. From a business perspective
| it's easier to say we're hiring for this specific framework
| (React, Vue etc). vs. we have our own rules and styles. Finally
| these frameworks also have a social function. It's like a style
| or taste preference, where a group shares the same preferences.
| rglover wrote:
| Yes, they are. This is why I built Joystick [1] to take a lot of
| the valuable concepts of modern web development frameworks and
| make them work with pure HTML, CSS, and JavaScript without any
| hacks, syntax tricks, etc.
|
| [1] https://github.com/cheatcode/joystick
| JimmieMcnulty wrote:
| I find myself missing React when building a plain HTML/CSS/JS
| site. I just like the modularity and my fingers have muscle
| memory for solving certain issues.
| julianlam wrote:
| From somebody who's been in the industry for a little bit (only
| 10+ years, which depending on your perspective could be no time
| at all, or a lifetime!), I'd be wary of becoming too familiar
| with the "react way" (substitute your framework of choice.)
|
| Aeons ago I learned js with Mootools, so much so I thought in
| Mootools vernacular. Imagine my surprise when Mootools went
| away seemingly overnight and I couldn't code vanilla js to save
| my life.
| JimmieMcnulty wrote:
| Fair!
|
| I'm pretty confident in my ability to pick up new tools and
| tech (I'm probably too far into the "bleeding edge" side of
| the "how comfortable are you supporting new tech in prod?"
| scale), so I'm not overly worried about getting left behind.
|
| I just recently had to explicitly build a "raw" JS/HTML/CSS
| app for work, and found myself missing the organization React
| overlayed on top of JS, is all.
|
| Besides, my bread and butter is backend, so I can always
| throw my hands up and shove the work onto some web dev's
| plate if I ever do get left behind! :D
| IYasha wrote:
| You also forgot to mention Flash :) It was starting to solve all
| the problems: from design to inveractivity. But then Adobe.
| cetinsert wrote:
| People love getting themselves tangled in convoluted frameworks.
|
| ---
|
| We are building SyncHTML.io to counter that.
|
| Try at https://sy.ht (press up/down arrows)
|
| See how we set ourselves apart https://efn.kr/b/sync#new-
| playground
|
| ---
|
| Web standards are unbeatable when used right.
|
| They are not used right most of the time.
|
| ---
|
| See 2 custom elements done right(tm): (The /?s at the end is
| significant!)
|
| 1. zero-md: https://md.sy.ht/?s (just press up/down arrow keys)
|
| 2. WebPDF.pro: https://pdf.sy.ht (view); https://pdf.sy.ht/?s
| (edit)
|
| (The WebPDF.pro elements are served from an unoptimized server.
| Takes a few seconds to load.)
| foobarbecue wrote:
| I tried these links and couldn't figure out what's going on.
|
| When I go to https://sy.ht, I see a clock animation on the
| right and a blank editor on the left. I tried arrow keys and
| nothing happened.
|
| Got ERR_CONNECTION_RESET from https://efn.kr/b/sync#new-
| playground
|
| What are you sharing? Is this a codepen-like thing?
| cetinsert wrote:
| Oh, thank you for reporting! Might have temporarily hit a
| limit (https://deno.com/deploy/docs/pricing-and-limits) with
| the link shorteners.
|
| This is what I am sharing: https://sy.ht/yt (YouTube video
| showing what this is about.)
| robertakarobin wrote:
| I've always really preferred keeping it simple with HTML/CSS/JS
| and find most front-end frameworks to be a huge turn-off. You
| might like Astro (https://astro.build). I love that my sites are
| still 100% HTML/CSS/JS that I wrote myself. But Astro comes with
| Sass and Typescript support out-of-the-box (no Webpack
| necessary), and also makes it easy to do reusable components,
| scoped styles, supports FE frameworks if you want them, etc. It's
| the happiest medium I've found yet. :)
| silent_cal wrote:
| Cool, thanks for sharing!
| bob1029 wrote:
| We do 100% vanilla web development for our B2B product now. Our
| roadmap went something like:
|
| (Client Authoritative State) Angular 2.x/??? => RiotJS/Bootstrap
| =>
|
| (Server Authoritative State) Blazor/Bootstrap => Custom/Vanilla
|
| The Angular and Riot apps were a nightmare to maintain long-term.
| We sign contracts with our customers that are 5+ years long, so
| having autonomy over this sort of stuff is critical. The rate of
| change with these frameworks was too much to deal with,
| especially at our scale of <10 employees.The big solve moving to
| Blazor from RiotJS was keeping the state on the server and being
| able to reuse existing C# codebase to manage UI. This continues
| to be very productive for us. Server-authoritative state is _the_
| answer for keeping complex UIs on rails.
|
| We still have quite a few interfaces on top of Blazor, but those
| aren't really a pain point for us (at least until Microsoft does
| what they usually do in a few major versions...). The biggest
| catalyst for moving from Blazor/Bootstrap to Vanilla was 2-fold:
| On one hand, the power of modern web APIs, such as CSS Grid,
| eliminates a large reason why you need a 3rd party layout system
| in the first place. On the other, we realized that dynamically
| updating the DOM using a 2-way web socket setup is actually not
| that complicated or scary, assuming you have well-scoped
| requirements and aren't afraid of javascript.
|
| For hand-rolled vanilla, the way we sync the DOM is with a simple
| 2-way web socket protocol where the server has a dictionary of
| elements per active client, and hashes of state are used to
| detect required updates after client events are processed. No
| shadow DOM or any of that crap. We just blow it all out and
| redraw on update. None of our UIs has enough elements to justify
| all that extra complexity right now. We could easily iterate into
| several directions if we needed to over time. The key point is
| that we understand 100% of our stack. Every line of code makes
| sense to us. At no point do we have to worry about someone
| pulling support or shifting their framework in an adverse
| direction.
|
| Finally, we also have major security concerns with vendoring out
| anything, since our product is used - in part - for in-branch
| banking. The hottest PII you can imagine flows through our web
| app every day. Being able to tell various CTOs that there is no
| supply chain risk with our web UI is a very fun hat trick for me.
| P5fRxh5kUvp2th wrote:
| I have a mini-rant about that. When a company decides to use
| Angular (for example), they're also deciding to jump on the
| rat-wheel that is constant upgrades to the next version.
|
| Meanwhile, that vanilla app will just keep working in
| perpetuity.
| nfw2 wrote:
| A company can just stick to one version of Angular in
| perpetuity if it wants to. The code in some Angular X.X.X
| release will always be the same, and the Angular org can't
| magically break your code by releasing a new version of it.
| P5fRxh5kUvp2th wrote:
| How sure are you of that?
| n3t wrote:
| You can vendor your project's framework of choice. Or,
| more generally, all your dependencies.
|
| Moreover, I believe you should be able to build your
| project without expecting npm to host all your
| dependencies ~forever and being online when you need it.
| tqkxzugoaupvwqr wrote:
| But if your framework of choice is big, you'll have trouble
| extending/modifying it and be locked in.
| nfw2 wrote:
| And if your hand-rolled solution is big, you'll also have
| trouble extending/modifying it.
|
| The argument was that hand-rolled code doesn't break on
| its own, and my point is neither does framework code.
| beej71 wrote:
| "Every dependency is a benefit and a liability."
___________________________________________________________________
(page generated 2022-09-09 23:02 UTC)