Develop web applications without any framework: is it possible

Angular used to be popular, then React, now Vue.js… others like Ember, Backbone or Knockout are almost gone. Some standards, such as Web Components, are rarely used. It seems that new frameworks are released every year, like Svelte, Aurelia, and each framework has a corresponding object on the server side (NestJS, NextJS, or Nuxt for those at the beginning, Sapper for Svelte, etc.). Not to mention non-JavaScript web frameworks like Django, Spring, Laravel, Rails, etc. There are even frameworks on top of frameworks (Quasar, SolidJS), frameworks that generate component code for frameworks (Stencil, Mitosis), and NCDP (No-Code Development Platform).

This variety confuses developers and technology sizing decision makers who want to know which technology is worth learning.

There are often articles comparing these frameworks on the Internet, which seem to help us solve this confusion. But most authors are usually biased because they may have “used this framework” but “only tried a few other frameworks”. Less biased authors always conclude “it depends on the situation” (depending on performance, tools, support, community, etc.), which is effectively an inconclusive conclusion.

Even if some benchmarks compare different frameworks based on the same application, it is difficult to get real results because such benchmarks are limited to the application being tested (such as a to-do application).

Frameworks look like religion (or politics): each one pretends to provide a solution for the developer, but each one is different. Each of them claims to offer the best prospects for the application, but there is a constant debate about which one really lives up to its name. Each framework requires you to follow specific rules, and there may be similarities between them, but it is always difficult to transition from one framework to another.

Now, let’s take a look at the “atheistic” approach to frameworks: no frameworks are used.

Where to start?

In addition to my over 25 years of professional software development experience, this article will build on my experience building real pure JS web applications (front-end and back-end).

Why not use a frame?

Actually, the idea is quite new. Back in 2017, Django web framework co-founder Adrian Holovaty talked about his framework “fatigue” and why he left Django to build his own pure JS project.

One might ask, why would anyone want to develop a web application without using a framework? Why not build on what others have spent years and effort developing? Or is it because of the NIH (Not Invented Here) syndrome that everyone wants to build custom frameworks?

Developers are not more prone to asking for trouble than the average person, in fact, they are probably lazier than anyone: they just want to write less code (so they can make fewer mistakes), want to automate (to avoid human error)……

Develop web applications without any framework: is it possible

But they also want agility, which means being able to solve problems easily and quickly.

While “fast” seems to be what the framework promises (scaffolding for you, and adding reliability), it’s not free: they want you to sign a contract, agree to pay a “tax” fee, and put your code in ” Orphaned Wells” (“Taxes and Orphaned Wells” quote from Akira Sud, IBM Carbon Systems Design Team Leader https://github.com/carbon-design-system/carbon-web-components#readme).

framework tax

There is a cost to using a framework:

Follow their API rules so they can serve you. That’s how frameworks work: your code has to obey certain rules, including more or less boilerplate code. What you think about every day is not “how to do this”, but “how to get the framework to do (or not do) this”. If you circumvent these constraints, you do so at your own risk: if you bypass frameworks by calling the underlying API directly, don’t expect them to understand your intent, and don’t expect them to behave consistently. So it’s a false promise that the framework will let you “focus on the business”: in fact, you don’t care less about the framework.

If you want these things, you have to force an upgrade:

1) want a new feature (you have to upgrade everything even if you don’t need all the features);

2) Want to fix a bug;

3) Don’t want to lose framework support (versions your app depends on will be deprecated as new versions are released).

