Why build another website builder?
makeswift.com
makeswift.com
> Can I host a Makeswift site elsewhere? > Makeswift code can't be exported. Every page created in Makeswift is securely hosted and served via Google Cloud.
I'm sorry, maybe I'm just being absolutist and cranky, but this doesn't sound to me like it's a 'website builder' - it's a tool that allows users to create presentations that can be displayed on the web.
I get why you'd go that route in the first place for 'non-coder' users, but locking them in to your ecosystem is, to me, antithetical to the culture of the web.
Of course - everyone does it, but it doesn't make it right.
I guess the reason we call ourselves a "website builder" is because Makeswift lets you build, well, websites. As for "presentations that can be displayed on the web", it's a bit more powerful than that. All components use to build Makeswift sites are React components and we are planning on opening that up so that third-party developers can create components any Makeswift user could drop in to their website.
As for lock-in, again, I think you make a fair point. In the long term we will probably have a self-hosting solution but it's something we're not focusing on at the moment. Most of our customers just want to focus on designing a website and then clicking a few buttons to have it live.
Thanks so much for your feedback :)
To really address that question, one needs to address the elephant in the room: wordpress. Thanks to over a decade head start, it's arguably the most advanced solution in the space. Wordpress and its ecosystem handle a myriad of business-focused things that make most attempts at React-based solutions look like toys. There are power user templates that let you configure pretty much every aspect of the site and then some, and if you want to defer, you can also find wordpress experts very very easily.
I'm being a bit facetious, but why would you need this if marketers can control everything already? :-)
Any React component is already a Makeswift component, the question is, how do you get the props? Well we've got a whole bunch of what we call prop controllers for basic stuff like numbers, colors, images, padding, margin, etc. You can also make your own. For example, in the Twitter feed component, you might make a panel that lets you search for tweets and then once you pick the account it passes the Twitter username to the component as a prop. The component can then fetch the tweets using the Twitter API, etc.
We have plans to open source all of our components as a reference for third-party developers building their own custom Makeswift components. Also, if you're a company that already has an internal design system built in React, your marketing team can just drop those in to your Makeswift site (constrained by the props the developers decide to expose).
This is all internal right now, though. I can't wait until we can release this API to the public, haha.
The lock-in here is created by a clever use of the word "Web." It's the same use that allowed marketers at Netscape to call LiveScript JavaScript because it would sell better by bandwagoning on Java. We all know how that went: decades of new users confusing JavaScript and Java. The same mistake is made here by confusing users betweent Makesswift and Swift!
The Web Remembers!
I didn't realize that all these services are actually presentations and not websites. Whatever that means.
The value of a tool like this without the backend and infrastructure is minimal. If you need to setup your own host and generate new HTML/CSS every time you'd like to update the site, the market for this product drops close to zero.
l.o.l.
We're a small team of 5 right now, though, and decided to focus on the core experience right now.
Although Shopify does allow you to export your webite too - it just won't be able to do very much used elsewhere, without the Liquid-supporting back-end! :)
Not all of this is exposed just yet, which is why we're in early access. But a Makeswift site couldn't be further away from a "presentation builder".
That being said, it does seem the way we're presenting ourselves leaves much to be desired. So I appreciate you pointing that you!
Most of the solutions out there either are stunted by no-code workflow that severely limits what you can do (ala Casio), or are code-behind solutions that are poorly engineered, fragile, and require deep platform knowledge and far too much coding to accomplish simple tasks (ala Alpha).
Zoho Creator is the happy medium, but it's cludgy, badly organized, has terrible support, missing key functionality, and its engineering choices are mind-numbingly stupid.
We need an Access for the web, but nothing comes close.
(I made it, so feel free to ping me if you have any feedback: david AT retool)
We've spent a lot of time thinking about the right architecture to pull this off. Today, we're focusing on removing bottlenecks for marketers so that they can build beautiful websites with flexibility, fast. So because of that we are making all the components ourselves. In the future, though, we expect most components to be built by other people.
Have you looked at PHPMaker?
Static files are stored in S3 and served by cloudfront. API endpoints are served by AWS Lambda, so it's quite fast and scalable.
It's also supporting advanced features like SSR and translations.
It's a low code solution, easy to use for non coders, and full access to source and advanced backend features for devs.
Disclaimer: I am the CTO ;)
Documentation: https://support.appdrag.com/
> We need an Access for the web, but nothing comes close.
You're using ASP.NET terminology (code-behind) and implying that Access was some sort of DB revolution on the desktop.
About time to get out of your bubble.
As for my "bubble," stop being so judgmental. You have no idea what my background is. I'm primarily a Python dev, specializing in systems integration.
The question should be: Why don't we create a website builder focused in web performance?
I've seen this pain first hand when I "rescue" clients from DIY website builders or am forced to use one myself. It remains one of the main reasons our clients graduate from DIY solutions to working directly with a professional. How are your templates (https://www.makeswift.com/templates) different?
By putting the abstraction layer, even with templates, at the component level instead of the page level like most builders do, we believe that all of these pain points Alan mentions in the article will be solved. The component you're using should be flexible enough to modify to your heart's content. And if it isn't, you can just find a third-party component to satisfy that. And if that component exist, then you should be able to make your own by just writing some React (or Vue, etc.), not interfacing with some bespoke API.
And becase these components compose, there shouldn't be a need for a "rescue". That's the vision.
I would love a website builder that has Drag Drop CMS capability for non technical users (kinda like page builders in WordPress) but allows clean static HTML export finally (kinda like static site generators). The problem is we either have the WordPress or static site gens.
We believe there is an opportunity to build a website builder that is much more flexible than the usual template-driven ones, but not as complicated as Webflow. I would say Makeswift is to Figma like Webflow is to Photoshop.
-Output accessibility (eg for blind users)
-Clean and efficient output html (every square space site I visit is slow as shit)
-No cdn resources. Allows you to pack your own fonts and assets.
Does this do that?
This is something that's in our roadmap. Makeswift components are just React components and as only developers of those components at the moment we plan to follow accessibility best practices.
>-Clean and efficient output html (every square space site I visit is slow as shit)
Again, because the components are just React components, it's a matter of keeping markup clean in the components themselves. This is something that I think we could do a better job at right now. But we will definitely improve and there's a clear path for it.
-No cdn resources. Allows you to pack your own fonts and assets.
We're currently focused on delivering a great out-of-the-box experience so we take care of that for all of our customers. In the future we plan to open up an API that will allow developers so extend Makeswift however they see fit, including writing their own components, panels, and integration with assets, etc. This would allow you to pick your own custom fonts and assets.
That being said, today we do support custom snippets that you can add to your pages as well as an Embed component. With these you can bring your own "anything".
I would like to add:
- good multi-language support
That being said, I'm proud to currently have customers that have built sites in over 5 different languages, that I know of.
We're constantly iterating on the product so some of the UX and visuals in the videos might be outdated, but the core is the same. We'll be updating these soon!
With what seems like a new website builder popping up every week, I'm often asked the same question. Why build another one? Here's my answer.
We're starting to invite people to our early access program and would love your feedback.
Especially now that I’m over 40, the important of contrast can’t be overstated yet right now everyone seem to be competing on how many barely discernible shades of grey they can have layered over their sites and content.
Lots of good common sense guidance in there - and it’s freely available/useable to all.
My main question is: does this let you output html+js so that I can upload it on any other site, or does the site stay hosted on your site?
Looks neat, btw.
And thanks!
Quick feedback, it seems you forgot to answer the question "Why build another one" before submitting your comment, I'm still awaiting your answer :)
Cool project. So do you mind actually answering the question of _why_ building another one? Just curious.
Or is that not extensible enough?
Wix's current editor is based on fixed position (think photoshop / illustrator). This approach works great for banners, graphics, icons etc, but is inherently at odds with web design. The solution for fixed position builders is to hardcode breakpoints, but there are too many devices. It's better to just design a UX around the box model, as that's how we code for the web anyways.
Editor X has potential but there's a little too much magic happening in the layout for my taste.
These are just a few of the many pain points. From our research, companies rarely keep using Wix / Squarespace after a certain stage. I personally haven't tried scaling a Squarespace or Wix site, but I also have never gotten them to a point where I was happy with all of the details before deciding to just code it myself.
So, it's not a fully responsive templates, but they are good enough for most websites.
This is actually not part of the core Makeswift code, but a custom snippet we added to this blog post to tweak the navigation. It sets a class on scroll, which is why you saw so many errors in the console.
I just fixed it. Thanks for letting us know!
- Squarespace/Shopify may seem like "website builders", but the bigger play is to manage parts of online business (transactions, reservations, point of sale, etc.), and ultimately everything. "Website builder" is just an entry point.
- Online presences need to manage multiple web properties (i.e. a restaurant = yelp, tripadvisor, facebook, etc.). And lets be real, a restaurant can just redirect their domain to whatever the hottest social platform is (chances are it's going to load faster).
- Websites aren't the only channel anymore.
Website builders are commoditised imho, and have no value as a pure tool.
Another reason I think WeBase is unique is that it also supports custom data models (think Airtable) that you can integrate with a website which often requires multiple tools with other platforms.
Even in mature markets there can be great opportunities for innovation.
All the best with Makeswift!
It's quite impressive.
At least if I understand you correctly to mean the cartoony faceless curvy people.
Squarespace and Wix are great for people who want to set up a template, skin it, and forget it. Their focus on wizards and templates optimizes the user experience for beginners, but at the cost of flexibility for advanced customization. There are a lot of people that this makes sense for.
Makeswift is designed for opinionated people who are constantly tinkering with design, layouts, and new ideas, but don't want to climb a giant learning curve. We're focusing on making a generic, flexible user experience with composable components that doesn't have opinions about how you build your pages.
From your comment and article it seems you're focused on marketing teams rather than a general purpose website builder. It would be great if you communicated this in your homepage. I know a couple of marketing teams using WP just to use themes and building landing pages.
Maybe if it was marketed as a "fast prototyping" tool, I'd be more on board with the product.
If the issue is maintainability once the website has been extended (i.e., with custom code and integrations), then it's all about _that__ experience. I think in those cases, the mistake is to come up with some sort of bespoke abstraction that the developer now has to learn and that is different from everything else they're used to.
With the way we've designed Makeswift, once we open up extensibility, you'll just use regular old code (e.g., React, Vue, Angular components, or plan HTML and JS), in a repository that's version-controlled, that lives with the rest of the code.
To make that a bit more concrete, today, Makeswift components are just React components. So Makeswift's API is just passing props to your component. That's what we plan to open up eventually.
I had nursing students, high school grads, history majors, and a heroin addict make a html/css page.
Sure it was wrapped in my header/footer, but this means 1 front end developer, once.