Streaming live at 10am (PST)

Limitations with Webflow?


#1

I am a designer from the print generation. Over recent years I have taught myself to handcode. It’s not difficult to do - in fact it reminds me a lot of Adobe InDesign text styles and master pages. I enjoy being able to see the code and work out what is going on. I use simple CMS like Surreal.

However, I have probably reached a ceiling of what I can do. Things like JavaScript, PHP and Wordpress are probably outside what I want to do.

Hence my interest in Webflow. But there are a few things that I don’t like: I can’t see the code, so it is far harder to ‘see’ what is going on; only limited set break points; and no support for changing the HTML base REM at breakpoints (something which I use a lot to make everything smaller by only changing one line of code).

Also, I find WF slower than handcoding. I’ve got to learn the tool before I can do anything. It seems to put another step in the process / get in the way of the actual code.

I guess my question is: will WF allow people to see and edit all the code (as well as doing it visually) inside of WF? I beleive this would then make WF an amazing tool. I can still handcode the easy stuff and leave WF to do the tricky JS, JQ, database, CMS stuff.

Any thoughts? Any one else from a handcoding background using WF?


#2

Hi Mark,

All your concerns are legitimate. However read below for some technical details and workflow ideas. I’d like to paint a brighter picture of the tool :slight_smile:

That’s not entirely true. For starter, what you build in Webflow IS the code. There is no abstraction. A box you create is either a div or another box html5 element.

Apart from some pre configured components like Columns or Slider, what you put is what you get. On top of that, you can analyze the content of such components in the Navigator view, and select and alter their inner elements. They’re meant to be helpers, they’re not magic.

Now, you can still use Chrome Inspector when you’ve activated Preview. And there is your code. The structure you’ve been defining, the custom code and custom fields you’ve been adding using the designer. all of it. And… it’s clean, it’s very understandable, even the proprietary classes that Webflow use make sense. And they’re predictable, and limited. Already way better than any of the big CMS I had to work with (not better, WAY better).

Not only using Webflow is like creating HTML and CSS, but visually, but it so respects everything that you get better at web concepts themselves. You do get better at HTML and CSS when you use Webflow.

For all of the reasons explained above, there is no difference of facing a situation with manual code than facing it on Webflow: an issue is resolved the same way: inspected in Chrome, solved in WF or code. Same, same logic, same efficiency. Situations were you have a bug because of Webflow, a bug that you can’t fix with HTML and CSS, are rare. The proof is that you can see users solving other users issue on this forum, every minute. Look at the solutions. Not so much as Webflow solutions but HTML and CSS. Users here constantly link to Stack Overflow, CodePen, W3C.org. Are those site talking about Webflow? No. HTML, CSS, JS and all that stuff.

They’re limited, but in my quite experimented opinion, they’re well defined. Yes that’s true that the wait for an larger one starts to be long. I could use an extra one in the like of 1200, 1440, for all of my projects. But I cope with this absence very easily, by crafting my own container, that behaves elastically between 1200 and 940. Still, I’d like to have a new one supported by Webflow, with the extended grid that comes with it. And the grid is maybe one reason why we still don’t have the extra breakpoint: the grid is very well managed in Webflow, not a lot talk about it but the components makes working with the grid very easy. The new breakpoint can’t happen in a snap, I’m sure there’s a lot to think about before bringing the feature.

It all depends on what you do. I can see some cases where hand coding can be really fast, but doing what I do with Webflow, spending time on every detail, refining every motion, fine tuning styles and make them behave neatly for each breakpoint, playing with conditional visibility on complex elements to procure the UX you wanted and not only what’s left as options to you… that I can’t see being more efficient by hand coding than visually designing.

I don’t see WF allowing touching the code in parallel of the designer anytime soon. What would be the point? Pinegrow allows this and it comes with limitations: that’s the reason Pinegrow isn’t on par with Webflow when it comes to visually edit/build a page.

