Jump to content
Sign in to follow this  
Guest Sehrish

Best Code Editor

Recommended Posts

Guest Sehrish

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

Share this post


Link to post
Share on other sites

Yep. Just play with different editors until you find one you like.

 

I've been using IntelliJ for years, but recently started using VS Code and quite like it.

Share this post


Link to post
Share on other sites

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 by rbrtsmith

Share this post


Link to post
Share on other sites

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 by Grant Barker

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 by Grant Barker

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Pretty much what @rbrtsmith said!

About the only stuff I do differently - we're using nigh****ch for e2e tests, although also played with cypress.io (we had some issues when trying it out though so put that on hold for now). Also I've been playing recently with styled components, which is a methodology that basically removes standard class names from your css and instead bundles your css directly with your React components.

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?

Generally speaking for me now, if I'm doing a front end style component, I'll be using the following tech in one form or another:

  • git (first thing I do, of course)
  • npm/yarn (I went back to yarn after using npm 5 recently. Yarn is nice. I don't think the differences between the two are that huge though really)
  • React
  • Jest (I agree with Robert - Jest has improved so much over the last couple of years that I now consider it to be the best test environment in JS. I use it for all unit tests and also for some integration style tests). I also setup code coverage, and because I do TDD, I make all builds fail unless everything is 100% covered. Can discuss why I like this as a separate post if people are interested
  • Enzyme
  • Eslint (I use the airbnb ruleset)
  • Prettier - I <3 prettier
  • Webpack
  • Npm scripts - I use these for all tasks. Haven't used grunt or gulp in ages
  • CircleCI for CI - CI is essential, and Circle makes it really easy. I've also used bitbucket pipelines in the past, which is also great, but unfortunately quite restrictive on their free plan
  • Docker - I tend to wrap everything up in Docker containers these days. Makes testing on CI a trivial thing, as Circle has first class support for Docker.
  • Babel - for transpiling ES6 to ES5
  • Styled Components - Something I've only just started playing with, but I'm liking what I see so far...

For backend stuff, it's quite similar. I'll maybe use express or hapi.js if I'm creating an API. I'm finally looking into GraphQL now too (only took me what, a year or so eh @Jack?)

I'm building an app in what little spare time I have. To be honest I started on it like a year ago and then forgot about it. Keep coming back to it in small increments though, and because I'm using it as a means to learn new stuff I've still gained loads from it - I got pretty good with Docker by playing with this for example, and that's paid big dividends in work over the past couple of months.

I'm also using VS Code for everything now, and I must say I've become a big fan. I love it.

 

Share this post


Link to post
Share on other sites
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 by rbrtsmith

Share this post


Link to post
Share on other sites
46 minutes ago, rbrtsmith said:

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.

It's early days for me for sure. I literally tried it for the first time yesterday, after somehow convincing Katie to give me a full day to do some work. In that short time I read up on both CSS Grid and Flexbox and then built a basic front end for my Wishlist app using CSS Grid for layout and Flexbox for the middle container. I know (as we spoke on Slack yesterday) that you don't believe CSS Grid is ready for production yet, but after watching this video I think it may well be time to start trying it out on real sites: 

According to the video, you can quite easily create fallbacks using Flexbox that may not be identical, but will be "good enough" for browsers that don't support grid.

Again though, I'm no CSS expert and don't claim to be. What I did find exciting using styled components was the fact that the architecture concerns basically go away. I also like the fact that a component truly is an encapsulated component.

I actually had fun playing with all this stuff yesterday. Even used Yarn instead of Npm, and think I may continue down that route for now. For one, I simply prefer "yarn [mycommand]" over "npm run [mycommand]". I know there are other more compelling reasons to use Yarn, but little things like that make an impression.

With regards to the performance issue - Styled Components does allow for server side rendering, so perhaps that would mitigate against that issue somewhat? https://www.styled-components.com/docs/advanced#server-side-rendering

I do understand what you are saying with regard to learning BEM and so on, but surely those tools are there to fill a need? If CSS didn't suffer from the problems it has, BEM wouldn't need to be a thing. I feel like the CSS in JS approach makes CSS more accessible to people like me again. You're right that people should understand the technology properly, of course, and BEM and ITCSS are great for traditional code bases, but when living in a component based world, it does seem to make a lot of sense to me to componentise the CSS in the same way we use JSX.

Btw, what do you think about this: http://www.material-ui.com/#/

I suspect you won't be a fan of the material ui stuff as it obviously comes with styling a bit more in the bootstrap style. I spent quite a bit of time trying to make a material like component yesterday, then stumbled across this. It can be used with Styled Components, so I'm planning to use it a bit in my app.

Fact is, someone like me is likely never going to be a CSS expert. I've always much preferred the backend side of things. The problem for me right now is that "backend" used to mean PHP/MYSQL and being able to setup perhaps a single server, or a couple of servers with a load balancer in between. These days it's all about the cloud, and I've not done much of that stuff at the BBC, so in an attempt to get a bit better at the front end stuff I've come back to CSS for a bit. Styled Components seems like a great fit for someone in my position.

I would prefer however, to have a CSS expert such as yourself or the guy we have in work sat alongside me in a professional environment though.

Share this post


Link to post
Share on other sites

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 by rbrtsmith

Share this post


Link to post
Share on other sites
On 29/12/2017 at 11:04 AM, rbrtsmith said:

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.

I think there are more advantages to the markup issue than meets the eye. It's not just about removing a tiny amount of data for the client - the fact that your design is less tied to the structural makeup of the page has implication for better responsive designs, and better designs in general.

Consider this example. Here are two examples of markup that create the same design. One is done in a pre css-grid world using bootstrap. The other, using css-grid:

<!-- Bootstrap -->
<h1 class="title">BOOTSTRAP</h1>
<div class="row">
  <div class="col-xs-12 header">
    HEADER
  </div>
</div>
<div class="row">
  <div class="col-xs-4 menu">
    MENU
  </div>
  <div class="col-xs-8 content">
    CONTENT
  </div>
</div>
<div class="row">
  <div class="col-xs-12 footer">
    FOOTER
  </div>
</div>
<!-- CSS Grid -->
<h1 class="title">CSS GRID</h1>
<div class="wrapper">
  <div class="header">HEADER</div>
  <div class="menu">MENU</div>
  <div class="content">CONTENT</div>
  <div class="footer">FOOTER</div>
</div>

<style>
.wrapper {
    display: grid;
    grid-template-columns: repeat(12, 1fr);
    grid-template-rows: 40px 100px 40px;
}

.header {
    grid-column: span 12;
}

.menu {
    grid-column: span 4;
}

.content {
    grid-column: span 8;
}

.footer {
    grid-column: span 12;
}

@media screen and (max-width: 480px) {
    .header {
        grid-column: span 6;
    }
    
    .menu {
        grid-row: 1;
        grid-column: span 6;
    }
    
    .content {
        grid-column: span 12;
    }
}
</style>

The css-grid design is much more flexible. Consider that media query - that will result in the menu moving up to the first row and taking up half the column space with the header at that breakpoint. This is not possible will pure css in the first example, but would instead require some hacky Javascript.

So the removal of markup means that the layout is better defined in css as opposed to in the markup itself, which leads to more flexible designs and a better separation of responsibilities.

Edited by citypaul

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Recently Browsing

    No registered users viewing this page.

  • Member Statistics

    • Total Members
      57,553
    • Most Online
      4,970

    Newest Member
    Skilton06
    Joined
  • Forum Statistics

    • Total Topics
      65,740
    • Total Posts
      455,352
×