Substitute for Dreamweaver

[Solar_Gary]

Hi,

This may seem like a strange question, but I'd like to know if there is a reasonable substitute for Dreamweaver out there.

I started my site around 2005 on Microsoft Frontpage, and to be honest for my modest needs, FrontPage was a really good fit.  But, then it was phased out for what ever they called the follow on version of Frontpage, and I converted over to that.  Then it was dropped.

At that point I'd had about enough converting the whole website over to something to new, so I bought a copy of DreamWeaver, which seemed to be the most stable product going.  Took a while to do the conversion, but got through it.  Meanwhile the site kept growing -- now over 1000 html pages (www.builditsolar.com).

Then Adobe switched over to the subscription model.

In the meantime my site is less active, and the only use I am really getting out of DreamWeaver now is some occasional updates and a new page once in a while.  The $240 a year seems excessive for my current usage and I'd like to find something that I cold maintain the DreamWeaver created site with that would not have a steep learning curve.  But, It feels like I'm pretty embedded in DreamWeaver with the templates etc. -- I can't do individual conversions to over a thousand pages.

I'm an engineer who would just like an easy to use tool to get some ideas out there for people who want to build solar projects -- have less than zero interest in writing html or other code.  The more it looks like a wordprocessor the happier I am.  But, it needs to be something that will accept the current DreamWeaver created site without tons of conversion work.

Any ideas on software I might try?

I understand DreamWeaver is a terrific product for those who need and use its many features.

Thanks -- Gary

[rayek.elfin]

It also depends on the code editor/IDE, of course. For example, Atom has a simple extension that is installed within seconds to automatically auto-prefix your css when it is saved (or a command is evoked). Install, change one setting, and you're good to go.

So yes: it is definitely possible to integrate said functionality in the coding environment. Other tools have it. Why that's not done for DW? No idea. One part of the answer is the relatively small community. I remember a time when the situation was quite different, and many extensions were written for DW by the community for the community. I believe Adobe ruined that with their actions.

[B i r n o u]

what happen to the prefixed line... once the file is saved... are they still present in the CSS file... does this mean that the extra lines added by the prefixed value are now full part of the CSS file...?

if that is the case that is why I do'nt want to use any inbuilt tool ... does this makes sense ?

[rayek.elfin]

https://forums.adobe.com/people/B+i+r+n+o+u  wrote

what happen to the prefixed line... once the file is saved... are they still present in the CSS file... does this mean that the extra lines added by the prefixed value are now full part of the CSS file...?

if that is the case that is why I do'nt want to use any inbuilt tool ... does this makes sense ?

Yes, the original CSS file, when saved, is automatically prefixed. I understand your point all too well: I myself do not use it either, because it should be a post processing action, and I don't want it to touch my original source files. It becomes too unwieldy to edit during development

[osgood_]

rayek.elfin  wrote

Yes, the original CSS file, when saved, is automatically prefixed. I understand your point all too well: I myself do not use it either, because it should be a post processing action, and I don't want it to touch my original source files. It becomes too unwieldy to edit during development

And what is wrong with the option to add the prefixes directly to the css file at a point when it suits yourself if you dont want them added on each return or save?

You probaby dont even look at the css file if youre using sass or less anyway so its not a great problem if thats your  chosen workflow.

Id be more concerned with the bloated code Bootstrap adds to the html.

[B i r n o u]

clear... thanks for the heads up...

[pziecina]

I don't understand your objections Birnou?

With a proper in-built autoprefixer, it is possible to turn off autoprefixing, then just apply it to the final version that is to be uploaded to the server. The option to add autoprefixing to every save is there, (and only to apply it to a selected portion) but it is a user selectable option not a do on every save only option.

[B i r n o u]

now it's me that don't understand you Paula... ...

once you applied it.. because it's production time.. so far so cool... but does this also mean that the project is over... wont move, wont evolve... wont update... arf arf...

so back to your css file, you will have to stuck and do with all the prefixed value...

say now ... your target in statistic demonstrate that you wont need anymore a specific prefix... so how to you remove this target.?.. hmm...wait and see... hmmm you said remove the prefix for which property... hmmm... welll let me think about... ????

no I was joking... I know that you personnaly use browserlist... so you will regenerate the production file automaticaly with autorpefixer...

but what's about the inbuilt tool... are you still searching a way to remove the outdated prefixed value ?

[pziecina]

I'm used to working with a version control, repository system, (have not used git for years, but could be used) and once testing is complete all files are copied to the versioning server and locked, (required passcode to unlock). The  working files then have the autoprefixing applied and are transfered to the repository for use.

