oleg009

There has been a lot of attempts at this, this one is the best so far.

The point of this question is why we can't start using it now with a fallback that does the same thing but with JS.

Why should chromium users wait? very soon majority of the users will have that feature, why should they keep getting less performant and often stuttering animations via JS libraries?

We are generating React/Remix app atm, but our architecture is designed to support other frameworks as well.

It is achieved by using data as a source of truth, not the code. Web tooling is very fragmented. People have too many opinions on how to write components and that makes it nearly impossible to have components written by hand and then synced back into the UI without enforcing a huge amount of constraints. You will end up writing code in such a way that the UI can handle.

Airtable works, we even made a video for it: https://www.youtube.com/watch?v=21y1_CiBqnM

Notion: data should work, we are going to record a demo, but Rich Text is not supported yet for every CMS, only those who have an HTML option, see compatibility: https://docs.webstudio.is/university/foundations/cms

We will add them one by one, with full Rich Text support.

Syncing the site data from builder to local fs and then building everything and configuring the app for publishing to vercel.

Just pushing to github only helps you if you only have static html/css if you wanted to publish a site as gh-page ... I guess you need to clarify your use case

This would also solve the problem with testing on various mobile devices by e.g. using browserstack and similar tools or even physical phones.

when you say confidence, is it because the person who builds, can't test in other browsers inside builder?

this is something we are going to solve soon by having ability to open up the build url and keeping it in sync with the changes.

We are launching a CLI soon that will allow syncing data and self-publishing, starting with Vercel as first destination.

its because dashboard works in other browsers too, but builder is very complex

for privacy reasons? Afaik github is gdpr compliant ... or is there some other problem?

CLI for syncing and publishing to Vercel is coming in the next weeks

Webflow actually helps with all those things. Webstudio doesn't have much yet accessibility features on canvas, because this comes next, but the performance - man it feels like a lifetime spent on optimizing it with the help of lots of different tools. we hit 100% on lighthouse score consistently, the webstudio.is landing is built with webstudio.

https://pagespeed.web.dev/analysis?url=https%3A%2F%2Fwebstud...

I am confused, we only have a download button at the bottom of the page, but "Get early access" button everywhere else. It is much harder to find download than to open the browser version ...

Similarity to Webflow is not a bug, its a feature. It's designed to feel familiar for Webflow developers. This product is built for them.

Check out this video to learn how Design Tokens work in Webstudio. It's built with full knowledge of Webflow Style selector. You are talking to an ex style system engineer from Webflow lol.

https://twitter.com/webstudiois/status/1669441600831868944

Not sure if you are new to the internet :) to give you one example of many https://supabase.com/

This is how you can position yourself and be understood by the target user if the product is for them

You are correct regarding CMS. Same story with e-commerce and other things. In fact fundamentally the architecture is built around the idea of not having those things built-in but rather providing APIs for others to create integrations with any data source: CMSs, Databases, E-commerce etc.

Webflow and others with built-in CMS have a massive amount of problems, because there is no one CMS that fits all.

Even harder is e-commerce.

So yeah, we are not going to compete on that because we are not building any of it, but instead focusing on architecture to support integrations.

Here again you show lack of nuance.

Pro webflow developers use keyboard a lot. In fact with Webstudio we took the keyboard accessibility very seriously, still A LOT to improve.

Visual development is a mixture of mouse and keyboard. Some things are faster with the mouse, some with the keyboard.

The reason some people prefer mouse is not just that they are used to, even though it is true. Its because they know how to be efficient with it very well.

"code is like that but on steroids" - again it can be true in certain use cases, but there is a massive amount of use cases where this is not actually true.

Most of them are around layouts, styling and configuring components. Visual development is basically declarative programming - its configuring things.

We are actually thinking deeply about the gap between typing and visually manipulating stuff at Webstudio and the plan is to allow a lot of the same UX patterns that you have with text-based coding: copy/pasting things like styles, box shadows, gradients, instances of components etc.

Ability to paste gradients is already there, box shadows comes soon. Writing component code inline will most likely come at some point as well. Linked CSS editor - similar to chrome dev tools for css is also planned.

As you can see there are ways to close the gap and when needed write code.

The most frustrating thing with code is the build tools, compilers etc. These days nobody writes just simple html and css, things are complex. So the benefits of writing code are often completely destroyed by the amount of complexity to deploy the site.

There is a serious knowledge gap between what you just wrote and the actual reality out there. I don't want to convince you of anything, just share the knowledge of what's actually happening. Why tools like Webflow have $4bln valuation and why there are millions of webflow developers.