I don’t even know what my point is here. All your fears, I had them. And I was skeptical about visual editors. They were all magic and buggy. I wanted to do too serious of a job to use any of them. Webflow wiped those concerns. I could develop what I want, visually. And the kind of closed ecosystem where you’re hosting on Webflow, in the end, made me concentrate on the design and pay a very small fee for all the servers and maintenance tasks that I didn’t want to do and that I was doing poorly anyway.

All I say is give it a serious try :slight_smile: it’s worth it.


#3

In general also in static sites, Wordpress themes + Wordpress builders (like elementor) + Frameworks like: Bootstrap / bulma / foundation + WIX and other visual buildiers and so on - you find 4-5 breakpoints. Why? Because it’s really hard to manage 7-8 breakpoints (Endless work).

For very specific issue (RARE) - you could add custom CSS code.

I code static (ATOM or tools like pinegrow), WP (Elementor or regular themes) and by webflow - the flex grid, the drag and drop, the visual environment, symbols (Usefull for Global areas - like footer or nav), built-in components (tabs, slider, Etc), classes (And great CSS editor), global styles (for H1-6, p…Etc), swatches, Zero page refreshes, CMS concepts (Very easy to style pagelists & posts), responsive (very easy to control the layout in each breakpoint) - “Need for speed” :slight_smile:

Anyway the Quality of your site is what matters (This is not a race). Like any other program - more experience = less time to create same things


#4

Thank you for your reply. Appreciated.

That’s not entirely true. For starter, what you build in Webflow IS the code. There is no abstraction. A box you create is either a div or another box html5 element.

I guess what I’m thinking is: there is no way to see overrides: spans inside body text, or additional classes etc.

A long time ago I worked in an academic book publishers. We didn’t use Quark or InDesign but another software called Ventura. It was much more like raw code. The editor would mark up the content (like HTML), marking headings, italics, bolds, sub heads etc and then we would flow the content into the layout and establish the styles (like CSS). Webflow reminds me of InDesign: visual. Handcoding reminds me of Ventura: being able to see the underlying code.

I’m not saying Webflow is wrong, but there are times when I’m using InDesign that it would be handy to see the “markup” of the content, to be able to see style overrides and spans.

Is handcoding faster?
When I handcode I use REMs. Then at my breakpoints by changing the base text size, I can make everything smaller or bigger - by simply changing one line of code.

Also, if I want to change the baseline grid of my website, when handcoding I can simply do a find/change and in one go change the line-height of all my elements.

Just these two examples are massive time savers.

Anyway, thanks again for your time and I’ll probably give Webflow a try…


#5

It’s not that I see a case necassarily for more breakpoints (apart from a larger size one), but control over where the breakpoints are. The content / design should inform where the breakpoints are. See https://adamsilver.io/articles/stop-using-device-breakpoints/


#6

Why not? A text span is box, you can click on it and change its style, cancel it… You can navigate into the hierarchy of classes, for each element, accross all breakpoints.

Here I spanned some text for a lettrine

Here I browse the classes to add properties to the base paragraph element

I’ve been an editor of computer books and they were all made in Venture. We would have coders constantly improving the workflow with features coded in VBA. They’d write APIs for editors, translators etc.

Webflow is not InDesign. InDesign is a visual procucers with a very weak flow limited to text flow. Everything is damn absolute.

If you want to produce document and see the code and modify the code, then Ghost is the way. Or DocX maybe if I understand it well.

Webflow is only a WYSIWYG editor for web content. As long as it works, producing clean code — which is the case — it can’t be wrong, it can only be limited by the amount of HTML and CSS things it supports in its UI/workflow.

Coding is only one tiny aspect of developing a front end or cms project. And coding faster or not is really an uninteresting topic. To achieve a project in reasonable time, from client relations to maintenance after publishing, you need good tools and strategy. Something stronger than a Notepad.