Change commit author date

git commit --amend --no-edit --date="Wed Mar 30 22:45:55 2022 +0200"

Get last commit to modify file

git log -n 1 --format="%H %s" -- path/to/file

Get first commit

git log --reverse --format="%H %s" | head -1

Find commits with modified code matching some string

git log --branches -S'some code you need to fix'

Find commits with modified code matching some regular expression

git log --branches -G'some code you need to fix'

Create a commit message with a trailer

git commit -am 'add something' --trailer="Molecule: apiPackageManager=NPM, apiLanguage=TypeScript"

Find dangling commits

git fsck --lost-found 2>&1 | grep "dangling commit"

Wipe unused history

git for-each-ref --format="delete %(refname)" refs/original | git update-ref --stdin
git reflog expire --expire=now --expire-unreachable=now --all
git gc --prune=now --aggressive

Remove untracked files and directories

git clean -f -d

Delete all remote branches:

git branch -r | grep origin/ | grep -v 'index$' | grep -v HEAD| cut -d/ -f2 | while read line; do git push origin :$line; done;

The demand for software engineers is higher than ever, and it grows by the day. Custom software provides immense benefits to businesses and their customers. It is a necessity for most businesses to keep up with the modern world.

If you've kept up with software progression over the years, you've probably noticed a pattern emerge where we repeatedly recreate the same things in different ways, often using different technologies, languages, tools, platforms, and paradigms. The primary reason for this repetition is that software (mostly) exists to fulfill human needs, and we've grown to expect certain functionality from the software that we use. We almost always log in. Sometimes we want to be notified. Businesses need to be paid, and the easier it is for customers to do that, the better. It takes significant amounts of time and effort to seamlessly integrate all of these things into the custom software that powers businesses.

It's impossible to know the exact percentage, but it's safe to say that at least 50% of software projects fail. Various sources report failure rates ranging from 25% to 80%. The common theme behind these failures is a lack of time. Developers everywhere routinely underestimate the amount of time it takes to build quality software. Much of the reason for this comes down to a lack of experience, unclear requirements, and/or factors beyond their control.

To be competitive in today's markets, you will need to integrate with third party services and platforms, each with their own sets of requirements and restrictions which evolve over time. You have no control over any of this. It can take a very surprising amount of time to properly integrate these systems.

Nowadays, we have a myriad of amazing libraries, tools, and services we can use to make development easier, but we still spend entirely too much time manually integrating them to produce the result that we really want, things that are actually functional and useful, complete with all of the integrated functionality that users have come to expect. Many example git repositories and app starter kits are generously available, but they are all very limited in what they do. They all still require a lot of work to turn into something that meets real world needs.

Are millions of developers really going to continue reimplementing the same integrations for systems and functionality that we know we need? I don't think so, but collectively, we're not quite there yet. We've refined our tools. Some systems and best practices have solidified. These things are not going anywhere for the forseeable future, so why not take the next step and reduce the time and cost of integration to almost nothing? This is the problem Molecule.dev aims to solve.

Our approach is based on tools and workflows already used on a daily basis by developers everywhere. The goal is to instantly produce the kind of output that teams would expect if they themselves implemented it over months (or years) for their specific stack and requirements. The result is something that developers have full control over, without the need to learn (or be locked into) some elaborate framework or wait on someone else to implement any extra functionality they need in the form of issues, forks, and pull requests. (Some functionality could certainly be packaged and installed as dependencies, but that is a discussion for a later date. Molecule.dev primarily provides the glue between all of your dependencies and integrated systems.)

You can check out what we have so far and instantly assemble full-stack applications using any combination of TypeScript, JavaScript, React, PostgreSQL, Capacitor, PWA, Android, iOS, macOS, Windows, Linux, Styled Components, themes, typical user authentication, OAuth (Google, Twitter, GitHub, GitLab), push notifications, Stripe, Apple Pay, Google Pay, emails, file uploads, unit tests, documentation, logging, and deployment. The resulting fully functional app is capable of being published to app stores within the same day, after some minor setup.

