Hi,

 

What is the best code editor? I am using sublime text 3 for now as it has The Package Control and fast as well but want some suggestions over this.

 

Thank You in advance

The best is the one that is most suited to your needs. for me it is Atom.

Thank you for sharing your views and suggestion.

I am using textWrangler. It sounds good for me.

For me it depends on the task at hand, I flitter between NP++, DW, Atom and Sublime.

I have been using Dreamweaver 8 for many years, it still does the job.

Depends how you use it. The WYSIWYG editor can create rubbish code.

Going from VSCode to something like Dreamweaver would be like stepping back into the dark ages.

 

DW won't support things like ESLint, ES6 or JSX code highlighting, test suite integration, built in terminal and npm task runner, integrated Git tools. I'd find developing without these tools to be a nightmare.
What about intellisense? I bet it can't do any of that...

 

Essentially it's not a good tool for modern JavaScript development.

Edited November 17, 20178 yr by rbrtsmith

Yeah, I'm still using Dreamweaver to be honest.

Do the above programs you mention have WYSIWYG windows? (For want of better terminology)

If not, do you guys just code like pros, throw it online and it looks awesome?

Recently, I've been curious about the tidiness of my code.

I need to be able to see the results in real time though (WYSIWYG).

Also, although I love using Fireworks (believe it or not). it might be sensible financially to not be tied to Adobe Creative Cloud monthly subscriptions.

I'm pretty interested in some ideal options for my scenario.

 

Edited December 26, 20178 yr by Grant Barker

19 hours ago, Grant Barker said:

Yeah, I'm still using Dreamweaver to be honest.

Do the above programs you mention have WYSIWYG windows? (For want of better terminology)

If not, do you guys just code like pros, throw it online and it looks awesome?

Recently, I've been curious about the tidiness of my code.

I need to be able to see the results in real time though (WYSIWYG).

Also, although I love using Fireworks (believe it or not). it might be sensible financially to not be tied to Adobe Creative Cloud monthly subscriptions.

I'm pretty interested in some ideal options for my scenario.

 

No professional and dare I say very few hobbyists will use WYSIWYG editors these days.  We don't just code blindly we will use a web browser to see our changes.  We use tools to automate a lot of tasks that result in the application being updated in the browser when we save.
As a developer I rarely use any design software as design is not my job.  IMO you should learn some basics for HTML CSS and then JavaScript or just stick to design if that is more your thing.  Treehouse and Codeschool have good introductory courses for this.

6 hours ago, rbrtsmith said:

..We use tools to automate a lot of tasks that result in the application being updated in the browser when we save.

Thanks, Robert. That sounds like the kind of thing I was talking about. I've just installed Atom too, so I'll see how it goes.

Edited December 27, 20178 yr by Grant Barker

Interested to see if things have changed drastically on this front while I was away. I'm still using Visual studio code + gulp + git.

I know there were plenty of task runners rising this year but I've been pretty happy with gulp.

Brackets is another editor I liked but not as much as VS code.

5 hours ago, teodora said:

Interested to see if things have changed drastically on this front while I was away. I'm still using Visual studio code + gulp + git.

I know there were plenty of task runners rising this year but I've been pretty happy with gulp.

Brackets is another editor I liked but not as much as VS code.

Things have changed remarkably in the past 18 months or so in this area, here's a little glimpse into what I've been using day to day...

I use Yarn as my package manager and task runner.  It pulls packages from the NPM registry just like NPM does and can run scripts from your package.json.  It's faster and less buggy than NPM, although NPM is quickly improving.  Yarn Workspaces can be used for mono-repos (Multi package repositories), NPM has Lerna for this.

Moving on from the world of Gulp we have two things: Task runners and module bundlers.

NPM/Yarn are task runners, you can specify any task / bash command from the scripts section in your package.json.
Some common tasks might be: Running tests, running linting, removing some directories prior to a build, running a bundler, starting a server.