It can be very frustrating (and possibly putting the project at risk) if the framework has bugs without a clear planned fix date. Framework libraries (such as widgets) or plugins provided by third parties are no exception, and if you keep using older versions, they will become less and less compatible with your application. Maintaining backward compatibility has become a very troublesome thing for framework maintainers. They found it more profitable to develop tools that automatically update code (Angular’s ng-update, React’s native update helper, Facebook’s jscodesshift, etc.).

  • Need to learn how to use them (what they can and cannot do, their concepts, API, ecosystem, tools), including understanding what might change in new versions. This may be easier if you choose the most popular framework, but you can’t know every aspect of a framework. Also, the hype never stops: if you decide to use another framework in a new application (or worse, migrate from one framework to another), all your investment in the old framework will be reset to zero. That’s why many enterprise projects lack dynamism, even though each project may not be the same as the previous one. The late David Wheeler once said: “Maintaining compatibility means knowingly repeating someone else’s mistakes”.

    Delegating control to the framework is a compromise on the framework’s flaws: you may not be able to do anything you want (or prevent the framework from doing what you don’t want them to do) or you may not get the performance you want (because additional layering, universality, larger code size or backward compatibility requirements).

    Skills are fragmented. A lot of developers either don’t know much about the underlying API (because they always use what the framework provides) or live in the past (only know outdated knowledge and don’t know about the latest improvements and features). The “law of tools” often leads to over-engineering, building complex solutions to simple problems, and gradually fragmenting the knowledge to build simple solutions. We lost (or didn’t gain) the culture of good software design (principles, patterns) and lost (or didn’t gain) the experience of building important projects under the guidance of guidelines. Just as users of CSS frameworks (Bootstrap, Tailwind, etc.) lack CSS skills, users of web frameworks are doomed to lack experience with modern web APIs and software design.

Develop web applications without any framework: is it possible

Once you put money in the frame, it’s hard to get it out.

frame solitary

Besides having to pay a “tax” fee to get the benefits of frameworks, if frameworks are not standardized, they pose another problem.

Because they force you to follow the framework rules – and every rule is different – this means your application will be tied to a proprietary ecosystem, that is, with a proprietary API (and its upgrade process) ) to lock your application code. It’s a risky bet for your project, as they all suggest:

no portability: migrating code to another framework (or a new version with breaking changes, or even not using a framework) would be very expensive, including possibly retraining costs;

Your code has no interoperability with other framework runtimes or other framework component libraries you want to use: most frameworks have a hard time interoperating with each other due to different rules.

Of course, at the beginning of the project, you can choose the most popular framework. This may be acceptable for a short-term project, but not for a long-term project.

Develop web applications without any framework: is it possible

Frames come and go. Starting in 2018, 1 to 3 new frameworks will replace the old framework every year.

However, there are no silos of standards frameworks. On web platforms (ie browser frameworks), using standard web APIs reduces the risk of your investment because they work on most browsers. Even if not all browsers support it, it can still be compensated with a polyfill.

For example, today’s Web Components are both portable (can be used in almost all browsers) and interoperable (can be used by any code, including proprietary frameworks) because they can be encapsulated into arbitrary HTML elements. Not only are they better performant, their runtimes (custom elements, shadow DOM, HTML templates) also run as part of the browser, so they’re already there (no download required) and native.

Develop web applications without any framework: is it possible

Few developers try to escape framework silos.

So frameworks are inherently bad?

If you create your own framework to implement your application logic, then you can’t say that frameworks are bad: any application needs to implement its own business rules.

A framework is good if:

is application specific: any application will eventually design its own “business” framework.

To be a standard, for example, the web platform is a standard web framework, and the final components built by the web component frameworks (lit, stencil, sketchjs, etc.) conform to this standard.

Add some unique value that other solutions (including other frameworks) lack. In this case, you have few options, and the added value justifies the implied lock-in cost. For example, an OS-specific framework follows the OS’s standards, and there is no other way to get an application or extension that meets the requirements.

For building non-critical (short term, low quality expectations, and “taxes” and “silos” are acceptable) applications. For example, use Bootstrap to build prototypes, MVPs, or internal tools.

Deframed goals

Simply put, the goals of avoiding frameworks to build applications are:

Maximize flexibility by avoiding the “one-size-fits-all” constraints of the framework. In addition, remove the constraints of the rules and increase the creativity of the application. Most Web applications developed with Bootstrap fall into this category, because it’s hard to get rid of predefined components and styles, and ultimately it’s hard to think otherwise.

Minimize your reliance on overhyped frameworks. Not being locked into the framework can avoid portability and interoperability issues.

Maximize performance by only doing the most fine-grained operations when needed (e.g., framework-independent refresh cycles), and by reducing dependencies and using only a few required lightweight libraries.

