Other than for learning purposes or very lean projects, you'll de-framework yourself just so that you have to spend extra time rebuilding it instead of focusing on the essence of your project
Plain Vanilla Web
11–20 of 715 posts
Re: Plain Vanilla Web
#12> The most basic structuring technique is separating CSS into multiple files. We could add all those files in order as \ tags into the index.html but this quickly becomes unworkable if we have multiple HTML pages. Instead it is better to import them into the index.css (via @import)
You'll eventually need \ anyway for preloads, especially with web fonts, since that's the only way to prevent FOUC. Personally I lean on build steps to solve this. I don't like bundlers or frameworks, but I have grown accustomed to custom-building.
Re: Plain Vanilla Web
#13Good to understand, but most likely better to stick with react for production stuff anyway
[dead]
Re: Plain Vanilla Web
#14I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.
Re: Plain Vanilla Web
#15Other than for learning purposes or very lean projects, you'll de-framework yourself just so that you have to spend extra time rebuilding it instead of focusing on the essence of your project
This is the common wisdom about frameworks but I think it ignores the wastage & other side effects around frameworks and the things they make easy or difficult. Many of the decisions made in any framework will represent guardrails for things that don’t apply to you specifically.
I know you’ll “write your own framework” but maybe that’s optimal in some situations - more than we might give credit to at the moment.
Re: Plain Vanilla Web
#16Question - why would you do this in current year ? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!
Because of the ridiculous complexity in their setup and operation, their glacially slow performance if it is actually written in JavaScript and not a non-web platform language that compiles to native code, and their extreme volatility and instability/pace of deprecation.
The benchmarks I've seen actually show web components being slightly slower than the best frameworks/libraries.
The idea is: no build steps initially, minimal build steps later on, no dealing with a constant stream of CVEs in transitive dependencies, no slow down in CI/CD, much more readable stack traces and profiling graphs when investigating errors and performance, no massive node_modules folder, etc. Massive worlds of complexity and security holes and stupid janky bullshit all gone. This will probably also be easier to serve as part of the backend API and not require a separate container/app/service just running node.js and can probably just be served as static content, or at least the lack of Node build steps should make that more feasible.
It's a tradeoff some people want to make and others don't. There isn't a right and wrong answer.
Re: Plain Vanilla Web
#17Question - why would you do this in current year ? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!
Frameworks are fine when you just need to get a job done quickly. And they're ideal when you're in a typical corporate code factory with average turnover, and for the same reasons Java is ideal there.
React is the new Java.
But when you need something the framework can't provide, good luck. Yes, high performance is typically one of those things. But a well engineered design is almost always another, costing maintainability and flexibility.
This is why you almost always see frameworks slow to a crawl at a certain point in terms of fixing bugs, adding features, or improving performance. I'd guess React did this around like 2019 or so.
Re: Plain Vanilla Web
#18Question - why would you do this in current year ? Is it that much more performant? I might be ignorant but frameworks seem to be the lingua franca for a reason - they make your life much easier to manage once set up!
It actually is kind of about performance.
For me it's mostly about de-tooling your project.
For example - I have a fairly complex app, at least for a side project, but so far I managed to keep everything without a single external dependecy nor any build tool. Now I have to convert it all to react and I'm not very happy about that, I will have to add a ton of tooling, and what's most important for me, I won't be able to make any changes without deploying the tooling beforehand.
Re: Plain Vanilla Web
#19I have some notes here at andrewmcwatters/custom-elements https://github.com/andrewmcwatters/custom-elements.
My business doesn't use React anymore, and I'm so happy I don't have to do pointless maintenance.
A side note, included in my repository: you update your element's innerHtml from the constructor, not from the connectedCallback. MDN and the web standards seem to be inconsistent on this, and elsewhere people write about it, too.
People talk a lot about data and binding, etc. I think it's weird, it's like people have forgotten how to just use setters. You can call a render() method from a setter, and it does the same thing WebKit et al do when you call an internal setter on an HTML element.
I don't see the value in these frameworks anymore.
Re: Plain Vanilla Web
#20I work for about 2k users, they do not give a shit about reactivity... build a monolith, make it comfy, embrace page refresh (nobody gives a fuck about that in the real world), and get shit done.
Unless the page refresh is fast, I tend to agree with you!