Why build another website builder?(makeswift.com)
makeswift.com
Why build another website builder?
https://www.makeswift.com/blog/why-build-another-website-builder
88 comments
Can this builder help me to create a minimalist blogging app which only has text and design in material ui?
This is just an ad disguised as an article.
Hey everyone!
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.
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.
Check out the US Digital Web Design standards. For example their discussion on color and accessibility is one of the best and easiest to share I’ve found: https://designsystem.digital.gov/design-tokens/color/overvie...
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.
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.
I clicked through the features and handbook. I wanted to test it out without an account but that option was not available.
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.
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.
No, it does not.
We do all hosting ourselves at the moment. As for trying it out, we're currently in early access and you'll need an invite code to use it but if you apply [1], you'll get one in your inbox pretty quickly.
And thanks!
[1] https://www.makeswift.com/early-access
And thanks!
[1] https://www.makeswift.com/early-access
Thanks for sharing your project, certainly looks like an interesting start!
Quick feedback, it seems you forgot to answer the question "Why build another one" before submitting your comment, I'm still awaiting your answer :)
Quick feedback, it seems you forgot to answer the question "Why build another one" before submitting your comment, I'm still awaiting your answer :)
Hi :)
Cool project. So do you mind actually answering the question of _why_ building another one? Just curious.
Cool project. So do you mind actually answering the question of _why_ building another one? Just curious.
I do think we need better website designers for lay-people. I have a couple key points I would want in a web designer.
-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?
-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?
Clean and efficient output is my biggest gripe with many of the current builders.
I would like to add:
- good multi-language support
I would like to add:
- good multi-language support
Internationalization is definitely a big one. It's a hard thing to do right for a website builder designed for non-technical people, though.
That being said, I'm proud to currently have customers that have built sites in over 5 different languages, that I know of.
That being said, I'm proud to currently have customers that have built sites in over 5 different languages, that I know of.
> -Output accessibility (eg for blind users)
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".
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".
Demo doesn't show responsive design, which is important for smartphones/tablets, etc.
You're totally right, this is critical. If you want to check out how we do responsive design, you can do so here [1].
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!
[1] https://www.makeswift.com/videos/designing-responsively
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!
[1] https://www.makeswift.com/videos/designing-responsively
Jerry from Walking Dead in the Request Access page?
Maybe.
Heh ;)
Probably did some stock photography gig back in the day and now it's come to bite him -- looks like an endorsement.
From https://www.makeswift.com/early-access:
> 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.
> 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 don't think you're being absolutist or cranky at all. I think there's valid reasons why you would want to export your site.
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 :)
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 :)
> 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
I'm being a bit facetious, but why would you need this if marketers can control everything already? :-)
I'm being a bit facetious, but why would you need this if marketers can control everything already? :-)
Hah, all good. We give them _visual_ control of everything. But say you wanted to make a component that pull the last 10 tweets from an account or a Stripe Checkout button or some other custom component, then you can.
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.
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.
Dumb question. Does React matter in using the service - like an advantage of something like wordpress or shopify?
It will give us the opportunity to let developers build their own components, allow us to use frameworks like Next.js to power our users' sites, and let us leverage the ecosystem to build cool components and integrations. So as far as the end-user is concerned this should result in better performance, more options for components, and easier extensibility if they are developers.
This might be a sticking point to adopting your service for some stakeholders, not so much because they actually need to export the website anywhere but because the business model of so many website builders seems to be 'regret'.
Yeah, that's a no from me, dawg.
I'm reading through the first half of the article, which mostly tells some story about how a pain point might turn out, but I don't feel like that's really answering the "why _another_ website builder".
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.
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 consider Shopify a website builder, but I can't export my website to other hosting services.
You could use their APIs to pull your product catalog out, but IIRC their terms of service says that's not allowed if you're migrating to another system.
l.o.l.
l.o.l.
Yeah, you can't do that right now. But we do have plans to support self-hosting. We believe it will be table stakes for various customers.
We're a small team of 5 right now, though, and decided to focus on the core experience right now.
We're a small team of 5 right now, though, and decided to focus on the core experience right now.
Bit confused reading this, thread was talking about Shopify. (Other confused readers: parent's profile says they work at Makeswift, the site builder in OP.)
I mistakenly replied to the incorrect thread hah. Sorry for the confusion!
Good point, although Shopify does solve a very specific problem that's beyond the realm of basic front-end HTML sites.
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! :)
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! :)
Also Wix, Squarespace, and Weebly.
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.
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.
Shopify has a Shopify website builder.
No, you are right on. It's really a bespoke to techstars_ solution for Google Cloud. When I think I web, I think HTML and HTTP and all the resources that can be accessed under those two. Note, the web can also be SFTP and a plethora of other resources.
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!
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!
Javascript could interact with, script if we are being charitable, Java applets through LiveConnect.
I am not the most educated person on the matter, but I think there is an argument to be had about what constitutes a "website" and what is just a "multi-paged presentation" or even a "multi-paged advertisement" that is hosted on the web. I can imagine that even certain presentations can foster more intrigue and be more informative than just a place online that supports brands, products and services. I wish I was more well-versed on the history and principles behind the web so that I can express myself better, but I am quite unnerved by this service and how it presents itself.
I agree that there's a clear difference between the two. Makeswift sites aren't just a "presentation", though. They're hybrid (server-side rendered on first load and client-side rendered after) React apps. And because of that you can have components that do all sorts of things a "presentation" can't do. For example, you can pull in data from third party APIs, you can build dynamic UIs with dialogs, you can animate components, you can submit forms, etc.
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!
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!
[deleted]
Hey guys, I'm super excited about early access so that we can gather as much feedback as possible. We made a nifty handbook [1] a while back to show the basics of building a page in Makeswift. Would love to hear what you think!
[1] https://www.makeswift.com/handbook
[1] https://www.makeswift.com/handbook
So is it like a WebFlow competitor ?
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.
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.
I built one that does exactly that: http://luminaldev.com
You could say Webflow is a direct competitor, yes. The way we see it, though, Webflow is a tad too complex for non-technical users and you end up just shifting the bottleneck from developers to the "Webflow expert". Heck, they have a whole Webflow University for learning how to use the product.
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.
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.
Great. Would love an invite if you are up for it.
Of course! You can find my contact info in my HN profile. Feel free to reach out and I'll get you one :)
For what it's worth, by the time I'd finished reading the post there were about 450 errors about "Cannot set property 'className' of null" sitting in my console. Assuming Makeswift are dogfooding their own product that's not great.
Hah! Nice catch there :)
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!
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!
Developers hate these tools for a reason: they're the ones maintaining it after it's been deployed. The whole concept of "no-code website builder" ultimately goes back to "where is the code and how do we modify or integrate it with our current systems".
Maybe if it was marketed as a "fast prototyping" tool, I'd be more on board with the product.
Maybe if it was marketed as a "fast prototyping" tool, I'd be more on board with the product.
I'm not sure I understand what you mean. Why would developers have to maintain a website that's not hosted by them?
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.
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 made it a rule that all articles are html/css, no website builders. One website builder page broke and I had no idea for potentially years.
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.
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.
The SAAS I work for started out as the owner building pages on whatever dreamweaver was popular 15 years ago, and that templating engine still haunts us today. Our development cycle is painfully slow because of all of the copy-pasting that happened in the code base before a team with modern sensibilities got their hands on it. I have nightmares about nested tables for layout and inline CSS.
I realize this sort of tool targets a completely different audience, but what we desperately need is not more no-code builders, but a robust, DB-backed builder with an object-based workflow, and with code-behind for custom workflow logic. Like something that can compete with Zoho Creator, but is actually engineered in a sane manner, and offered at a sane price. It would take the market by storm.
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.
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.
> what we desperately need is not more no-code builders, but a robust, DB-backed builder with an object-based workflow, and with code-behind for custom workflow logic
Have you looked at PHPMaker?
https://phpmaker.dev/features.php
Have you looked at PHPMaker?
https://phpmaker.dev/features.php
Check this: https://appdrag.com
There is a pagebuilder producing real code that you can export and also a cloud sql db and API builder also producing real code (node.js) that you can modify and/or export and run on your own.
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/
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/
Webflow
> ... code-behind ...
> 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.
> 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.
I'm using the term generically, and you have no idea what you are talking about. Access was a DB revolution on the desktop. And that was both good and bad, as anyone who has had to migrate complex legacy Access apps to MSSQL will tell you.
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.
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.
Hi there! That's what we're working on with Retool (https://retool.com) It's, as you say, a "DB-backed" (or API-backed) front-end builder that's designed specifically for engineers. We don't store any data, and you can customize the front-end by importing your own React components or by writing JS.
(I made it, so feel free to ping me if you have any feedback: david AT retool)
(I made it, so feel free to ping me if you have any feedback: david AT retool)
We're in the early days of Makeswift but extensibility is a big part of our vision. The way we've built the core technology of our product is such that every component used in the builder is just a React component (and could be a Vue component or Svelte component), and even the controls in the sidebar, which we call panels, are also just React components. With this architecture, we plan to expose a public API where developers can just build their own Makeswift components and share them with the world. Someone could build a Stripe Checkout component, for example. Somebody else could build a table component that pulls the rows from Google Sheets, or Airtable, or from a Zoho API?
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.
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.
How does this compare to other solutions in this space like WebFlow, Squarespace, or Wix?
I like to say it's 75% easier to learn than Webflow with 80% of the capabilities. Over time, we want to get that up to 95%. Webflow has an amazing product if you already know how to code. You can make award winning websites in Webflow, but it will take you time. Makeswift sites may not be winning any AWWWARDS (yet), but you'll be able to build something good in a fraction of the effort. In addition, other people on your team can learn it as well, parallelizing your throughput. If speed is top priority, then our product is for you.
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.
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.
Thanks for the detailed answer.
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.
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.
Isn’t Squarespace or Wix aimed at people building websites with no code experience?
Or is that not extensible enough?
Or is that not extensible enough?
Extensibility is a good way to sum it up, but there's many specific issues with each. The biggest problems we hear about with Squarespace are responsive layout overrides. The templates are also generally pretty rigid.
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.
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.
Wix has a responsive layout from what I've seen as a casual maintainer of a rather large Wix site, which was originally built by a non-coder. Maybe it was part of the template he used, but a row of 3 images on Desktop automatically becomes a column of 3 images on mobile, and the top menu turns into a hamburger. You can also switch to mobile mode while editing to adjust the layout of the mobile version.
It's more complicated than this. You design a desktop version of the site in Wix, and it automatically generates a mobile version. Some widgets like image galleries and lists are responsive, but they have hardcoded rules.
So, it's not a fully responsive templates, but they are good enough for most websites.
So, it's not a fully responsive templates, but they are good enough for most websites.
I built the website builder in WeBase [1] mainly because I felt like current solutions were just so bloated.
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!
[1] https://www.webase.com
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!
[1] https://www.webase.com
Thanks!
their website is totally broken on my browser (Firefox 82 with uBlock Origin)
Hm, I'm looking at it right now in Firefox 82 with uBlock Origin and everything looks fine to me. Do you have any other details? Thanks for the report!
it seam awful, the templates are the fucking same as other platforms, as person in business i would say i dont care which technology make the job if the job is done, in general this is define for the lowest price posible or for advertising, maybe make price for use the service and export to third party hosting but i don see this, knowing that WordPress is free and have a bunch of cheap labor who can tailor your website and host in a cheaper host
>For one, the template never lasts as long as you need it to. You realize the design isn't working, or your competitor just unexpectedly made a move. So you start trying to make changes. Swapping out the text and images comes easy, but as soon as you start adjusting the layout, frustration begins to set in. You've got a million other things to do and for some reason you can't get the page to look right on mobile.
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?
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?
The promise (and I understand it's something we have to prove) is that extensibility won't lock you down. The most succinct way I can put it is: component composition. We're making a bet on the idea of components as a composable visual entity that can be used for building websites.
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.
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 don't understand the need for additional SMB website builders (as the use-case described says "company") — problems I see:
- 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.
- 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.
Tangential: Does anyone know what the name of this latest design trend is that makes heavy use of illustrations with shapely people? Does anyone know where it originated? It's taken over everything.
No, but it probably helps perpetuate it that there's many free illustration packs featuring them.
At least if I understand you correctly to mean the cartoony faceless curvy people.
At least if I understand you correctly to mean the cartoony faceless curvy people.
The premise that web sites are thrown out whenever you redesign your site is flawed. The design of a web site is one piece of a larger branding, marketing, and sales effort. It is also the end result of many other content building and design efforts, that happen to come together on a site. The site is just the end result. A re-design of the site does not throw away all the work to have built the content in the first place.
Dear Everybody, avoid all web site "builders" that are not open source.
Your own landing page takes 5.8!!!! seconds to load and makes 32 request: https://www.webpagetest.org/result/201020_Di60_34c239a225fda...
The question should be: Why don't we create a website builder focused in web performance?
The question should be: Why don't we create a website builder focused in web performance?
Improving performance is something we're actively working on!
There’s nothing wrong with more website builders, and I say this as somebody who makes his money through building custom websites. Every builder is different and takes a different approach. Every business wants something unique. The more choices that are out there, the more likely peoples’ needs will be met. Just try and add some kind of unique value proposition. Don’t just clone other tools out there.
Odoo's open source website builder released a new version last month: https://odoo.com/page/website-builder
It's quite impressive.
It's quite impressive.