loading...
Cover image for A New Way to Build and Share Code

A New Way to Build and Share Code

ashevat profile image Amir Shevat ・6 min read

You have a brilliant idea for a startup. You meet with an awesome person you know from college, who gets so excited that she asks to join you as a co-founder. You are about to change the world!

You get an amazing initial spec that your partner has written, mocks and all. She hands you the doc and asks "How long will it take you to build this?”. The pressure is now on you, considering it took her only 2 days to write this spec. You shrug and say, “I think it will take me 6–8 weeks to build a prototype.”

Now, it’s actually time to build the prototype. It’s also where the problems start.

1) Sharing is broken because we share dead code, not live components.

You start with the frontend and pick React as the framework. React has a rich components ecosystem, so the first thing you do is explore that. Searching for the right components is a pain, because you need to install the components locally in order to experience them and see if they are the right fit. Several components are actually not what you were looking for, and you only find this out after you NPM install them. Some friendly developers go out of their way and set up a demo site for their components, but most do not. It is frustrating to find the right experience because GitHub gives you the ability to browse the code, not to experience it. GitHub Pages try to solve this issue, but that solution is limited - It does not provide a solution for frontend components that rely on a backend or a database.

GitHub is an awesome code repository - but the sharing part is broken because you cannot try out the functionality.

Note how this friendly developer links to another site to preview the code.

A week later, after you have installed tens of UI components — you have a semi-working frontend, now comes problem #2.

2) Connecting frontend, backend, and data is a pain in the butt.

The functionality described in the spec requires a backend - some data to save, a user registration system, and other functionality that needs to be run securely on the server.

You need to decide which cloud provider you are going to use — Firebase and Heroku are on the shortlist. You need to create your backend project scaffolding, and do a lot of plumbing. Setting up the backend takes hours, if not days. Connecting your frontend and backend makes you feel like a plumber fixing a clogged toilet. Welcome to a new world of pain.

But the fun just started, now comes data! You need to configure the datastore, build the schema, set permissions and connect it to the backend and frontend. You start wondering why you even started this project in the first place?

Firebase and Heroku are powerful backends, but the building experience is broken and require tons of plumbing, configuration, and setup.

This is what comes up when you Google “AWS — 3-Tier Web Application”

Finally, 3 weeks later, you finish all the plumbing and have a (semi) working prototype. Now comes the biggest problem, it’s only a freaking prototype!

3) Scaling is hard and moving from prototype to production requires rewriting almost everything.

Your co-founder loves the prototype and the investors are happy to shower you with dollars. It is time to go to market, now your prototype needs to scale to tens of thousands, if not millions of users, who are eager to pay you for your service.

“But wait!” you exclaim to your partner, “this is just a prototype”. You know from experience, that prototypes are just that, an example of what can be. Definitely not production ready.

Most prototypes are designed to be thrown away because they are not built for scale — they are built to prove a concept.

What if it could be different?

What if the story didn’t have to go this way? What if we could share and build live code examples that dissolve the boundaries between frontend, backend and application data? What if we could start from a working template that is already designed for production and scale?

At ShiftJS, we are changing the way code is built and shared. Here’s how we are accomplishing that:

  1. A simpler way to build backend code — we enable developers to write backend code directly inside their frontend project . With this model, developers call backend functionality as if it were a local function call. At build time, we automatically replace the function call with HTTP requests and deploy the backend code, without the need for configuration.

  2. Live templates — we let developers start from a working template that has already been built for scale. These open-source templates, have pre-configured plumbing, and are ready to use out of the box. Think of these templates as web app starter kits - they are live, and developers can play with them, until they find the right template. At the simple press of a button, developers can remix code, we will clone and provision a new cloud environment for the developer, with the template pre-installed. Now, developers just need to download the code and make their desired edits. At any time, they can deploy their version into the cloud with zero configuration.

  3. A directory of live components — we envision a world where developers share end-to-end components that span across frontend backend and data. Imagine a React component that is already connected to a live backend. Developers will be able to build, modify and share these components and utilize them in their projects.

A new future

Let’s rewind the story, and play it back the way we envision it:

You have a brilliant idea for a startup. You meet with an awesome person you know from college, who gets so excited that she asks to join you as a co-founder. You are about to change the world!

She hands you a great spec and asks you how long will it take you to build it. You answer “6–8 days”.

Together you go into ShiftJS.com and browse through a directory of thousands of templates. Each template is a live experience with working frontend, backend, and data. Each of them is open source, but more importantly — you can experience the code live!

You should be able to play with a live end-to-end component before you use it.

You and your partner pick a template that is closest to what you want to build, it has a login, image gallery, and social components. After playing with it, you are convinced that with a few tweaks and some branding, this will be a killer proof of concept. You click “remix” and the system clones the frontend, backend and sample data, resulting in an environment of your own. The best part? No plumbing is required — everything is already connected and working. It also comes with an automatically-allocated URL that you can share, with a designer for example.

Next, you download the source code. The template is simple and well documented. The frontend code is seamlessly integrated with the backend code and the data access layer is easy to use. You make the necessary changes, and you are almost good to go. As a last step, setup your custom domain. Now you have a working prototype!

There’s only one magical detail we haven’t covered yet— your prototype is scalable by design. No need to throw it away after your co-founder and VC fall in love with it.

“We are ready for 10 millions users, even if they all come tomorrow morning :)”

Wouldn’t that be an awesome future? This is what we are building in ShiftJS — a platform where developers build and share live end-to-end components, working together to build a more productive and scalable future. Because, at the end of the day — you have a brilliant idea and you are going to change the world.

Join our beta

Posted on by:

ashevat profile

Amir Shevat

@ashevat

I build developer platforms. I have done so at Microsoft, Google, Slack, and Amazon and now my own at shiftjs.com

Discussion

markdown guide