Of course, our goal cannot be to “reinvent the wheel” either. Let’s see what to do.

Options outside the framework

So, how do you develop an application without a framework?

First, we have to clarify an anti-goal: don’t confuse “building an application without a framework” with “replacing a framework”. Frameworks are a general technical solution for hosting arbitrary applications, so they target not your application, but all applications. On the contrary, it is possible to leave the framework out of the box to allow you to focus more on your application.

Develop web applications without any framework: is it possible

Developing an application without a framework does not mean reimplementing the framework.

To assess the difficulty of building an application without a framework, let’s understand: it’s not as difficult as building a framework, because the following are not our goals:

Build proprietary component models (containers that implement specific component lifecycles);

Build proprietary plugin or extension systems;

Build a fancy template syntax (JSX, Angular HTML, etc.);

Implement common optimizations (change detection, virtual DOM);

Framework-specific tools (debug extensions, UI builder, version migration tools).

Therefore, building a normal application is not a daunting task of “reinventing the wheel”, since this “wheel” is mainly about API/contracts, implementation, common engine and related optimizations, debugging capabilities, etc. Abandoning generic goals and focusing on application goals means you can get rid of most of the goals and that’s the real “focus on your application”.

So, how do we design and implement a normal application? Because most applications are built using frameworks, it is really difficult to devise a way to achieve similar results without these familiar tools. you must:

Change your mind: don’t use framework-specific services. For a normal application, you probably don’t need these services. No change detection required, just update the DOM directly…

Use other technical alternatives to perform common tasks previously performed with frameworks (updating the DOM, lazy loading, etc.).

Some authors like Jeremy Likness or Chris Ferdinandi (known as “JS geeks”) have also touched on this topic. However, by definition, any common application can choose (or not choose) to use one of these technologies, depending on its needs. For example, the authors of MeetSpace only need to use the standard API.

Next, let’s look at some common “solutions”.

standard

Standard APIs are “good frameworks” because they:

Portable: they are available anywhere, and if not, they can be polyfilled.

Interoperable: They can interact with other standards and be used in proprietary code.

Long-standing: Designed by multiple industry players, not just one. They’re well designed to stick around once they’re released, and there’s less risk in using them.

It is immediately available in the browser in most cases, avoiding the download process. In some cases, you may need to download a polyfill. However, unlike proprietary frameworks (destined to become less popular), they will become more usable (and gradually reduce the need for downloads).

When choosing a programming language, it is important to consider criteria. JavaScript has evolved over the years and now also includes features found in other programming languages, such as the class keyword and limited type checking support through JSDoc annotations such as @type.

Many programming languages ​​can be compiled into JavaScript: TypeScript, CoffeeScript, Elm, Kotlin, Scala.js, Haxe, Dart, Rust, Flow, etc. They all add different value to your code (type checking, extra abstraction, syntactic sugar). Should normal apps appear to use them? To answer that question, let’s see if they imply the same drawbacks as frameworks:

Follow the syntax: This is mandatory for most programming languages ​​(CoffeeScript, Elm, Kotlin, etc.). But be aware that they are a superset of JavaScript (TypeScript, Flow) and you can still write some parts of your choice in pure JavaScript.

If you are using a very old version of a programming language (including JavaScript), you will need to upgrade, but upgrades are much less frequent than frameworks.

Need to learn their syntax. However, you can learn the superset programming language incrementally, as parts of your code can continue to use traditional JS.

Discretizing skills is indeed a risk for non-superset programming languages. Because they compile universally and may not be optimal without you realizing it. Maybe you can do the same thing with simpler and more efficient JS code.

The downside needs to be compromised because we can’t change the process of transpiling to JS (or using tsconfig.json for a little customization) or to WebAssembly. Some languages ​​may also ignore some concepts of JS.

Portable because usually code can be transpiled to ES5 (but sometimes you have to compromise, even if you want to transpile to ES6). WebAssembly is very new and all modern browsers support it.

Provides interoperability with other JS code. For example, Typescript can be configured to support JS.