The above is a simplified explanation, but i hope you understand the workflow used.

[osgood_]

Why are you concerned about removing an outdated prefix value, it does no harm at all. Id hate to guess at all the redundant css and code which the majority of websites use. I mean if you regularly update, delete a section on a page which uses specific css  does anyone bother to hunt down the associated css and remove that from the css file, in most instances although they should they most probably dont.

[BenPleysier]

Why are you constantly being moderated? It takes too much of my time to release it from the queu.

[osgood_]

BenPleysier  wrote

Why are you constantly being moderated? It takes too much of my time to release it from the queu.

I dont know, switch it off if you have the authority. Maybe its because l can get a bit vocal regarding Adobe at times but l cant think at anytime since l lost my MVP status, some months ago, that l have posted anything controversial in terms of other participating members. Mostly helpful posts really or just debating.

[BenPleysier]

osgood_  wrote

I dont know, switch it off if you have the authority. Maybe its because l can get a bit vocal regarding Adobe at times but l cant think at anytime since l lost my MVP status, some months ago, that l have posted anything controversial in terms of other participating members. Mostly helpful posts really or just debating.

Agreed. I don't have the authority so I'll just move them on when I see your posts in the queu. All in a day's work.

[pziecina]

I'll try PM'ing Preran when he gets back from his vacation to get the moderation removed, as it was originally place on Os by Adobe senior staff, so will require senior staff approval to remove.

[B i r n o u]

we have certainly a different approach of the development, I like my production code being clear and uptodate

[osgood_]

https://forums.adobe.com/people/B+i+r+n+o+u  wrote

we have certainly a different approach of the development, I like my production code being clear and uptodate

Well l think everyone thinks their code is clean but in reality its not. I like to take a more realistic approach, l do my best but its never perfect.

[pziecina]

osgood_  wrote

https://forums.adobe.com/people/B+i+r+n+o+u   wrote

we have certainly a different approach of the development, I like my production code being clear and uptodate

Well l think everyone thinks their code is clean but in reality its not. I like to take a more realistic approach, l do my best but its never perfect.

I'm going to throw a very good reason why i think an autoprefixer that DOES apply the prefixes on every save or to a selection, is required.

I used to use Dw to experiment with new css and create 'ideas' for there use. This meant that it required all browsers and devices to be tested to have the prefixes applied, so that i could experiment with the various options from one environment, and check how each browser/device interpretated them.

Without having an autoprefixer option, doing this is impossible, or very time consuming. All i can think of for not working with and experimenting with new features, without an autoprefixer, is that people do not experiment with new features or wait until they are no longer required and someone else has done the ground work for there use, which can often be years even when a feature has over 99% browser/device support, though not the same in every browser.

Whilst it is still true that various browsers/devices also use vendor specific css, that are not part of the specs, or will be writen as a spec in a different form at a later date, prefixing will always be necessary. Asking anyone to change their workflow just to accommodate a development programs lack of support for anything is never an option, especially when the incorporation of the feature is possible, and especially in these times.

[osgood_]

pziecina  wrote

Asking anyone to change their workflow just to accommodate a development programs lack of support for anything is never an option, especially when the incorporation of the feature is possible, and especially in these times.

Agree, nothing more l can add.

[osgood_]

https://forums.adobe.com/people/B+i+r+n+o+u  wrote

what happen to the prefixed line... once the file is saved... are they still present in the CSS file... does this mean that the extra lines added by the prefixed value are now full part of the CSS file...?

if that is the case that is why I do'nt want to use any inbuilt tool ... does this makes sense ?

The prefixes get saved to the css file , thats the point isnt it? What use is it if when you save the css file the prefixes get removed.

The css prefixes dont get removed from the css file when you use sass, less or autoprefixer do they. The point here is you dont work directly in the css file, you use sass or less which is fine for those that choose that workflow, so you dont have to deal with the prefixes in your face. For those that just want to work with the css file thats an issue they will have to deal with. Since my css files are well organised and arent exactly huge l personally dont find that a problem.

[B i r n o u]

I am sorry but you mix concepts and affirmations that I made. It's confusing and you miss some of the critical points that I'm trying to put forward.

we are talking about two different concepts that generally employ two different processes

using an embedded tool to auto-prefix declarations is likely to work on a single CSS file, which will be both use in development but also use in production ... so the extra lines will be part of our daily life, being systematically present once they have been applied, and we will have to do with all this rather verbose code ...

the tools of types sass, less, or autoprefixer, they generally make a big distinction between the file used during the development and the one sent and used on the server in production. so certainly the famous 'extra lines' generated by prefixing will be present ... but only on the file used in production ... and will not obscure the one used in development.