99.9% of it is free and open source with an Apache 2.0 license, and there is a lot more in the works. Once we've made it even easier to add more options and integrations, it will be opened up to contributors. Long term, the goal is to provide a tool which skips all of the most boring and tedious system integrations, while combining all of the most popular tools and libraries, so that developers can focus on building what really matters.

Thanks for reading!

What would you say professional software engineers do? The job usually involves a lot more than writing code. Meetings. User feedback. Bug fixes. Design decisions. Choosing the right tools. Cost-benefit analysis. Team building. Delegation. The list goes on.

The job can vary significantly, depending on the role and level of experience, but at the end of the day, it all comes down to producing code which solves real problems and meets business needs. The effective output of software engineering can be measured as code committed, not by the number of lines or even the number of commits, but by the problems solved, features added, and systems integrated.

If you're a professional software engineer, there's at least a 99.99% chance you know what Git is, and you probably use it almost every day. The tangible work you produce is typically a series of Git commits and branches. The end result is the current version of your application.

What if you had a way to skip all of the time-consuming integration work, a way to pick and choose exactly the commits you need to produce your desired application? That is exactly what we're doing here.

Almost every user-oriented, data-driven app in existence shares much of the same core functionality, especially today, as users have grown accustomed to features like two-factor authentication, receiving emails, push notifications, dark mode, in-app payments, biometrics, cross-platform support, and everything else. For any serious application, users tend to expect all of this functionality at a minimum, and it can be extremely time-consuming to integrate all of it on your own in a manageable, extendable way, specific to your stack. Why should developers everywhere spend their time reinventing the wheel, over and over again?

Tools and technologies improve, standards change, and sometimes it is necessary to upgrade your stack and your codebase to keep up, but overall, the core functionality remains the same. Our mission with Molecule.dev and its open source tools is to give developers everywhere a way to skip reinventing the common core functionality and jump straight to customizing and building what really matters, without being locked into a single particular paradigm or ecosystem. Ideally, you'll be able to instantly add, remove, swap, and upgrade features, platforms, and maybe even eventually entire languages, and it will all work exactly as expected. (You can already do this with the current options!)

Introducing mlcl

To help make all of this possible, we've developed a command line tool called mlcl. It is designed around patterns and conventions already integral to nearly every developers' daily workflow, regardless of language or platform. Many of the commands resemble git commands, as it mostly uses git under the hood.

Choose combinations of the most popular battle-tested libraries, platforms, and features, depending on your individual needs, and mlcl generates your fully functional codebase by cherry-picking a series of carefully crafted commits from various branches, relevant to your selection.

While it initially produces very framework-like results, the output is not a framework. It is not limited to any single way of doing things, and you have full control over every line of code. Obviously, some structure and opinion is required, but we try to remain as agnostic as possible. The end result is a composition of well-defined, pure functions.

The biggest upside to the cherry-picking approach is that there is no need to devise some elaborate framework with a plugin system or anything like that. All that is necessary is good code and modular git commits.

Another upside is that every line of code has a purpose. There is no extra theoretical code or bloat for you to sift through. What you see is exactly what you get. The surface area is exactly as large as you need it to be, which helps you maintain a simple, predictable mental model.

How does it work?

A few approaches were considered before finally settling on the simplest one, which works with no extra setup and relies only on git.

Git has a handy feature called "trailers", which is just a line (or lines) of text at the end of git commit messages. Historically, only a Signed-off-by trailer was officially supported by using the --signoff (or -s) option, but a --trailer option was added roughly a year ago (since version 2.14) to officially support any trailer. (For older versions, you can manually add the line(s) in the proper format.) These trailers provide useful information about commits. For example, GitHub looks for a special Co-authored-by trailer, which allows you to attribute a commit to multiple authors, visible within GitHub's UI.