In an ordinary application, we should be careful to use non-superset languages ​​because they all imply some constraints more or less. Superset languages ​​(TypeScript, Flow) minimize these constraints by avoiding “all or nothing” and we should use them where they can bring value.

It’s important to note that a language layer built on top of JavaScript means another layer of complexity in our toolchain, which can fail for some reason (see below). Also, after compilation or transpilation, the benefits of the development phase disappear (typically no type or visibility constraint checking is enforced at runtime).

development library

Based on the assumption of not “rewriting the framework”, it is concluded that normal JS applications should not use development libraries. This is completely wrong. “Reinventing the wheel”, i.e. rewriting everything from scratch, is not a wise goal. Our goal is to remove constraints implicit in frameworks (not development libraries), please don’t confuse this with the “write everything yourself” dogma.

So if you can’t write some code yourself (maybe because you don’t have the time, or because it requires too much expertise), there’s nothing wrong with using a development library. You only need to care about:

Modularity: If you only need a small part of the functionality, avoid relying on the entire big development library;

Avoid redundancy: use the development library only when there is no standard, and give preference to the development library that implements the standard;

Avoid lock-in: Do not use the APIs of the development library directly, but wrap them in the application API.

A word of caution, don’t be fooled by docs or articles that claim they are not frameworks (because they are “not well-defined” as frameworks, or define a “complete application”): as long as constraints are implied, they are frame.

model

It’s not enough to just apply patterns (without using frameworks) to build software, Holovaty said.

Patterns are well-known things, not specific to a certain development process. They are themselves self-documenting in that they can be quickly identified by experienced developers.

Here are just a few examples:

Model, View and Controller pattern (MVC);

Factory pattern for creating objects based on configuration;

Observer pattern that simplifies reactive programming;

Iterator pattern for traversing the collection;

Proxy mode for lazy loading, security checks;

Command pattern for encapsulating actions that may be triggered based on context.

There are many such patterns: you are free to use them to suit your needs. If a pattern provides a typical solution to a typical problem in your application, you should definitely use it. More broadly, anything that conforms to SOLID principles and has good cohesion is good for application flexibility and maintainability.

update view

When interviewing developers, when asked what their main concern is when building a common application, most of them answer: implementing complex model change detection and subsequent “view” updates. This is a typical “tool law” effect, which makes you think in terms of frameworks, but in fact some of your simple needs don’t need frameworks at all:

“Views” are just DOM elements. You can of course abstract them (and you should), but in the end they are just abstractions.

Updating them is just a matter of calling viewElement.replaceChild(newContent) and doesn’t require updating the wider DOM, nor repainting or scrolling. There are several ways to update the DOM, from inserting text to manipulating the actual DOM object, just pick the one that suits you.

In normal applications, it is usually not necessary to “detect” when a view needs to be updated. Because in most cases, you only know what needs to be updated after an event, and you can just execute the command directly. Of course, in some cases you may need to make general updates by inverting dependencies and notifying observers (see below).

template

Another feature that developers don’t want missing is writing HTML fragments with dynamic sections or listeners.

First, DOM APIs (like document.createElement(“button”) ) aren’t that hard, and are actually more powerful than any templating language because you have full access to these APIs. Writing long HTML snippets can be tedious, and if they are really long, break them up into finer-grained components.

Treating these elements as templates does improve readability, though. So how to manage them? There are multiple ways here:

HTML templates are now available in the browser (actually since 2017). They provide the ability to build reusable HTML <template> fragments. This is actually part of Web Components.

JavaScript supports template literals since ES6 (2015), and you can easily embed values ​​into strings. You can embed primitive types (numbers, strings, including other HTML code, etc.), but not more complex elements such as DOM elements with registered listeners.

