> Once upon a time, design and code worked as one. Web designers would imagine beautiful designs and turn them into beautiful websites with HTML and CSS.
This was never the case and in fact a rewriting of history. My first "proper" job in web development was taking a PSD from a designer and turning that into a XHTML template. Quite a lot of the time the designs looked nice in Photoshop but were almost impossible to implement (at least in CSS 2).
I've worked in several since then and most were using Photoshop to create designs or design guidelines to pass over the developers. I used to "cut up the design" and then implement into XHTML template and controls. This was pretty much the norm everywhere if the company cared about how the website / webapp looked.
There were some frontend designer types that would write code, but I've met actually two of them during my career as a dev that was heavily front-end focused until 2023.
It was definitely true at some places. My first job was web dev using the LAMP stack. The "developer" side of the house would generally write something up, wrap everything in a bunch of divs, and hand it off to the "designer" half who would add CSS/assets and make it look good.
Sometimes there would be more interaction to have the code output things in a form more amenable to the desired design, but a lot of the time it was really that simple - the designers worked in CSS and the exchange format was divs with well-defined classes. You can do a lot with a workflow that simple.
I imagine it's a bit harder if you're using a modern stack where your code is separated from what's actually rendered to the user by a dozen layers, but designers are quite capable of working with CSS rather than Photoshop.
> It was definitely true at some places. My first job was web dev using the LAMP stack. The "developer" side of the house would generally write something up, wrap everything in a bunch of divs, and hand it off to the "designer" half who would add CSS/assets and make it look good.
So someone wrote a bunch of server code (backend) and then handed off for someone to style the frontend. This is what happens now in most teams. The person styling the frontend was never referred to as a "designer".
> Sometimes there would be more interaction to have the code output things in a form more amenable to the desired design, but a lot of
the time it was really that simple - the designers worked in CSS and the exchange format was divs with well-defined classes. You can do a lot with a workflow that simple.
I am aware. However that isn't the norm in most places. What happens is that the best dev that can style stuff is lumbered with doing all the frontend work and most of their colleagues don't understand it.
Larger orgs have dedicated frontend/backend teams.
> I imagine it's a bit harder if you're using a modern stack where your code is separated from what's actually rendered to the user by a dozen layers, but designers are quite capable of working with CSS rather than Photoshop.
This are actually simpler than they were back then and there is better separate between the frontend and backend. So it actually easier IMO.
I have never heard the term designer used to describe anyone doing anything else other than creating PSD mockup and later on wire-frames.
I have worked in large corps and smaller agencies as a full stack / front-end dev for about 18 years.
This wasn't just the case in my part of the world. There were prominent online publication that were extolling the virtues of designers embracing creating their designs in CSS and HTML and moving away from using Photoshop.
No. I didn't think what I said was that difficult to understand. But I will break it down.
- Designers were not working with HTML and CSS (this was about ~2008-2011). I met one "designer" who would do HTML and CSS back in about 2015. I met another woman that could do it in 2022. I've worked in a bunch of web agencies and corps.
- Some designers due to emergence of smart phones had started experimenting with using HTML 5 and CSS 3 to create responsive designed.
- There were articles in online publications and blogs where people were extolling the virtues of it, trying to convince others.
- This ultimately didn't happen. People are still using Photoshop if they are not using Figma. You have dedicated front-end devs and/or teams in most orgs if they actually care about the UX/UI quality. Otherwise they just just use a bootstrap/tailwind theme and call it a day.
I stopped doing frontend dev primarily back in 2023 after I realised I was still fixing the same stupid iOS bugs from a decade before hand.
All I can say is that your experience from that time was very different from mine.
I don't really understand why you first claim that designers absolutely were not writing CSS and then go onto admitting that they even wrote articles about why everyone should.
That is a very clear contradiction. Clearly a lot of designers were writing CSS otherwise they wouldn't write about it...
> I don't really understand why you first claim that designers absolutely were not writing CSS and then go onto admitting that they even wrote articles about why everyone should.
I really don't know what to say with this statement. Obviously there were very few doing so, and trying to evangelise others into doing so. I think I made that crystal clear.
It seems you are getting hung up on the difference between "I've encountered this very rarely" and "none". If that is your complaint you are simply nitpicking. Which is what I suspect you are doing.
> That is a very clear contradiction. Clearly a lot of designers were writing CSS otherwise they wouldn't write about it...
No you cannot draw that conclusion. If there were already at the time "a lot" they wouldn't need to try to evangelise others to do so would they? There is no contradiction at all. Again this feels like you are angling for something that not there.
TBH from my interactions with you so far, It feels like you're wilfully misinterpreting my statements for gotcha. So I would rather we would leave it there.
Seriously. Talk about revisionist history. The web dev workflow before Figma was awful. It never “worked as one”.
I love Figma’s dev mode. Saves me and the designer time from measuring sizes and eyedropping colors. Figma also allows me to export assets myself instead of waiting for the designer to do it, or do it myself poorly from Photoshop.
The relationship between design and dev is much more collaborative now. It was downright hostile pre-Figma with photoshop and illustrator files. Nevermind versioning, sharing and comments…
Man, I started building websites and doing CGI coding in 1994 and 1995, which makes me a very early web developer and I don't remember this time at all.
In fact, I stopped coding as a job when it became expected that I would do back end database & business logic stuff AND fiddle with front-end code to make it work/look the same in 3 very different browsers, and update the code each time (I'm looking at you Microsoft) a browser vendor would do something stoopid.
Ah. I was managing teams of developers by then, and most of them had some front end skills, but we still needed dedicated people to deal with... I almost said "edge cases" but since they impacted every single project I guess they were not "edge cases".
I was still working on Safari Compatibility in 2023. The bugs I was fixing in both CSS and JS were present in the iPhone 3GS or iPhone 4. I was utterly fed up of fixing the same stupid issues and decided to look for a more backend focused position. Unfortunately I am now working with AWS which has it own set of headaches.
Seems to be unavoidable in in the era of "move fast and break things" coupled with "let's make it proprietary so we don't have to defend our space with innovation" and incentives for staff to release features we didn't ask for nor want.
I am not saying that it was the same at every company and your personal experience may be different.
This was absolutely the norm at a lot of companies. It was very normal for the developers to work in either PHP or Ruby on Rails and the designers wrote CSS.
It is also true that since the introduction of modern frameworks we see significantly fewer designers who know CSS.
It was never the norm. I've worked as a contractor/consultant in a lot of places and I saw two people that were "designers" that could write HTML and CSS. That is two people in 18 years.
> It is also true that since the introduction of modern frameworks we see significantly fewer designers who know CSS.
None of these people knew CSS at all. I am talking pre-2012. Bootstrap version 1 or 2 was out at the time and 960 grid css was only out a few years before.
I think with maybe Flash 4? That's when we started pushing the envelope and some of our back end developers started working in Flash.
I was procedural programmer (came from Sysadmin - shell and perl) and I had zero desire to learn the whole timeline approach to actions (my memory is fuzzy) but I would give them endpoints to call server side!
Having worked with Figmas from pure UI-designers that translation to HTML/CSS is not at all as straightforward as they like to pretend.
I don't know about this startup's product but based on their homepage having (real) HTML/CSS output as a core part of the creation process would have helped me many times. Designers need to be constrained.
Expecting designers to know how to build production websites in html/css/js before designing is apparently a step people skip over these days. It creates meaningless design and dev cycles + tons of extra approval meetings by marketing/execs.
It always bothered me that people got in the trouble of making a web-app, that generates designs, and those designs are not plain web pages.
I guess one could create a really good tool where UI designers make a real web reusable pattern language, and UX designers specialize them into a set of templates the software developers can actually apply.
E.g., it's more similar to how Adobe Illustrator and other C++ graphics programs render content than it is how a web browser engine renders HTML and CSS.
That's an implementation details and doesn't answer the higher level product incongruency. Tool A, used to design for technology B, doesn't output files in technology B format. It's fine to point out that Tool a uses technology C under the hood, but that's the tail wagging the dog, and doesn't make sense, even if there's an explanation for it.
To address your point specifically though, Webflow is (at least from my perspective) the inevitable result of the line of thinking you're pursuing. So I'd be curious what you think of Figma vs. Webflow, and why those two products have their relative market positions.
I.e., "Tool A, used to design for technology B, doesn't output files in technology B format. [...] doesn't make much sense".
E.g., why not just use Webflow then? From my understanding, that's what it does, that's what it's made for.
Figma got where they are because their collaboration features are Google docs level. They also got enterprise buy-in, and target design more broadly than simply website building. (As far I understand. I'm not a professional designer.)
> Figma got where they are because their collaboration features are Google docs level.
I’d argue Figma got where they are mainly by streamlining the handoff process, not because of their live editing collaboration features per se. But there isn’t really an empirical way to validate this. But my point is really if you want to export natively to the web, just use, promote, etc... WebFlow that's the tool designed for that job.
> [Figma targets] design more broadly than simply website building.
This is absolutely true, but I’d argue it’s impossible to be able to both target many platforms, and simultaneously be able to export to all those platforms natively. I.e., you have to build the constraints of a specific platform into your tool in order to export to that format. This is what WebFlow is (and using it for just 5 minutes makes clear the trade-offs of designing a tool like that).
My first and last experience with Figma was that it required a user to import existing designs in order to do anything useful, such as 'share them with the team' . I was surprised at that given its hype as a design tool but then realized the name must have been carefully chosen.
As others have pointed out, this should have been a showHN, but the article is vague enough that it wouldn't have garnered attention as a showHN. Furthermore, the post inflates the problems of design handoff to try and sell a no code editor environment. Yes, I'm aware that the platform enables coding capabilities, but plenty of no code tools can.
If you want to get into the shortcomings of Figma when it comes to hand off, I'm more than happy to have that conversation. Units that aren't valid in the CSS spec? Sure. Vector tools leading to things that are only achievable through clip path and masking? You bet. But claiming that designers and developers should have the same job when they're completely different skill sets and claiming that both roles are using the wrong tools to get the job done is no way to sell your product.
I didn't notice at first but it's one of those "blog post ads", concluding with "it's time".
Time for what? To click the "open app" button? Okay, so I clicked.
It doesn't open app. A button labelled "open app" should do what's on the tin. Instead it prompts for sign-up with terms and conditions warnings. I'm out.
Just open the app without sign-in! Why not? Too hard? Too scary? You can haggle for sign-up later. Let's see what you have right now, under the button labelled with a promise that I expect you to keep. Lying to me on page one is not a good start.
Here's an example of a web app that does it right. The button "start using Photopea" isn't a lie: https://www.photopea.com/
Ok good, I'm checking out the CSS clock demo. Looks interesting, although I'm probably not the target audience, I'd just code it normally. I may revisit and see what else it can do.
Like all the comments below, a show HN should have been the norm, but they knew that would not get any clicks and this.
However, I do not understand their pricing. If nordcraft's ppl are here, please tell me how does it work. For open source, you say there is a limit of 20k requests? . But I can always download the code/web-components and deploy anywhere I want right? Then even enterprise can do that? I do not understand it. Also it is Apache License 2.0. I can host it on my own cloud. Are there some restrictions if I do that?
> Designers would go into a design team and draw user interfaces. Developers would go into a dev team and write code. And thus, the hand-off was born.
Which is exactly what Figma solves and why it's so valuable.
Figma is the place where the UX team and dev team meet and discuss, specify design and behavior together through back and forth, and helps the dev team move from there with exactly what they need.
Nordcraft might want to be the next Figma, as it's apparently a lucrative position provided you execute incredibly and capture most of the market. But how they describe it they're not properly assessing or representing any of the current reality.
I kinda wonder what it would need to achieve to be significantly different from Figma. Perhaps if it was actually a whole production runtime where designers define front layers and the dev team codes binds them to a backend ? Basically a WordPress competitor ?
The Figma as a design space works better when the designers understand that constraints of HTML/CSS/JS animations. That's not often the case in reality (unless you hire around that idea).
I find many Figma designs basically force you to use fancy JS to assemble their UI designs. I know everyone uses React these days but you really shouldn't have to constantly write JS just to reproduce what's in a UI design. It creates so much needless dev and browser overhead.
Reading the other threads as well, I got the feeling it's more a culture or process problem than tooling per se.
The excessively fancy UI issue can be avoided if the devs enter the process at the prototyping phase. And Figma can be used for that: start with a wirefame and get everyone's input, comments, or even let the devs make counterpropositions (basically MRs?) by tweaking a copy of whatever screens are worked on. And as the design gets closer to reality the back and forth can continue in Figma.
That requires team collaboration and the willingness to build decent HTML/CSS in the first place, none of which are a given, but for teams working at that level it's a boon.
You can do it that way but it’s not the easy path. I think the problem with the tool is that Figma makes it too easy to make polished interactive designs that look done. The easy path is just to skip the wireframe, so by the time the programmer gets involved, the designer and management has already fallen in love with what appears to be a final product.
If figma was built on top of HTML and CSS—and so couldn’t represent designs that HTML and CSS can’t, this might be less of an issue.
Granted it would still be a problem because there are always underlying technical and processes issues that should be uncovered before you leave the wireframe phase that have nothing to do with HTML and CSS.
> the designer and management has already fallen in love with what appears to be a final product.
This is probably the crux of the issue. It's the same process as asking a famous illustrator to draw a cool house, and then ask some random architect to make it a reality. I'm always amazed at people doing so, that's not the type of house I'd like to live in.
You are right that tools don't solve problems, but they can cause them.
The problem here is that designers are limited by their tools. Figma can only do 10% of what CSS is capable of.
We can try to work around those issues with closer collaboration early on, but the truth is that most of the problems aren't universal. They are constructed
It works better in house for sure or with a good agency. There's a whole industry of fancy corporate design agencies that produce Figmas and developer-in-the-loop means going into lots of meetings with the consultancy managers and then waiting a week and a couple grand in hourly for them to produce something that needs to be fixed again.
But ignoring those fixable processes and hiring issues, there is plenty to be said about the new world of isolated islands of UI/UX designers, frontend, backend teams. I blame Javascript/React eating the world more than Figma. React/Vue opened up a whole hyper complex world of UI design and shit rolls downhill from UI->frontend->backend->users (mostly via performance/complexity).
100%
The problem is that Figma is not a web design tool. It is a vector drawing tool. It only covers about 10% of what CSS can do so you are never going to get good web design from a Figma file.
We are definitely not trying to be the next Figma. Figma does not solve this by any measure, quite the opposite. Figma could have been a web design tool, it is not. It is a vector drawing app.
Nordcraft is a completely different type of tool. It is based on HTML and CSS instead of layers and absolute positioning.
Seems to be missing quite a bit of history. As many here mention, there was an entire ecosystem of tools to convert PSDs to HTML such as CSSHat, Engima64, etc., and its evolution into Avocode, Sketch, Zeplin, Invision Craft & Inspect, and other preview/prototyping/inspect/export tools.
Eventually all roads led to Figma somehow, which honestly I would've never expected. Still surprised Figma became Sketch before Sketch could become Figma.
What the hell is this article talking about? Designers used to hand development teams PSD files. Or Illustrator files. Or, in the golden times, Fireworks files. Designers rarely handed us CSS and markup.
... did this person just start in the industry like three years ago?
No quite the opposite. I have been around for a long time :)
It used to be completely normal for companies to have developers who worked in php or ruby on rails and have designers take care of the css.
You are absolutely right that in the early days many UI designers came from graphic design and worked in photoshop. But the fact that they also existed in some companies isn't really relevant.
Absolutely agree. That is why we are working on making the Nordcraft editor open source and we write blog posts like this to hope to get more people to see that we need better tools.
If you are just one tool are not going to have meainingful change.
Okay, there’s no “working on” open sourcing your app. You could just open source it.
What you really mean is that you’re looking into how you can open source just enough to create a free-to-paid entrapment pathway. You’ll do open source if you can provide a product where all of your users eventually hit a wall and need to upgrade to a paid plan.
A more honest answer from you would have been “we are just looking to provide a solution” rather than pretending to be working on a true open tooling ecosystem.
Don’t pretend to be open source as in Linux or git when you’re really open source as in MongoDB or Chef Software.
the editor is currently closely coupled to our hosting platform which is built on top of cloudflare. we want the open source version to be independant of that
This was never the case and in fact a rewriting of history. My first "proper" job in web development was taking a PSD from a designer and turning that into a XHTML template. Quite a lot of the time the designs looked nice in Photoshop but were almost impossible to implement (at least in CSS 2).
I've worked in several since then and most were using Photoshop to create designs or design guidelines to pass over the developers. I used to "cut up the design" and then implement into XHTML template and controls. This was pretty much the norm everywhere if the company cared about how the website / webapp looked.
There were some frontend designer types that would write code, but I've met actually two of them during my career as a dev that was heavily front-end focused until 2023.