6 ms·
These days, most people seem to be ok with having a compilation step in their workflow. I don't. I'm way more productive with a lighter stack. I stick to plai
by TekMol 8y ago
These days, most people seem to be ok with having a compilation step in their workflow.
I don't. I'm way more productive with a lighter stack.
I stick to plain Javascript. Sometimes I add a lightweight framework like Vue that I can simply include.
Are there more of us out there?
- phamilton 8y agoDo you use an IDE?
- TekMol 8y agoNo.
- finaliteration 8y agoI’m genuinely curious: Why are you not okay with the compilation step? I work primarily as a developer using compiled languages so I may be missing something.
- TekMol 8y agoThere are many aspects to it. From setting up a new project to 'edit a line and reload in the browser'. Everything feels so much faster, lighter, fresher.
- deleted 8y ago[deleted]
- stefanfisk 8y agoI'm one of many who don't seem to understand your point of view. how would editing and reloading be faster than hot reloading? I usually edit my styling live in Sublime while viewing the changes in Chrome.
- deleted 8y ago[deleted]
- TekMol 8y agoStyling?
- stefanfisk 8y agoyep, as in style sheets. personally I prefer Sass before native CSS, so I usually use the broader term to avoid assumptions about the technology stack used.
- szatkus 8y agoI usually write down styles to some kind of Notepad and then rewrite it to sass. At the beginning it was annoying, because I was forgetting that my css will be reloaded, but I got used to it.
- spankalee 8y agotsc --watch is incredibly fast. And you don't need a bundler and hot-reloading. Just stick to JS modules, output JS modules and let the browser take care of it.
- peterkelly 8y agoBut when you use a tool like webpack it's even simpler - you just save your file and it recompiles & reloads. You can also run 'tsc -w' (watch mode) and it will automatically recompile as soon as files change. And since doing so maintains a local cache of the compiler's state in memory it's extremely fast. The tiny amount of time I spend waiting for compiles is several orders of magnitude less than when I had to deal with the lack of static typing, particularly when refactoring code.
- ww520 8y agoFast REPL cycle.
- scandox 8y agoIf you've made the right choice for your workflow and project type then you'll never be alone.
- elboru 8y agoLegit question, what don't you like about it and why?
- RobertRoberts 8y agoI am moving into ES6 modules and the very notion of trying to use Babel or other post compiler to support older code styles seems archaic. It reminds me of the smell of supporting IE6. My apps are all designed to run on the latest browsers. Maybe I am lucky this way, but I don't have to support browsers older than a few months for my key systems. Not sure about the OP, but for me, I've been around for almost 20 years on web dev front end stuff, and every time I review a compiler, a while later a new one comes along. And eventually every compiler I have tested/or reviewed is now out of style, or the version I tested had so many bugs, or NOW the default configs are perfect! bah. Burnt way too many times on this. I use absolutely minimal external libraries, and those that are, are already minimized. Eventually, when my systems get more wider spread and more devs involved, I think a build step for staging then to production will be useful though. (note, we do have a build step, it just doesn't use any front end compilers like webpack/babel)
- TekMol 8y agoI use the native modules more and more too. They are awesome.
- coltonv 8y agoIn my opinion the cost of setting up a compiler such as typescript ot babel is significantly lower than the benefit and organization that types, modules, and modern language features provide.
- marpstar 8y agoagreed. being able to rename a property with confidence is worth the setup time in and of itself, let alone all of the other benefits it brings along.
- bendavis381 8y agoSo presumably you write all your non-web stuff in machine code? Compilers are pretty common.
- TekMol 8y agoServer side code is different as the server usually starts an interpreter that compiles the file on-the-fly in case it changed since the last pageview.
- matt_kantor 8y ago> the server usually starts an interpreter that compiles the file on-the-fly You may already be aware of this, but you can set up the same workflow for frontend development (if you have a compilation step). "Watch mode" seems to be the popular nomenclature for this in the JavaScript community.
- eyko 8y agoIn production? I think I'm misreading your comments.
- navaati 8y agoWhat ? Interpreters are pretty common in the non-web world too…
- Sharlin 8y agoNot all people do code anything else than JS web stuff these days.
- Ajedi32 8y agoEven if you don't use TypeScript, don't you still need a precompilation step for minimizing your source files? I suppose can probably get away with plain, unprocessed JS files for small personal projects, but that seems rather difficult to maintain for anything serious.
- TekMol 8y agoI do maintain pretty big projects this way. Even though the js is not minimized, it is way smaller then what the competition uses. Companies these days throw together insane amounts of bloated code for no reason.
- dcwca 8y agoDo you reference all your source files separately with script tags?
- TekMol 8y agoYes. And again, we usually do way less http requests then the competition. Look at a single post on the new React based Reddit. I just did and got 65 http requests loading 1.6MB of data. It's almost everywhere like that these days. Too much tools. Too little concern for the actual outcome.
- joewrong 8y agothere are dozens of us
- ionforce 8y agoTo each their own, but I question the scale/stability of your work without participating in the world of JS compilation (and the subsequent benefits).
- cabaalis 8y agoThe only valid question of scale/stability is whether or not it scales/remains stable. I've personally achieved a couple million ARR with unminified, uncompiled javascript on the client. Edit:I will grant you that our business is processing-heavy, so the ratio of client JS to backend language is very low.
- tim1994 8y agoWell it really depends on the size of the project. For small project I agree but for larger projects Typescript really helps to produce better and more robust code (and also faster if it's well integrated into the editor like VS Code). I am currently rewriting a Firefox Extension in Typescript that started as a simple script and grew in complexity (quite a bit) to make it easier for others to contribute (it's open source) and understand the code and I wish I had started that way, it would have saved me quite a bit of work by now.
- blauditore 8y agoIMHO, it depends on what you're going to build. The bigger your application, the more you profit from features like static typing or automated tests. When building a highly interactive e-banking front end application, you may want to use some complex framework. For a mostly static website with some show/hide-toggleable areas, plain JS or jQuery is probably easier and quicker to use.
- ww520 8y agoYep. Same here. I'm not against compilation step. I have projects with compilation. But projects with minimal dependence work as well. E.g. the Firefox extension Tip Tab and Session Boss are moderate complex SPA, and I just used plain JavaScript, JQuery, and a small CSS framework to build them. Work very well.
- usaphp 8y agoFor smaller projects - sure, but for anything bigger than that it will take more time fiddling with JavaScript quirks then just use a preprocessor. Like with css compared to sass, I can’t imagine myself writing plain css anymore for any big project, it’s a nightmare to maintain and edit
- simplify 8y agoPlain CSS has actaully come a long way since SASS was first introduced. The only reason to use SASS nowadays is for their color functions (which is still a big reason unfortunately).
- bontaq 8y agoLordy, what? Webpack + hot reload makes the "compilation" step almost invisible / equivalent. I'm assuming this is just a troll comment.
- TeMPOraL 8y agoSo this is this week's recommendation? Last I checked it was grunt, or gulp, or something like that. I am forced to dabble with Node from time to time, and the effort to track what's this week's build chain is already too mentally taxing for me.
- mercer 8y agoFWIW I mostly run terminal commands defined in package.json. I agree that keeping track of the fancy build tool du jour is best avoided, if possible.
- bontaq 8y agoThese days it's easy to type into google "typescript starter" thanks to the excellent work of other people, which will inevitably include automatic reloading. You get better code pretty much for free.
- TeMPOraL 8y agoI'm not trusting those starters will remain up to "modern standards" for longer than couple of months.
- szatkus 8y agoI've used react-scripts for a few months. I have no idea how old it is, but it's pretty good. Maybe automatic reload isn't always working, but I can just reload the whole page if something is off and it's instantaneous.
- invalidusernam3 8y agoFor me, it depends on the project. I try to stick to JS for smaller, simpler projects, but anything large (or with potential to become large) I use TS. I've worked on some very large JS projects over the years and in my opinion it's really difficult to for a JS codebase to scale well. I definitely agree with being more productive with a lighter stack, but I do find the even though TS is slower to develop due to compiling, the quality of the code is usually better (especially with multiple people on a project).
- camelCaseOfBeer 8y agoDepends on the size of your project, size of the development team writing it, and more importantly the developers maintaining it. I am much more productive and grateful if the large project I'm responsible for maintaining is written in TS. The resulting conventions are more consistent and easier to follow than the code-golf fuckery I see so often in JS. My conclusion would be if you're creating a light application ultimately only you or a small team is responsible for, do whatever works for you. If you're creating some brand of enterprise battleship, do the next dev a solid and use Typescript.
- TeMPOraL 8y agoCount me in. I don't touch frontend if I can avoid it, and if I can't, I sometimes have to work with compiling to JS and bloated node-based stacks. But when I write any JS for myself, I tend to do it pure, with files delivered to the browser as written (no minification, no obfuscation). Not sure why I do it this way. For some irrational reason, I just don't like modern web tools. I don't use LESS/SASS either, prefering LASS (S-expressions -> CSS compiler library) in Common Lisp projects, and raw CSS otherwise. Part of the reason might be that I just miss the days when you could learn from "View Source" in your browser. A different part might be is that I don't understand why modern compilation to JS requires downloading many dozens of megabytes in hundreds of Node dependencies. That's just ridiculous.
- mercer 8y agoI'd say it's mostly irrational, but I do sort of get the feeling. It's true that many people who use, say, webpack will also just indiscriminately use heavy packages, complicated SASS/LESS setups, and whatnot. But that doesn't mean that using webpack means you have to do the other things. It's possible to use webpack and various other 'fancy' stuff without going crazy on the packages, and with sourcemaps you still get to 'view source'. Personally I find that the benefits of at least some degree of compilation are well worth the potential drawbacks. I am quite conservative in pulling in packages, I regularly use tools that show me visually which things increase the size of my payload, and the result is pretty nice. I can't imagine going back to using multiple script tags to include multiple js files. EDIT: I'll add that I do understand wanting to avoid all this. It probably does take a bunch of domain-specific knowledge to know what to do and not to do, and I myself have also been trying to avoid much of it by moving to the back-end.
- TeMPOraL 8y agoI'd love to read a guide into modern web that focused on establishing a leanest possible solid foundation for further work. Like, "this is the minimum setup to get minification of your JS and CSS; add this to get auto-refresh on file change; ...". Everything I've read so far jumps straight into downloading hundreds of megabytes of NPM modules. I just don't feel comfortable with all that code doing God knows what, God knows why.
- splintercell 8y agoTypescript is a boon to large projects. It isn't just about having a compilation process or something, but it's about the fact that a good type system (even like that of TypeScript) is like getting the compiler to do a lot of error checking for you without having to write the unit tests for it. But if the project itself is so small that you don't care about writing unit tests, then sure fine use vanilla JS.
- true_religion 8y agoWell when you say “I” do you mean that you work alone? I find when I do, I do not need type systems, safety checks, etc. to understand the code, but if I need to review others code them having type annotations replaces the documentation that they didnt write.