now please do not talk to me about sass or less ... I'm talking about autoprefixer ... do not mix them... please...

using autoprefixer requires a single click on a batch process ... if you do not want to open the command line use a .bat under windows and a .command if you are under mac... and that's it... being external allows us to update when ever we want, when ever it is available on github... not have to wait after Adobe to integrate it... and plus... it allows us also if we want to work with what ever atomator or process that we like.... now we can go back to and speak about sass... and ruby...

[osgood_]

https://forums.adobe.com/people/B+i+r+n+o+u  wrote

I am sorry but you mix concepts and affirmations that I made. It's confusing and you miss some of the critical points that I'm trying to put forward.

we are talking about two different concepts that generally employ two different processes

using an embedded tool to auto-prefix declarations is likely to work on a single CSS file, which will be both use in development but also use in production ... so the extra lines will be part of our daily life, being systematically present once they have been applied, and we will have to do with all this rather verbose code ...

the tools of types sass, less, or autoprefixer, they generally make a big distinction between the file used during the development and the one sent and used on the server in production. so certainly the famous 'extra lines' generated by prefixing will be present ... but only on the file used in production ... and will not obscure the one used in development.

now please do not talk to me about sass or less ... I'm talking about autoprefixer ... do not mix them... please...

using autoprefixer requires a single click on a batch process ... if you do not want to open the command line use a .bat under windows and a .command if you are under mac... and that's it... being external allows us to update when ever we want, when ever it is available on github... not have to wait after Adobe to integrate it... and plus... it allows us also if we want to work with what ever atomator or process that we like.... now we can go back to and speak about sass... and ruby...

I dont need you to tell me how l should be working thanks. I have no issue with the prefixes being part of the css file. I have an issue with not being provided with that option in a simple way without having to use 3 party deployments which is what l term as bloated workflow.

As l previously stated getting autoprefixer into the workflow was a non option. If you can point me to an autoprefixer plugin great, if not then dont bother.

[B i r n o u]

maybe the translator is not really adhoc ... but since the beginning of this exchange I try to be polite, respectful and constructive ... by developing work processes to improve the quality and comfort of work ... but I do not feel in your last answers calm and kindness ... I am sorry

[osgood_]

https://forums.adobe.com/people/B+i+r+n+o+u  wrote

maybe the translator is not really adhoc ... but since the beginning of this exchange I try to be polite, respectful and constructive ... by developing work processes to improve the quality and comfort of work ... but I do not feel in your last answers calm and kindness ... I am sorry

I dont know what l said to upset you. Just asked if you could point me to a plugin for Autoprefixer as lve been down the route of trying to install autoprefixer unsuccessfully in the past.

[pziecina]

osgood_  wrote

Ok if its too difficult then lets clarify that and ill back off about it but having seen Coda address this to a limited extent some years ago I would assume it is possible.

It is possible, i will even give you the xml code to do it in Dw.

You will not be able to install it as Dw's documentation is useless now, and there is no extension manager, (except 3rd party). The only way is to insert it directly into the actual Dw file in the relevant installation folder

[B i r n o u]

what ever inbuild tool, you'll use there are two main problems... at least for what I think... of course, I can be wrong...

1 - the inbuilt tool that generate the prefix, for what I think should generate extra lines (the one for the prefixed value)... if  CSS are wrote in a plain CSS file... that do mean that once the inbuilt tool will be run, the next time that we open the CSS file , we should have something like

prefixed-property:value; property:value;

that makes an extra line, extra line that will stuck in the CSS code... and if the prefix is multiple... and present in multiple rules that will drive to produce a bloated full page... prehaps that I'm miss something ?

2 - when css will propose a new property.. that do mean, that as DW will use an inbuild tool to generate the prefixed values, DW users will have to wait that Adobe update DW to integrate the new process in the inbuild tool... and that's not interesting.... again, I also can be wrong...

now back to autoprefixer, I 'm sad to hear that you have find trouble on the how to use it... it is so usefull and it can be use in so many way... perhaps the simplest one will be to run it throught postcss ? at least just to give it a try

if you wish, I can write a simple tutorial from scratch just to help you to see what it is about ?... just let me know

[pziecina]

The problem with any autoprefixer solution that is not 'built-in', is that one must point the utility one is using to the css file, and then give another file for the output.

True with postcss it is a file with just the css file extension, so one can use the same file for both source and final, but it still requires setting up to point to each individual site structure, a problem that one does not have if the feature is built-in, as that can be configured directly from a menu option, (at least it could be if Dw updated its extension documentation, and had an extension manager).