No, writing your code in an editor and previewing the result in a browser is not "archaic"; it is actually the only sane way to create a website.
Kompozer — like its predecessor Nvu or Dreamweaver, the commercial software they are supposed to be an alternative to — makes a lot of compromises to give you a supposedly easy to use interface. The text editing is not as good as in an actual text editor (and Vim is kind of the gold standard when talking about editors), the rendering is not as good as in an actual browser, the generated code is often too verbose…
I started with Dreamweaver 2 back in 1999 but dropped it very quickly for a more bare bones workflow where I control everything. It made me a lot faster and a lot better.
And, well… the latest Kompozer release is from five years ago. It uses Firefox 2's rendering engine so you shouldn't wonder why your website doesn't look right!
In the mean time, front-end development has become a bit more involved than it used to be: preprocessors, watchers, hundreds of frameworks and libraries from tiny to huge, dependency managers, package managers… but the trend is somewhat funnily command-line-centered.
To the risk of being too caricatural, "modern" professional front-end dev is currently done like this:
- you have your project under some version control system (Subversion, Git, Mercurial, others…),
- you have some package manager to deal with your project's dependencies (npm, bower, others…),
- you edit your code in a text editor (Vim, Emacs, Sublime Text, Atom, Brackets, TextMate, VisualStudioCode, others…),
- you have a watcher running in the background, linting, testing, compiling your code and your assets (Grunt, Brunch, Gulp, others…),
- you preview your site in as many browsers as you can on as many devices as you can,
- you debug your code in the browser using its developer tools,
- you manage your deployment with some CI software (Jenkins, travis, others…).
And it looks the same on the back-end side.
Now, all that stuff can seem a bit too heavy for something as fundamentally simple as web development but, if you are a professional web developer in 2015 and don't use a variant of the workflow above, I really don't know what to say… you have a lot of catch-up to do.
The minimum you could do is…
- keep your code under version control and learn how to use it efficiently,
- edit your code in the most comfortable text editor you can find and learn how to use it efficiently,
- test your code in a web browser, possibly with an extension like Livepage or Auto Reload, and learn how to use its developer tools efficiently.
And forget about Kompozer.
Thanks for the insights. I come from a more performance driven software development angle (scientific computing using C, Fortran, MPI, etc.) and am very new to web development, so my go-to mode of operation is vim (edit) - make (build) - run (test) - see where it breaks (refine), but it didn't seem like that was the way to do web dev. A lot of that is because I don't understand CSS, divs, etc., but it sounds like I just need to do my homework some more on learning those things and (once they are learned) implement them in the same way I have been. – drjrm3 – 2015-06-21T20:51:59.890
Web development has been edit → test… for quite a while. Nowadays, it's moving a lot to an edit → build → test… model that is fundamentally the same as the one you are used to so yeah, time to learn HTML and CSS ;-). – romainl – 2015-06-21T21:01:51.447