We can embed complex values ​​such as DOM nodes into templates with the help of markup template literal functions. ObservableHQ has designed a very handy tool to write code like html`<header>${stringOrNode}</header>, or to implement more complex templates like html`<ul>${items.map( item => `<li>${item.title}</li>}</ul>.

What about conditional or loop statements in templates? Not to mention that this is probably never a good idea (the UI shouldn’t have logic in it), you can (and should) just implement the logic in JS and then use the technique above to insert the result into the template.

event

Now that we have the basic template, how do we bind events to DOM nodes? There are also several options here:

HTML event handler code ( <button onclick=”myClickHandler(event)”> ) can be inserted into the HTML source code, but this is not the best approach because the specified handler is only available within the specified scope.

The event handler API ( button.addEventListener(“click”, myClickHandler) ) is available for all nodes created via the DOM API or HTML markup template literal functions.

So what about custom or business events? What if I need to react to some event fired by some component of the application? There are also multiple ways to handle this:

Custom Events: You can create your own event classes by extending EventTarget and dispatch or listen to them, just like “standard” events.

In theory, using an EventEmitter is also an approach (in Node, and as a library in the browser), but it’s rarely used.

Observer Pattern: You can build your own observer or consider using RxJs, it’s the standard for this. You just need to build a Subject and notify all subscribers when an event occurs, and let the subscribers react to the event.

components

While developing a normal application is different from developing a complex infrastructure (aka containers for hosting components), if something is going to be present multiple times in the system, it is still possible to design them as reusable components (context-agnostic) is a good idea. No matter what technology you use, business or technical, some level of granularity of abstraction is still useful: encapsulate data and rules related to the same business concept into a single reusable object, or build It’s always a good idea to instantiate widgets somewhere.

There are many ways to create components, depending on your needs. Back in 2017, Mev-Rael came up with a lot of tricks for working with state, custom properties, and views of JavaScript components. Of course, we should not be limited by the technologies recommended by others, but should consider our own needs first, and then choose the appropriate technology.

In addition to standard widget components (usually standard web components), any component should be able to:

Separate logic and views (usually using the MVC pattern). Mixing them together often results in less maintainable code and less flexibility (for example, if you want to display a record in both detail and table form, your RecordComponent only needs to use DetailRecordView or RowRecordView).

Parameterize the behavior or view of the component.

Notifies subscribers that some event has occurred in the component (usually after user interaction) by triggering an event.

Synchronization: The component should be able to redraw if some event occurs. This can be easily achieved using reactive development libraries such as RxJS.

In any case, no matter what design strategy you choose, your component (or more specifically, its associated “view”) must be able to provide some HTML rendering result. You can use a string containing HTML code, but HTMLElement (or Element ) is usually a better choice (higher readability, straightforward updates, event handlers can be bound to) and better performance (no parsing required).

Also, you may wish to use external components from third parties. Due to the higher popularity of proprietary frameworks, they can make greater use of community-developed libraries and groups. Most of them aren’t actually very different from features implemented in pure JS (like JQuery), but the problem is, they lack interoperability, so in the end you’ll find yourself needing pure JS or web components.

Fortunately, such libraries do exist, such as the Vanilla JS Toolkit, albeit perhaps less commonly. In terms of web components, webcomponents.org lists more than 2000 elements. There are even normal web components, but they’re less relevant to what we’re talking about (more focused on lightweight implementation than interoperability).

routing

Managing routes in the SPA requires the Web History API. While this isn’t complicated, you may still want to delegate this to a simple router library like Navigo.

All you have to do is replace one DOM element with another when routing (using the replaceChildren() or replaceWith() methods).

lazy loading

Loading JavaScript code on demand is a concern for any web application. You definitely don’t want to load the entire application code in order to display a login screen.

Back in 2009, before web frameworks existed, James Burke (Dojo developer) released RequireJS (originally called “RunJS”) to solve this problem. Since then, more technologies have emerged with the advent of modularity. Since ES6 (2015), we can dynamically load code. This works in Node, but also in the browser:

So how do I split the modules into separate files? A bundler (like Webpack) can do this for you.

 

It’s important to note that you should only use constants in import paths, otherwise the packer won’t be able to guess what you want to load and will pack all possible files in one file. For example, await import( ./welcome/${moduleName}) will package everything into the specified directory, since the packager doesn’t know what the variable moduleName will be at runtime.

native application

A growing number of frameworks provide a way to run, migrate, or compile applications for native platforms such as React Native to deploy them as standalone applications on Android or iOS mobile systems.

Aside from thinking about developing true native apps, the more common solution is to embed web apps in native containers, such as PhoneGap before (now out of maintenance) or Apache Cordova, and now NativeScript (which supports frameworks such as Angular, which also supports normal applications), or a native web application wrapper like Electron, or Electron’s lightweight successor, Tauri.

Server-side rendering

Many frameworks run similar code on the front-end and back-end, making it easier to implement SEO-friendly server-side rendering (SSR).

This can be a cool and convenient feature, but be aware that it can also cause server lockups. Therefore, before introducing framework lock-in to your application, you need to consider its impact on the project, infrastructure, client technology, etc.

Fortunately, you can also implement this feature without using a framework.

Render from the server

Going with a common implementation seems simple at first: just return HTML? Yes, you already have ready-made components, but:

You also need a server-side DOM API, because by default, the server-side does not provide a DOM API (JSDOM maintained by Domenic Denicola or the optimized Happy DOM are good choices).

Your rendering component cannot assume that the DOM is on the client or server side, i.e. don’t use the global DOM, because on the server side, every request needs a DOM. To do this, you need to select the DOM object (windowdocument and type such as Node, HTMLElement, NodeFilter) from the (client or server) application context instead of getting it directly.

There are various ways to share render components between client and server applications, such as publishing them in a package repository, but the most flexible would be to have the application package reference the module in the monorepo.

add interactivity

However, once HTML elements are converted to strings, all event handlers set on those elements are lost. In order to restore interactivity, you need some “hydration” steps, i.e. injecting scripts to execute them on the client side. Frameworks have a hard time doing this because of their ubiquity. Take Shadow DOM, they are constantly trying to improve their algorithms, hoping to do it in the smartest way, but if we narrow the problem down to the application level, it becomes a lot easier.

Of course, doing this in a normal server application also means injecting JS scripts into the response message (either by reference or inline, depending on how “progressive” you want to be, e.g. Embed the required code into the HTML response and let them execute on the client side).

The common solution gives you control over where, when, and what to attach: you can just send HTML, load basic interactive JavaScript, then load more (depending on what the user does), etc.

This is simpler than anything mentioned in this article because they are application code, not generic framework code.

globalization

For many years, internationalization issues were handled through libraries (and eventually integrated into frameworks as well). It’s also easy to integrate these libraries yourself, but you can also choose to implement one yourself, as your own implementation can support simpler and more efficient message types than a generic library.

Here is for you:

Type checking: Each message has a static type (and several translation implementations), so the IDE can check that you’re using a valid message property and provide you with autocompletion.

Translation sanity check: Failed to compile until translations in all languages ​​are provided for all message keys.

All you need to do is (load and) instantiate the message class related to the user’s locale. Generic libraries do not provide this business-specific message type.

tool

If you want to get rid of your reliance on a strongly constrained software stack, you probably also want to get rid of your tools: you don’t want them (their limitations, performance, bugs, versions) to be able to move forward . You don’t want to be stuck with a build issue that you can’t fix (or that takes hours or days to fix) (especially if you’re using recent builds that haven’t been fully battle-tested).

Having said that, it’s still hard to avoid using these tools. In most cases, your production code must be bundled in some way, including minification, obfuscation, code splitting, tree shaking, lazy loading, including styles, etc. No doubt existing bundlers like Webpack, Parcel, ESBuild or Vite will do a better job than you.

All you can do is:

Use as little translation as possible. For example, using TypeScript can be a good thing, but it introduces additional complexity that you must have tools in your toolchain to handle. The same goes for CSS, especially the latest versions, it’s not worth your while to process them with a preprocessor like Sass.

Use as few tools as possible. The more tools you use, the more likely it will go wrong or not meet your needs.

If you do need to use a tool, choose the most popular ones, as they are battle-tested and more likely to meet your needs (so you don’t get stuck in a “change needs or change tool” dilemma). Using the latest packaging tools too early may save you a few seconds of build time, but most likely none of that time is enough to understand tool documentation, deal with bugs, or deal with issues caused by lack of support.

the biggest challenge

At the end of the day, the biggest challenges are not technical, but people:

You have to get out of your comfort zone. Hopefully you’ll eventually be able to understand that it’s not that difficult to use common solutions, and the complexity of frameworks outweighs the benefits they bring. Also, you’re likely to see more new APIs (WebComponents, ES6 modules, proxies, MutationObserver…), and the web is more modern and powerful than you might think.

As for the others, you can try to convince them. They may be reluctant to do so because no one is willing to embark on a journey they have never tried before.

Others may tell you:

“You’re going to develop your own framework”: No, we’re going to develop an application, not a framework.

“You’re going to write more code”: maybe, but maybe not much (depending on how many dev libraries are used), as this needs to be compared to the framework’s boilerplate code. But either way, there will be less code to load.

“You’re going to keep reinventing the wheel”: Of course not. Not using frameworks is to not follow their predefined rules (configuration, lifecycle management, refresh mechanism, etc.), but we haven’t forgotten the DRY principle, we can (and should) still use battle-tested 3rd party libraries.

“You need to write more code for each function”: No, you can follow your own rules instead of using framework boilerplate code.

“No documentation to see”: There will definitely be no framework documentation (because there is no framework at all), but you still need to write application documentation. It’s worth mentioning that usage patterns help you automatically document your software design. You only need to care about the application’s code documentation, and if you use one more framework, you need to read one more document.

“There will be no constraints or patterns to guide developers”: No, if you do need constraints, nothing will stop you (you just need to define contracts).

“You’ll miss out on performance gains”, like the once hyped virtual Dom (now challenged, including from the Svelte or Aurelia frameworks): No, because it’s the framework itself that needs these “performance gains” (for generality) , not the application. Conversely, generic frameworks are more likely to miss some performance gains that can be achieved with custom code.

You are having this problem because you are not using a framework. Every problem (including bugs, delays, recruiting, etc.) is blamed for not using the framework. Because the experience of most developers is that frameworks are used for everything that works, not using them by default would be considered risky. This assumption is assumed to be true in the event of a problem, whether or not it is related to not using the framework. They forget that they have similar problems when using frameworks.

“We can’t find developers”: They’ll say it’s hard to find developers who can write pure JS code. This sentence is right and wrong. Because many developers (not to mention managers) will find themselves more accustomed to using frameworks. If they’ve never used or don’t understand basic web APIs, they might be intimidated by building a web application from scratch. However, if you want to develop high-quality applications, you should not go to this type of developer. Sure, it’s easy to find React developers these days, but you don’t just need React developers, you need good developers.

“You can’t get the same code quality as a framework”. Of course, frameworks or development libraries are usually written by experienced developers in the industry. However, the framework’s code is mostly related to framework-specific activities (component lifecycle, general refresh mechanisms and optimizations, tooling, etc.), not your application. Also, even with frameworks, you can still make bad designs and write bad code. The quality of the app is always more about the quality of the team than it is about the lack of a framework.

“You can’t get the same performance as a framework”: No, we can get better performance. Industry claims that frameworks employ complex techniques that “improve performance” are not discussed here, as they may be primarily used to address performance shortcomings of frameworks’ common solutions (such as virtual DOMs).

Develop web applications without any framework: is it possible

Without a doubt, the best performing frameworks are those that add fewer layers on top of normal code. The “optimization” of the framework is more to make up for the overhead of the framework itself.

in conclusion

Building a web application without a framework is not about building a framework yourself, it’s about developing an application without using a common engine to:

Avoid losing control and being implicitly bound (lock-in, upgrade costs, etc.);

Optimizations (performance, volume, design) can be made.

That is, only writing application-specific code (business and technical), including using development libraries. The framework you should really focus on is your own framework, the one that’s specific to the application. It’s truly “business-focused” and the most effective.

It’s not as difficult as you might think, especially with the support of modern standards (mainstream browsers can polyfill new features when necessary).

Posted by:CoinYuppie,Reprinted with attribution to:https://coinyuppie.com/develop-web-applications-without-any-framework-is-it-possible/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-03-27 11:02
Next 2022-03-27 11:04

Related articles