Webpack is a bundler, where anything can be seen as a module.  JavaScript, CSS, Fonts, Images... In it's simplest form you create a webpack config, provide an entry point and a destination for the bundle.  Your entry file (JavaScript) can be thought of as the root and other modules that you import can be seen as branches or leaf nodes (Essentially a tree data structure).
 

 

// index.js

import App from './App'
import styles from './styles.scss'

Webpack recognises file types by applying various loaders that are mapped to file extensions with a regex you provide in your webpack.config.  You would use a sass-loader to load sass and the output of one loader can form the input of the next, so a sass-loader can be piped into the css-loader and so on.  JavaScript you might pipe through the babel-loader to transpile ES6 code into ES5.

This has many benefits over gulp as it allows you to use ES6 / CommonJS modules to structure your application and webpack is insanely powerful with features such as code splitting allowing you to create per-route and vendor bundles, bundle the Sass with your JavaScript or split it out, Image imports can be converted to inlined base64 images.  It ships with tree-shaking which can remove unused portions of packages that your app depends on.  Webpack can be easy to get a basic thing going but can get complicated, but that's to be expected as it solves some very complex problems.

For JavaScript I use Babel to transpile my  ES6/7 code into ES5.  I use a preset called "env" that works much like Autoprefixer (PostCSS) in that it only transpiles code that is not understood by the browsers I currently support.  This links into the caniuse db so is continually kept upto date.  I also use Babel to transpile JSX that I use for my React Components.
ES6 is incredible, if you don't already know it, learn it!  Kyle Simpson has recently released a book on it, and Wes Bos has a course on it.
My Framework of choice is React, when needed I have found Redux to work really well for state management.  I am using a tool called Jest to run my unit tests, which again is an incredible tool and blows away all the other test runners in my opinion.  I use Jest to run unit/integration tests for both server-side and client side code.  I have used Nightmare.js for e2e tests but looking at Cypress as a new tool to try out there.  To test my React components I use a package by AirBnb called Enzyme.  Again superb tool.

Eslint is a really nice tool for linting your JavaScript, it's highly customisable.  I use AirBnb config here again.  Worth mentioning Prettier as a nice code formatting tool.  Both of these have VSCode integrations.

I still use Sass for writing CSS as I think it's still one of the best ways to write your styles provided you roll with a decent architecture and naming convention like ITCSS & BEMIT.  That said I think some of the CSS in JS solutions are becoming more compelling.   I use StyleLint to lint my styles.

Most of my repos now employ continuous integration - this uses online tools like CircleCI / TravisCI that clone down your repositiory into an environment that should mirror that of the server you intend to deploy to and can run your tests, linting.  This way you only merge your branch into master if the CI passes.  It's recommended that you peer review branches too, then once a change to master comes in, master is re-deployed to the live environment.

I've covered quite a lot here and no doubt missed some parts.  I hope one day to be able to teach this stuff to teams in more depth but that's quite some time away.  However feel free to ask any further questions you might have... My Github contains examples of my usages of the above tools.

7 hours ago, Grant Barker said:

Thanks, Robert. That sounds like the kind of thing I was talking about. I've just installed Atom too, so I'll see how it goes.

To be honest most of the inline browsers like the one in Dreamweaver render poorly, or at least they used to. If I remember they're not even close to what a modern browser can do feature wise.

If you write code in an editor like Atom, and preview in the browser, you're learning a better technique. By ditching the WYSIWYG tools you're forcing yourself to learn the syntax. You'll likely find like most people, you learn faster doing it this way, even if it takes some getting used to initially.

Thanks @rbrtsmith for the incredibly detailed answer. Things have certainly changed  

I see myself digesting your post and researching over the next few days  Thanks!

18 hours ago, citypaul said:

It's early days for me with the styled components, but so far I'm liking it. Css has always been a weak point for me (I hate it tbh), and Robert is definitely better at CSS than me, but having said that I like what I see so far - interested to know why you're not a fan (as far as I know) @rbrtsmith?

 