For codebases designed to work with mlcl, we use trailers to specify the language, library, platform, and/or feature relevant to the commit.

For example, we'll run a git commit command with messages and trailers which looks something like this:

git commit -m 'enable user authentication' --trailer Molecule='appLanguage=TypeScript, appRenderer=React, userAuthentication=Typical'

See more Take a look at the commits throughout the various branches of molecule!

Each mlcl branch is created (as necessary) as object-hashes of the various combinations of selections. This means that as we add more options, the number of potential branches will grow exponentially. It also means that if you make the same selection as other people, you will clone the same branch when starting out.

It doesn't really matter which branch the original commits are in. There are only two requirements:

1. The author date for each commit must be in the necessary (working) order.
2. Each integration should be developed on its own, ideally within the branch for the minimal feature set. For example, for payment platforms, Stripe, Apple Pay, and Google Pay each have their own branch. If multiple are selected, they will be automatically combined together during assembly.

Note Developers building on top of the resulting codebase(s) don't have to worry about any of this. You can build your app and commit your code however you want, unless you want to eventually make your own contributions. More on that later!

To assemble every codebase, mlcl runs a fairly complex git log --grep operation to find (and sort) all of the relevant commits for your selection, and then runs git cherry-pick for each one with custom Git merge drivers to automatically resolve any conflicts.

We're currently using only two custom Git merge drivers - one for JSON, and another for all other files using git merge-file's built-in --diff3 and --union options. We'll add more drivers as they become necessary.

When writing code for various options, it definitely helps to have enough experience with Git to know how it will attempt to merge. On rare occasion, placeholder comments and static code boundaries are necessary, but overall, Git is really smart with how it merges every commit. There are also probably some linting configurations which would help enforce mergeable code. For example, cherry-pickable items in an array should each be on their own line with trailing commas.

It's also worth noting that the Git history of each branch is rebased (overwritten) on a regular basis, but this is necessary and expected, as the Git history itself is the result we're after.

This approach seems to work very well and produces exactly the code we want. It also has the added benefit of forcing us to write clean, decoupled, modular code, such that every feature and integration can be added, removed, and/or swapped using simple git commands.

What's next for mlcl?

At the time of this writing, mlcl is very specific to Molecule.dev. One of the short-term goals is to generalize it, refine it, and add more commands to make it easier to go back and forth between branches, checkout the necessary commits to add features and fix bugs, and apply changes to all other relevant branches. It already has all of this, but it can be much more user-friendly. There may also be a more efficient way to pick all of the commits at once by passing a custom editor to git rebase instead of cherry-picking one by one.

