This should not have been posted as a Show HN. Show HN is for
something that people can actually try. Fundraisers and teaser pages are ruled out in the rules: https://news.ycombinator.com/showhn.html.
(We've taken Show HN belatedly out of the title above.)
This looks great, and could be a great tool to help some front-end developers.
However, I must say, it's 2019, if you call yourself a front-end developer, and you do not know flexbox and grid - you are greatly missing out on an amazing radical change in how you think about and design your layouts. There really is no excuse for not knowing this stuff, especially with all the great resources out there to help you learn.
The same company has a paid game to learn about the grid (https://gridcritters.com/), but I came across the resources below and did not buy it.
Flexbox Froggy and Grid Garden are both free, not gated by an email signup, and very high quality. You and everyone on your team should do them, even if you think you know them well. It will help with reinforcement.
I think Gimli is an amazing tool, and I might even buy it when it comes out. But please, do yourself and your team a favor - learn the tools by hand first. If you wrote a float at all this year, this post goes out to you.
I don't think learning something necessarily mean knowing lots of names/properties by heart. You should however have a good idea of what grid and flexbox can do for you and when to use them I think.
I personally have a hard time differentiating between properties such as justify-content / align-content / align-items / justify-items / justify-self and so on. To me those are just random words. Perhaps because English is not my first language, I don't know.
I really think it makes a huge difference to see a small icon describing what properties have been set and to see the difference by hover instead of just reading/editing raw CSS.
Agree with all of this, except that float still has a place. when you want text to flow around an element, float is great. I'm so glad that we don't need it for layout anymore, and I'm sure that's probably what you meant.
Agreed, although these days I find more new developers who know flexbox, but not traditional layout method like inline-block and position:absolute. IMO it's key to know both.
It's unlikely that's the case unless you're in a weird niche where people use ancient tech though. Both flexbox and grid have been available since IE10, albeit in a slightly different form prior to Edge.
I happily write flexbox layout code in particular that works everywhere without any changes necessary for old browsers.
I recommend that you make the app available for beta testing with some users. Maybe even releasing a beta version to the public, do not make the mistake of waiting until you have the perfect product.
Other request/suggestion is to make it open source or at least free for personal use, it will bring a lot of users that will want to have the same tooling at their workplaces. Then you can have commercial licenses that you make corporations pay for.
Agree - could you release an Alpha version via Kickstarter? I'd pay (say) 50 SEK for alpha access to play with it for a couple of months, and (if wanted) give feedback on bugs.
You could always end alpha access at a given point (set date or once the beta release is out) and/or offer upgrades to the full package at a slight discount.
No downside, apart from a little more complication for you, and you'd maybe get a bit of money even sooner...
Too answer your question though. I've been working on Gimli for the last 18 months now. Using up my own savings, and the reality is that I can't afford to keep working on it for much longer.
I would have loved to be able to present a finished and polished product but i'm just not there yet.
One little thing: after watching the demo vid, Youtube suggest some related content. You can disable that. (I caught myself youtubing inside your landing page :D )
This looks really cool and definitely fills a need I've had when doing web front-end.
Does the UI viewer work with dynamic content such as that loaded from a back-end (or say, from a sample .json file in the event that we want to skip the API call)? I've done a lot of work in WPF/MVVM applications where everything ends up becoming a ResourceDictionary and breaks the Visual Studio UI viewer, so I'm curious how you handle it.
Also, do you have any plans to incorporate a compatibility view? It would be really cool if I could select an item from a combo box and see what my UI would look like in (say) IE or Opera
I'd agree with this if it was ready now. I think a huge discount is warranted considering it's not actually available now and you're backing a Kickstarter.
The main difference is that now we actually have a proper grid layout system which enables editors to do their job properly. Things like webflow allow one to design responsive components without having to code anymore.
I agree, although, considering the age of Dreamweaver, I don't think we've come far enough. In other words, my younger self from early 00's would have expected way more from 2019. I didn't know what I wanted had a name (CCSS[1]), but I wanted it, and unfortunately for the web platform, there's still no official implementation, but at least there's a JS-based one[2].
Yeah, unfortunately. Hindsight 20/20: Using a JS-based layout engine alternative to CSS wouldn't make sense, but at least it counts as a proof of concept.
I know responsive design is important in a mobile-first world. But the grid systems I've seen (mini.css; it's my first web project in 15 years and I've decided not to use frameworks, just bash rocks together until the browser talks and listens to an API server) are nooot great.
They're significantly wordier than old school tables, and significantly more confusing to write by hand too. The one good thing is that they shrink with window size.
I know I shouldn't be coding up web "apps" by hand and instead learn React or whatever, but why should the whole making webpages an active hurdle for a techy person of average intelligence who can e.g. move some of his custom code from numpy to tensorflow?
Maybe I didn't google the right things, but I expected something that allowed me to say "div id=topnavbar" or something. As opposed to a lot of width classes that...
Next thing you know I'm not allowed to repair my TV despite having had a short protoboard-electronics hobby in my teens. I jest.
I've not used it yet myself, but it looks to work well enough for at least top-level grids. Your description of other grid systems is accurate, both of those and frankly of most advanced CSS in my opinion. (Cue someone saying "It's easy, you just apply these 3, 5, or 20 CSS properties that you knew applied because of dark magic, and It Just Works!)
> wordier than old school tables, and significantly more confusing to write by hand too
The issue with old-school tables was never that they didn't work or even were hard to write. The issues (beyond the issues of effective obfuscation of data and accessibility) were that they didn't handle revision well at all. Nor modularity, for that matter.
> I know I shouldn't be coding up web "apps" by hand and instead learn React or whatever
There are bitter haters on all sides, but the practical truth hasn't changed: template libraries make sense when you start to code solutions to the same problems they solve, or at least encounter those problems. If you aren't encountering those issues, they have little to offer.
> Maybe I didn't google the right things, but I expected something that allowed me to say "div id=topnavbar"
Unless you use some built in setup (mini-css, bootstrap, foundation, etc) and accept their limitations, you're left to write that all yourself.
> Next thing you know I'm not allowed to repair my TV despite having had a short protoboard-electronics hobby in my teens.
You seem bitter that some downgrade of experience has been forced upon you - it hasn't. Just because there are new best practices and preferred alternatives to old best-practices, doesn't mean the old ways stop working. You have more options today, not fewer. If you don't like those options, keep at them.
I myself am happier with the newer options over not having them, even if I think CSS is STILL way too obtuse and makes simple things difficult. Many old practices are not best practices for reasons. But no one is forcing your hand.
I still hand write everything in html css and make progressive enhancements. I like layouts that are still readable if you turn off css and javascript, using meaningfull/semantic html.
I do like a lot of the stuff that have been added to css, it makes my life easier. So i suggest starting out with just html5, then do the fancy stuff in css. One line of css can usually replace what you needed 20 lines of javascript to do before. Html and css are lagging far behind though eg. You cant define how a json file should be rendered using just html and css. Thus all the frameworks like React to close the gap. If possible though keep things simple enough that you dont have to rely on heavy javascrip.
I think that your experience is valid, but it's worth considering that in the days where we used tables for laying things out, we didnt worry about responsive design and people generally didn't design things to work with so many different viewports with significantly different aspect ratios. Basically, mobile devices have made it much, much more difficult to implement consistent design experiences on the web.
Also, I haven't used mini.css, but if you're looking for some CSS libraries that make your life easier, I really really like tachyons: https://tachyons.io. It takes a little while to become familiar with the classes, but almost all the classes are super easy to scope for media queries.
If you are at all interested in learning a little bit of react, create-react-app makes it really, really easy to get started. In the past, getting a react/js project set up and configured was a real pain, but create-react-app handles all of the config for you, and is a pretty great tool: https://github.com/facebook/create-react-app
I'm no expert, but if you have any specific questions about any of this, I'll do my best to point you in the right direction!
Completely agree with this. It would be very hard to build good tools around float, tables and inline-block which we used to work with.
Also, I do find a bit surprising that browser vendors haven't looked more at what tools like webflow are doing.
Firefox Developer Edition has visual tools for transition functions, font tooling, flexbox, grid, clipping and pretty much every CSS nuance. It's also available for free and always will be, is decoupled from your source code (while still providing you with visually-edited code if you want to make a change permanent) and is built into a browser.
(Mind you, our visual layout tools aren't this powerful at the HTML/CSS level. We have a fairly simple drag'n'drop system, and if you want to get lower-level than that, then you'll be editing HTML and CSS as text. Gimli looks awesome.)
You might want to make the Kickstarter campaign more prominent - use color, make it bigger and part of the main content instead of just part of the top bar.
Anyway, as a mostly backend and native / non-web person who occasionally has to do front-end development, this looks like a very useful tool! Something like this might convince me to start using VSCode for web dev over vim.
I started trying to use VSCode’s vim bindings full time yesterday. The bindings themselves are pretty good, but VS Code is so slow compared to vim!
I’m editing Typescript. Frequently my key presses lag for tenths of a second, or auto insert some unrelated identifier. I’m going to give it a week before I go back to nvim and Coc.nvim
Figma/Sketch don't use the box model. They are modeled after illustration programs. In fact Sketch IS an illustration program that like Photoshop before it got pressed into UI duty.
I hope not. It's a very lousy and frustrating illustration program. I'd rather design whole interfaces in Adobe Illustration that draw even the simplest shape in sketch.
Hey, this looks really neat! I have a few questions though.
1. If I use this tool, can I still collaborate with people that don't have it? This might be a concern to maintainers of free/open source projects who would like to use Gimli for themselves but not force others to use proprietary tools (which, I assume, Gimli falls under) when editing the project's source.
2. How does this handle components (when using a framework) that aren't presentational (like container components in React/Redux apps that subscribe to the store and pass data on)? Will you just be able to "drag them in" like visual components? Will there be an ergonomic way to add them into the tree later? (So that the designer can, for example, just focus on the visual aspect, then pass it on to a developer who adds the containers)
Very cool demo. Great idea to build on top of VSCode distribution channel/platform, but I'm curious on how you plan on enforcing payment?
edit: Also curious how you'll be implementing "find source" - just doing a string lookup for id/classname/attibutes? Will you be able to handle generated identifiers, e.g. css modules classnames?
You might want to consider a name change. Gimli has already been used for a cryptographic algorithm from a pretty famous team of cryptographers[1], so your SEO might take a hit by using that name.
(We've taken Show HN belatedly out of the title above.)