CSS in JS has come a long way, and Styled Components / Glamarous are definitely more compelling than what we had 12 months ago.
There are a few drawbacks however:
* Code completion / emmet, code highlighting - this doesn't currently happen (to my knowledge) because you are just writing a JavaScript string.  This also prevents your ability to lint the styles.
* Styled components are tied to React - which is fine if you are building a product.  But I typically build frameworks and as much as I like React I like the fact that Nebula is totally framework agnostic.
* The biggest drawback - Performance, styles are bundled alongside the React components and thus you have to wait for the JS to load and parse before anything renders.  With traditional CSS you can put the reference to the stylesheet in the head and show something to the user before the JS bundle has been downloaded & parsed giving the illusion of a much faster page. 

The above isn't to say styled components is necessarily a bad idea.  I think it's great for teams that don't have much experience architecting large CSS codebases.  But for a team that are the naming benefits that it brings isn't that much better than ITCSS and BEMIT conventions and with the drawbacks it has I personally won't use it in production but I can totally understand why some teams will.

Edit - I should mention one thing that frustrates me about the CSS-in-JS community in general is that they claim that these solutions are the best or only way to write scalable styles which is simply not true.  It's just another tool, another way of doing things.  It might be the best approach for some teams but it's not as universal as many of these claims make out.  By all means use and play around with Styled Components but don't buy into the Dogma.  It's well worth taking the time to learn good CSS architecture and then make a decision rather than blindly agreeing to these claims that are made.

Edited December 29, 20178 yr by rbrtsmith

I've covered this a few times but Flexbox isn't great for full page layouts as it has performance issues when it comes to layout thrashing, it's better used for smaller sections of content.

The issue with CSS-Grid as it stands is that you have to write fallbacks which is doubling your effort - whereas ES6 for example the transpilation . / polyfills are done via an automated process.

Using existing tools it's possbile to use a huge array of complex layouts as the grid and flag object in Nebula demonstrate.  The world is moving towards CSS-Grid and it is an improvement.  But having to spend time writing fallbacks for it at this stage outweigh the benefits.  Lots of people are suprised when you see that many layouts that include things like ordering and vertical alignment were already possible without CSS-Grid and Flexbox.
We spoke about having a declarative API,  but once you have components built around traditional CSS then things again become declarative as the CSS is abstracted away from the consumer.

You mentioned in our conversation that CSS-Grid uses less markup and I can't deny that, however in the scheme of things it's not a huge win.  a <div> has no semantic meaning and worrying about having a few extra divs on a component is getting into the realm of premature optimisation.  It's a very small benefit.  The main benefit of CSS grid is it's declarative API.  However once things are abstracted away into a framework it doesn't matter too much about how declarative the underlying CSS really is.

Again it's a cool technology and definitely worth learning in the long term but right now I wouldn't use it in production as the cost currently outweighs the benefit and there are bigger fish to fry where time is better spent.

Edited December 29, 20178 yr by rbrtsmith

On 31/12/2017 at 1:32 PM, citypaul said:

Also the browser support is good already, and there are relatively cheap and easy fallbacks you can create using flexbox for example.

I think the arguments for using it in production shouldn't be sniffed at. I'm planning to use it for my own personal project.

You make a good point on the markup being less tied to the layout however with fallbacks again I would not recommend Flexbox for full page layout as it has thrashing issues especially when content gets rendered asynchronously.  Jake Archibald has written about this quite extensively.

CSS Grid is the future, and it is sort of safe to use in production but I still don't think it's worth the trade offs just yet - not until browsers have full support as the fallbacks mean duplication of efforts and extra markup / flexbox issues for those fallbacks.

26 minutes ago, rbrtsmith said:

CSS Grid is the future...

Anything that gets rid of awful bootstrap sites has got to be a good thing

10 hours ago, fisicx said:

Anything that gets rid of awful bootstrap sites has got to be a good thing

Bootstrap will still be around I imagine, they will just build a new grid.  If used properly it's not all that bad.  Just there are better alternatives than Bootstrap's grid.

Most of what you can do with CSS Grid you can do with old layouts.  The grid and flag object on Nebula demonstrate this - they can be composed together in thousands of different ways to build pretty much any layout you want.  Granted the underlying code isn't quite as clean as CSS-Grid but it works down to IE9.