Right now, the public version of mlcl queries the Molecule.dev API for the relevant commits to cherry pick, but the next major version will include all of the following additional commands (pulled and polished from the version we're using internally):

• mlcl select --show

  Shows the current selection.

• mlcl select --feature=Value

  Selects the necessary branch for the specified feature(s), while leaving the other selections intact.

  For example:

  mlcl select --appThemes=Light
  

  mlcl select --appThemes=Dark
  

  mlcl select --appThemes="Light, Dark"
  

  Or multiple features at a time:

  mlcl select --appUi=Tailwind --pushNotifications=Enabled --paymentPlatforms="Apple Pay, Google Pay"
  

• mlcl checkout <hash>

  Checks out a known mlcl branch hash and updates the selection to match.

• mlcl rebase

  Rebases the selection's relevant commits onto the current branch.

• mlcl rebase --show

  Shows the selection's relevant commits which would be rebased onto the current branch.

• mlcl rebase --all

  Rebases every known selection's relevant commits onto their respective branches.

• mlcl rebase --show-all

  Shows every known selection's relevant commits which would be rebased onto their respective branches.

• mlcl rebase --all --continue=<hash>

  If for some reason the original mlcl rebase --all failed, you can continue at a specific hash to avoid having to rebase every prior branch again.

• mlcl rebase --all --feature=Value

  Rebases every known selection's relevant commits for the specified feature(s) onto their respective branches. Useful to update only the branches relevant to a specific feature (or features) so that no time is wasted rebasing unaffected branches.

• mlcl sync [remote]

  Synchronizes every branch with the remote.

Some other useful additions might be things like:

• mlcl find for quickly finding exactly where certain code originated.
• mlcl branch with an interactive human readable list of each branch's features to quickly go from branch to branch.
• mlcl backup to make quick backups of repositories, as the original Git history is overwritten regularly.

What's next for Molecule.dev?

The future isn't 100% certain right now, but I would like to think that this is the beginning of something that can seriously raise the bar for both developers and end users. The long term idea is not only to save developers insane amounts of time and costs, but to also improve the way we think about building software, making it easier and more accessible for everyone to build and use high quality applications.

The hardest part of building the underlying tech is done. It took much longer than expected, but you can now assemble fully functional full-stack starter applications with the most common features, integrations, and platforms, tailored to your needs. Now that the foundation is in place and it works (better than expected!), adding more options should be relatively quick and easy.

Eventually (hopefully sooner rather than later), Molecule.dev will have a marketplace and a job board.

• As a buyer: Imagine having a vast selection of features and integrations to choose from, where you can instantly add, remove, and swap each one, knowing that you're getting high quality code tailored specifically to your needs.
• As a seller: Whether it's a UI library, an icon pack, templates, a database, a CDN, anything really... you'll have a place where you can scale your work (which ultimately boils down to git commits, right?) to any number of buyers.

There is a lot of potential here, and refining these tools and practices is an endeavor worth pursuing. If you disagree, please let me know! I would love to hear your thoughts and feedback.

Stay in touch!

Keep up with weekly update digests by signing up via assemble.molecule.dev and enabling the newsletter.

Our goal is to revolutionize the way people think about building reliable, high quality software.

You can show your support with a monthly subscription or a license. If you cannot yet afford it, use Molecule.dev to build something awesome, something people want, and then subscribe or purchase a premium license via assemble.molecule.dev when you can.

Also be sure to:

• Share this blog post
• Follow @molecule_dev on Twitter
• Star all of our public repositories on GitHub

Thanks for reading!

In the case of modern front end engineering and React especially, you can reduce everything down to two simple concepts...

1. Rendering the current state
2. Updating the state

Realistically, it's a bit more complex than that. You'll often need to consider shared application state and internal component state. Updates can also occur asynchronously with potentially many different states along the way, possibly arriving at an unexpected state when there's an error or if the user aborts the asynchronous operation. You may also need to consider performance when rendering lots of data or animating complex scenes.

But when it all comes down to it, everything is just a function of state.

With that in mind, we have a couple of super simple React hooks that we use everywhere. Combined with a design pattern which we'll cover later in this blog post, it's hard to imagine needing much more for the vast majority of cases. We still use basic hooks like useState, useEffect, useMemo, and useRef as necessary, but as far as complex state management goes, the following two custom hooks are usually all we need.

useAsyncExtendedState

This hook works almost exactly like React's built-in useState hook, but with two additions. It's probably easiest to understand by example.

1. It includes an extra method to extend the current state.

   Define the State interface.

   interface State {
     foo: string
     bar: string
   }
   

   Use the hook.

   const [ state, setState, extendState ] = useAsyncExtendedState<State>({
     foo: `foo`,
     bar: `bar`
   })
   

   Setting state works as usual.

   setState({ foo: `Hello`, bar: `World!` })
   setState(state => ({ foo: `Hello`, bar: `World!` }))
   

   Or you can extend the state.

   // Set `foo` while keeping `bar`.
   extendState({ foo: `Hello` })
   
   // Set `foo` while keeping `bar`, as a function of the current state.
   extendState(state => ({ foo: state.foo.toUpperCase() }))
   

   Try not to abuse extendState. It exists to make your code more concise and readable when you're merging partial states many times throughout your codebase.

   It should become clear later in this article why we've decided to include extendState. (The API returns partial states for certain endpoints commonly used for every resource.)

   Tip With Molecule.dev, we try to give you as much control over your Molecule's code as possible. All of this code is open source, so you can quickly change it to suit your needs and preferences.

2. You can pass promises to both setState and extendState to asynchronously update the state.

   Suppose you have a function which asynchronously fetches data from your API and returns the data as the next state.

   const fetchState = () => API.client.get<State>(`data`).then(response => {
     return response.data
   })
   

   Alternatively, the promise may also resolve a function of the current state, similar to setState(state => ({ ...state })).

   const fetchState = () => API.client.get<State>(`data`).then(response => {
     return (state: State) => {
       return response.data
     }
   })
   

   Call the asynchronous function and pass the promise to setState. The state will eventually be set to the resolved value.

   setState(fetchState())
   

   Similarly for extendState, suppose you have a function which asynchronously fetches partial data from your API.

   const fetchPartialState = () => API.client.get<Partial<State>>(`data`).then(response => {
     return response.data
   })
   
   // Or a function of the current state
   const fetchPartialState = () => API.client.get<Partial<State>>(`data`).then(response => {
     return (state: State) => {
       return response.data
     }
   })
   

   Call fetchPartialState and pass the promise to extendState. The state will eventually be extended by the resolved value.

   extendState(fetchPartialState())
   

   Note: The setState and extendState functions accept promises, not functions. In other words, the usage is setState(asyncFunc()), not setState(asyncFunc). See this issue for more information.

usePromise

More often than not, when something is happening asynchronously, you'll want to display some feedback to the user.

This hook accepts any asynchronous function (i.e., a function which returns a promise) and returns a new asynchronous function wrapping the original, along with the state of the promise plus cancel and reset methods.

For example, suppose we want to fetch data from the API and display the current state of the request to the user.

Define the State interface.

interface State {
  foo: string
  bar: string
}

Define a function which returns a promise. In this example, we'll fetch API data and resolve it as State.

const read = (id: string) => API.client.get<State>(`things/${id}`).then(response => {
  return response.data
})

Pass the function to the usePromise hook.

const [ readThingRequest, readThing ] = usePromise(read)

readThingRequest contains the state of the promise plus a reset method, defined below:

interface PromiseState<T> {
  status?: `pending` | `resolved` | `rejected`
  promise?: Promise<T>
  value?: Awaited<T>
  error?: Error
  cancel?: (message?: string) => void
}

type PromiseStateWithReset<T> = PromiseState<T> & {
  reset: (keys?: Array<keyof PromiseState<T>>) => void
}

If you would like to initialize the readThingRequest state, pass the initial state as the second argument:

const [ readThingRequest, readThing ] = usePromise(read, {
  status: `resolved`,
  value: state
})

readThing has the same function signature as read. In other words, you'll call readThing(id) the same way you'd call read(id).

Initially, before readThing is called, the readThingRequest will be an empty object (other than the reset method) if an initial state was unprovided.

When you call readThing(id), the readThingRequest state becomes:

const readThingRequest = {
  status: `pending`,
  promise, // the promise returned by `read(id)`
  cancel, // a method to cancel the asychronous update
  reset
}

When the promise has resolved, the readThingRequest state then becomes:

const readThingRequest = {
  status: `resolved`,
  value, // the resolved value
  reset
}

If there is an error and the promise is rejected:

const readThingRequest = {
  status: `rejected`,
  error, // an instance of `Error`
  reset
}

If readThingRequest.cancel was called before the promise resolves, the readThingRequest state immediately becomes:

const readThingRequest = {
  status: `rejected`,
  error, // an instance of `Error` with the message passed to `readThingRequest.cancel`, if any
  reset
}

To cancel updates for the current promise, with an error message:

readThingRequest.cancel('Cancelled!')

To cancel updates for the current promise, without an error message:

readThingRequest.cancel()

Note: Cancelling only prevents the state update. The asynchronous function you've called will continue unless you have a way to stop it. For example, in our case where we're using axios for API requests, we would need to incorporate its cancellation methods. This is beyond the scope of this article though, as usePromise can be used for any asynchronous operation.

To reset the state entirely:

readThingRequest.reset()

Or if you want to reset a specific value (readThingRequest.error, for example):

readThingRequest.reset(`error`)

Or multiple (both readThingRequest.status and readThingRequest.error, for example):

readThingRequest.reset([`status`, `error`])

You may also call readThing(id) more than once, and in which case, the current readThingRequest.value will remain until it is overridden by the next resolved value. So if you would like to reset the value when refetching:

readThingRequest.reset([`value`])
readThing(id)

Note: If you're combining readThing with the useAsyncExtendedState hook, you probably don't care about readThingRequest.value. More on that below.

Combining the two hooks

The usePromise hook pairs especially well with the useAsyncExtendedState hook.

At the start of this post, I mentioned a design pattern which makes everything clean and predictable. We've been using it in the example(s) above, but now we'll make it more obvious.

API resources typically have a handful of their own routes, usually following a RESTful design with CRUD (create, read, update, and delete) methods.

Molecule.dev's core application code is structured such that each API resource has its own directory with an index which exports methods for each route.

Suppose we have an API resource called a thing with CRUD methods:

import { client } from '../../client'
import * as types from './types'

export const create = (props: types.CreateProps): Promise<types.SuccessResponse> => (
  client.post(`things`, props)
)

export const read = (id: string): Promise<types.SuccessResponse> => (
  client.get(`things/${id}`)
)

export const update = (id: string, props: types.UpdateProps): Promise<types.SuccessPartialResponse> => (
  client.patch(`things/${id}`, props)
)

export const del = (id: string): Promise<types.SuccessPartialResponse> => (
  client.delete(`things/${id}`)
)

We'll import these methods and use them with the useAsyncExtendedState and usePromise hooks.

As an example, let's create a component to read some thing by id and allow the user to update it.

First, let's cover some relevant type definitions.

Every RESTful API resource will have an id, createdAt date, and updatedAt date:

/**
 * The resource's properties.
 */
export interface Props {
  /**
   * Usually a UUID.
   */
  id: string
  /**
   * When the resource was created.
   * 
   * Usually an ISO 8601 timestamp.
   */
  createdAt: string
  /**
   * When the resource was last updated.
   * 
   * Usually an ISO 8601 timestamp.
   */
  updatedAt: string
}

Our thing resource will have a description property:

import * as resourceTypes from '../types'

/**
 * The thing's properties returned by the API.
 */
export interface Props extends resourceTypes.Props {
  /**
   * The thing description.
   */
  description?: string
}

Tip We've also defined types for every API request and response, which you can check out on GitHub.

For the sake of example, we'll create an Editor component with a predefined initial state and render the current state with an input for updating the description. An "Update thing" button will request an API update when clicked, extending the state with the response data, and we'll render a cancel button along with the current request status and error, if defined.

import React from 'react'
import { useAsyncExtendedState, usePromise } from '../../hooks'
import { update } from '../../API/resource/thing'
import { types } from '../../API/resource/thing'

export const Editor = () => {
  const [ state, setState, extendState ] = useAsyncExtendedState<types.Props>({
    id: `733e26aa-97ea-46d7-b4d4-e556a5f37d68`,
    createdAt: `2021-12-17T12:32:13.981Z`,
    updatedAt: `2021-12-17T12:32:13.981Z`,
    description: `This is a simple but powerful design pattern!`
  })

  const [ updateThingRequest, updateThing ] = usePromise((updateProps: types.UpdateProps) => (
    update(state.id, updateProps).then(response => response.data.props)
  ))

  return (
    <div>
      <div>
        {`Created thing: ${new Date(state.createdAt).toLocaleString()}`}
      </div>

      <div>
        {`Updated thing: ${new Date(state.updatedAt).toLocaleString()}`}
      </div>

      <textarea
        value={state.description}
        onChange={event => extendState({ description: event.target.value })}
      />

      <button onClick={() => extendState(updateThing({ description: state.description }))}>
        {updateThingRequest.status === `pending` ? `Updating thing...` : `Update thing`}
      </button>

      {updateThingRequest.cancel && (
        <button onClick={() => updateThingRequest.cancel(`cancelled`)}>
          Cancel update
        </button>
      )}

      {updateThingRequest.status && (
        <div>
          {`Request status: ${updateThingRequest.status}`}
        </div>
      )}
      
      {updateThingRequest.error && (
        <div style={{ color: `red` }}>
          {`Error: ${updateThingRequest.error.message}`}
        </div>
      )}
    </div>
  )
}

In case you missed it, the concise bit of code combining the two hooks is found on the button's onClick handler:

extendState(updateThing({ description }))

See it in action

(An interactive demo lived here on the original post. The CodeSandbox link below has the same example.)

This example is also available to play with on CodeSandbox.

Check out the source

You can find the code for these hooks on our GitHub here.

If you want to get started on an app and API using these design patterns, git clone the molecule repository. Thorough documentation and guides are included.

git clone https://github.com/molecule-dev/molecule.git
cd molecule
npm install

Conclusion

You can combine these two hooks to cleanly manage asynchronous state at any level throughout your app, for nearly anything you can think of.

These design patterns help you simplify your thinking and the code itself by separating concerns in a way that is predictably consistent and incredibly easy to manage and build upon. This naturally leads to both a better user experience and a better developer experience.

• Define asynchronous functions on their own.
• Asynchronously set or extend state with a one-liner, via the useAsyncExtendedState hook.
• To show the user the current state of any asynchronous operation, pass the async function to the usePromise hook and render the promise state.

We use this for everything throughout applications built with Molecule.dev - signing up, logging in, the users themselves, enabling 2FA, payments, subscriptions, plan changes, device management, push notifications... everything!

If you like this and want to learn more, check out our GitHub and get started building something of your own by cloning Molecule.dev's core TypeScript app and API. After installing Node dependencies, you'll be greeted with documentation generated by TypeDoc where you can dig into more internals and play around.

If you're a professional web developer, where you're an indie dev or a CTO, and you want to save months of development time on cross-platform apps, visit Molecule.dev to assemble a codebase tailored to your specific needs. You're guaranteed a rock solid foundation from which you and your team can scale with ease.

Also be sure to follow us on Twitter @molecule_dev for regular updates and more posts like this one!

We have many exciting things coming.

Molecule.dev exists because there are many incredible tools and services to choose from when building full-stack applications, and while they make our lives as developers much easier, it is often unpredictably time consuming to glue them all together in a way that meets real world needs.

Over the years, we at Fullstacked have built nearly every type of application under the sun. Every app is unique but almost always shares core functionality. Molecule.dev polishes this core functionality and provides the most solid foundation possible for whatever you need, saving months of development time, energy, and costs. It is the perfect fit for any project, designed for teams of professional developers of varying experience, whether you're a fledgling startup or an established brand.

The software engineering ecosystem churn that we've seen over these past decades is both intimidating and exciting. Libraries, tools, and services have come and gone, and it's only going to continue improving from here. Molecule.dev takes the best of them all and makes it insanely easy for you to jump straight to building your own unique features, immediately ready for release on every platform.

If you haven't already, check out Molecule.dev and assemble your own Molecule. If you're interested but not ready to dive in, you can submit your request without checking out. The direction we take Molecule depends heavily on your input!

We're adding and improving options every week, and we'll be writing often about engineering, design decisions, and inner workings, so keep an eye on this blog and follow @molecule_dev on Twitter for regular updates.