<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: GrumpTech</title>
    <description>The latest articles on DEV Community by GrumpTech (@grumptech).</description>
    <link>https://dev.to/grumptech</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4112309%2F8eb65904-d9f6-4e5d-a57f-2258c3ab366e.png</url>
      <title>DEV Community: GrumpTech</title>
      <link>https://dev.to/grumptech</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/grumptech"/>
    <language>en</language>
    <item>
      <title>Revolutionizing frontend development</title>
      <dc:creator>GrumpTech</dc:creator>
      <pubDate>Fri, 25 Sep 2026 07:11:35 +0000</pubDate>
      <link>https://dev.to/grumptech/revolutionizing-frontend-development-5912</link>
      <guid>https://dev.to/grumptech/revolutionizing-frontend-development-5912</guid>
      <description>&lt;p&gt;Have you ever felt that a large part of frontend development is repetitive work? Building forms, creating tables, connecting fields to API endpoints, adding validation, and handling loading and error states. Creating detail pages, list views, filters, navigation, and all the other pieces needed to turn an API into a usable application. And then doing it all over again for the next project.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;What if we could change that?&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Imagine building a set of reusable frontend components once: forms, tables, dashboards, navigation, search, filtering, validation, and more. Instead of manually building the frontend for every new application, you simply generate it from an OpenAPI definition that describes your backend. In this article, we explore a solution built on top of &lt;a href="https://formly.dev/" rel="noopener noreferrer"&gt;Formly&lt;/a&gt; that can transform an OpenAPI definition into a customizable frontend application.&lt;/p&gt;

&lt;p&gt;&lt;strong&gt;The idea is simple: build the components once, define your API, and generate the frontend application automatically.&lt;/strong&gt;&lt;/p&gt;

&lt;p&gt;Do you think it’s possible? You can try it now.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Temporarily add &lt;a href="https://grumptech.github.io" rel="noopener noreferrer"&gt;https://grumptech.github.io&lt;/a&gt; to your backend’s CORS configuration.&lt;/li&gt;
&lt;li&gt;Navigate to &lt;a href="https://grumptech.github.io/demos/formly-designer/material/open-api-client" rel="noopener noreferrer"&gt;https://grumptech.github.io/demos/formly-designer/material/open-api-client&lt;/a&gt;.&lt;/li&gt;
&lt;li&gt;Enter the base URL of your backend.&lt;/li&gt;
&lt;li&gt;Enter the URL of your OpenAPI definition.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Save the settings and see what happens. You will see how an OpenAPI specification is transformed into a functional frontend without manually building every form, field, and API interaction. Of course, a production-ready application will require some customization. Labels may need to be refined, descriptions added, and the client might request custom components for specific use cases.&lt;/p&gt;

&lt;p&gt;You can customize the generated application using the Formly Designer:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Navigate to &lt;a href="https://grumptech.github.io/demos/formly-designer" rel="noopener noreferrer"&gt;Formly Designer&lt;/a&gt;.&lt;/li&gt;
&lt;li&gt;Go to File → Import → OpenAPI 3.0 app and select a file with your OpenAPI definition.&lt;/li&gt;
&lt;li&gt;Go to File → Save All.&lt;/li&gt;
&lt;li&gt;Use the editor to customize labels, add descriptions, and choose different components.&lt;/li&gt;
&lt;li&gt;Navigate to the newly created &lt;a href="https://grumptech.github.io/demos/formly-designer/material/app" rel="noopener noreferrer"&gt;app&lt;/a&gt;.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;This gives you a functional frontend as a starting point while retaining the flexibility to tailor it to the specific needs of each application.&lt;/p&gt;

&lt;p&gt;For a sample application and a practical guide to creating your own custom components, check out the &lt;a href="https://github.com/GrumpTech/formly-designer-sample#formly-designer-sample" rel="noopener noreferrer"&gt;Formly Designer sample&lt;/a&gt;.&lt;/p&gt;

&lt;h2&gt;
  
  
  What do you think?
&lt;/h2&gt;

&lt;p&gt;Give it a try and let me know what you think. What worked well? What was missing? Whether you have a feature request, a use case, or simply an idea for where this could go, I’d love to hear your feedback.&lt;/p&gt;

</description>
      <category>lowcode</category>
      <category>productivity</category>
      <category>webdev</category>
      <category>angular</category>
    </item>
    <item>
      <title>The false choice between low-code and pro code</title>
      <dc:creator>GrumpTech</dc:creator>
      <pubDate>Wed, 16 Sep 2026 19:00:01 +0000</pubDate>
      <link>https://dev.to/grumptech/the-false-choice-between-low-code-and-pro-code-262n</link>
      <guid>https://dev.to/grumptech/the-false-choice-between-low-code-and-pro-code-262n</guid>
      <description>&lt;p&gt;For years, low-code has been positioned as the future of software development, with predictions that it would eventually replace traditional coding. The reality has proven different: low-code has partially changed how we build software, but it has not eliminated the need for professional developers.&lt;/p&gt;

&lt;p&gt;Traditional software development involves a great deal of repetitive work. Developers frequently spend much time building standard CRUD functionality, forms, workflows, and integrations instead of focusing on the complex business problems that create real value.&lt;/p&gt;

&lt;p&gt;Low-code platforms often lack the flexibility required for complex business logic. While they attempt to provide that flexibility through visual programming languages, these languages still impose constraints compared to traditional software development. As a result, professional developers often spend significant time implementing business requirements within the constraints of a rigid low-code platform.&lt;/p&gt;

&lt;p&gt;The real opportunity is not choosing between low-code and pro code, but combining the strengths of both. Low-code can accelerate the development of standard application components, while professional code provides the flexibility and control needed for complex requirements.&lt;/p&gt;

&lt;p&gt;An ideal approach should offer:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;A clear version history and source control.&lt;/li&gt;
&lt;li&gt;Flexibility to easily adjust and extend applications with pro code.&lt;/li&gt;
&lt;li&gt;No vendor lock-in through open standards and full access to the underlying code.&lt;/li&gt;
&lt;li&gt;Accelerated development of standard functionality, such as CRUD functionality, forms, workflows and integrations.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;Try &lt;a href="https://github.com/GrumpTech/formly-designer-sample#formly-designer-sample" rel="noopener noreferrer"&gt;Formly Designer&lt;/a&gt;&lt;/p&gt;

</description>
      <category>lowcode</category>
      <category>coding</category>
      <category>angular</category>
    </item>
  </channel>
</rss>