1. You are looking at it in black/white. Coder vs nocoder. That's not how it is in reality. There is a seriously big amount of people who understand enough of coding to use webflow comfortably but not enough to write code by hand and/or wanting to do so.

2. Designers are used to visual tools. They find their way when tool allows to experiment without first studying how to code and then gradually learn css/html basics if they need to.

3. Building layouts, styling, html structure etc is actually faster with webflow once you understand how it works and learn all the shortcuts.

If you actually care to learn about it, go talk to some pro webflow devs. Some of them will tell you they actualy know how to code, but its less efficient for a lot of use cases.

4. Handoff. A huge problem with building websites is wasted time between a designer and a developer. There is just too many things to consider and a static design in figma is never complete. Webstudio and Webflow aims at solving or at least reducing the handoff by either building directly in Webstudio/Webflow or by keeping figma design low-fidelity just for initial communication with the customer and then moving on to building.

5. This industry has come a long way and these days several tools are also integrating with git-based developer workflows. The goal is to let designers and visual developers to build visual components and design systems in the builder ui and provide those components to developers for further integration.

6. There is a clearly steep learning curve with Webflow. Lots of things are not easy to get. Its not a tool to build a website in 5 minutes, its a tool to learn html/css visually and become pro visual developer. Once you are there, the typical landing sites and marketing pages, even large one are built significantly faster and more presize from design perspective than with coding. I am saying this as an engineer who started building for the web in 2004.

This is not meant to start an argument. Just pointing out a lot of stuff that is understandably not clear to many.

Hi, hacker news community.

Oleg here, founder of Webstudio. We just launched the Beta a few days ago https://twitter.com/webstudiois/status/1668519656481497088

This is basically the first phase - Builder UX. Builder is focused on designers and visual developers.

Features developers community would expect are still in development and not documented, but I am excited about any feedback!

This is true. There are standard use cases like landing/marketing sites, blogs etc that can be done fully visually, and there are custom once where coding is not avoidable.

We have designed it to work for both by providing API and CLI to integrate with the custom app and git-based workflow.

This part is still work in progress though.

Integrations with various frameworks is on the roadmap. In fact we have already started integrating with the first one - Radix UI.

Once we are happy with the API for integration, we will document it for developers community so everyone can integrate it with different frameworks.

Hi, we just launched Beta and didn't start yet working on documenting the self-hosting and self-publishing experience much.

It will come for sure. We are still focused on builder experience.

People should stop looking for a silver bullet. If you are using react + relay, you must be building a very complex solution, where the overhead for such abstractions is justified.

If you are at a point where your task doesn't justify these abstractions - don't use them.

Find the right tool for your job.

Hi

I think its great that you try new ideas in this area. Don't listen to those who didn't event try to create better tools, but rather just crying around that all the "css in js" solutions are bad, ignoring the fact that the current traditional CSS is bad for lots of cases too.

I am biased because I am author if jss https://github.com/jsstyles/jss

What I understood from descartes is that you are trying to make styles dynamic by allowing listeners. So that when user interaction happens, styles can change accordingly, while the logic for it is contained in the style itself.

I had the same idea in jss too and ended up with this api for dynamic styles: https://github.com/jsstyles/jss/blob/master/docs/js-api.md#s...

I am still looking for a way how to make this idea more usable.

You guys should publish a content-editable abstraction that fixes regular cases first and then build stuff like collaborative editor on top.

1. Stop assuming I am stupid.

2. I know code reuse technics in css, they are mentioned in the presentation. Cascades do not work for component based development. Adding multiple classes to an element leads to awkward code and also will lead to namespace conflicts if you don't name everything very specifically.

3. Vendor prefixes are there and will be used for new features too. They will not go away. Precompilers can't avoid generating all prefixed variants.

Definitely!

jss not harder than less/sass/stylus ... its declarative json syntax most of the time.

saving come from 1. code reuse. less/stylus will generate everything dozens of times 2. vendor prefixes are added effectively at runtime

Thanks Cheng, you nailed it. Jss was actually inspired by your RCSS idea, I just wanted a different implementation. So thank you again.

Some people here assume that I am stupid and didn't learn the css basics. This is just funny.

Its definitely framework we need, to get more performance out of web pages, especially with mobile in mind.

It has some really good ideas in terms of architecture and good modularized code. (I would prefer cjs over amd)

On the other side it is very young:

1. There are some serious issues to be fixed, f.e. https://github.com/Famous/famous/issues/111 or https://github.com/Famous/famous/issues/74

2. There are no open sourced tests, I even assume there no tests at all at the moment.

3. They open sourced code but the development itself is closed. Its a black box.

I really hope famo.us will change this stuff and will focus more on the core framework and being real opensource product.