In 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.
Even 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.
I 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.
While I do agree that your approach leads to good result, I still don't see why you wouldn't add a compilation step to minimize/tree shake/TypeScript/etc.
If you're good enough to be conservative in what you pull in, you'll still be that, except you get to benefit from all the things a compilation step can offer. It still strikes me as a somewhat arbitrary limitation to impose on yourself.
I use webpack for almost all my projects, and TypeScript for a bunch of them. I'm also very mindful of what packages I use and the result is nice little bundle. I wouldn't be able to get the results I want if I limited myself by not having a compilation step.
And to expand upon pjc50's comment, the mobile experience still pushes the app, even though I'm logged in and always dismiss it.
(I know full well why they want people to the install the app, but I still find it unfortunate that they a) don't remember that I dismiss it/have an option to never ask me and b) despite the redesign and having a relatively good mobile experience (assuming you didn't first hit an `amp.` link) still push the app.
And by better you mean worse? I second 'pjc50 here - new Reddit is slow on both mobile and PC, inefficient to read (wastes a lot of space), has questionable interactions thanks to JS abuse, and generally turns what was a condensed link aggregator into a poor Facebook clone.
Same here. We have 140k monthly active users. Just using unminified JavaScript and script tags to include other JS files. Most just because I wrote it and I'm a backend engineer.
I developed a 500.000 line js front-end without a build step (only a minifier/bundler for production releases, nothing in dev). We did have an on-demand loader to bring in modules as needed. It’s definitely doable though I do prefer to use typescript myself for large codebases.
Well 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.
So 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.
I'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.
These 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.
The 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.
IMHO, 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.
Count 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.
I'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.
I'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.
Yeah, agreed. It's definitely true that going down the Webpack/compilation road sort of automatically sends you down a path of heavy, complicated solutions. Maybe what you describe could be something I could finally decide to blog about :).
I’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.
There 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.
I'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.
I 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.
yep, 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.
But 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.
I 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)
Well 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.
For 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).
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.
Yep. 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.
Server 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.
> 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.
For 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
Plain 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).
What is the most effective way to get into TypeScript for programmer with pretty solid Java background? Are there any canonical books, educational OSS projects or perhaps another references?
Start with a project in vanilla JavaScript (try to write your code in an idiomatic JavaScript style). Keep building on it until it gets difficult to manage, then go add TypeScript to it.
If you're not a JavaScript developer then that exercise will help you understand what a typical JavaScript project look like and where TypeScript adds value. I think that, as a Java dev, if you just start by writing TypeScript you're liable to write code that looks a lot like Java. Doing it this way helps you see TypeScript as "JavaScript with Types" instead of "Java in the browser"
I'll second this approach provided you have some 'downtime' to work it all out. Things are much better now than when I started with TS, but it can still be a lot to take on all at once.
Using TS from the start probably affects how you write your code, and it's definitely easier and less daunting to be faces with a ton of 'problems to fix'. But learning how to add TS to an existing project is a valuable skill to have.
Assuming you know JS already, TypeScript is quite easy, IMO, and the integration with VSCode is really nice. Just open up a .ts file and let the compiler teach you.
Do try to remember that the Javascript build tooling mess is not Typescript's fault.
If you just want to play with and learn Typescript, don't try to figure out the "right" way to build your project - just do whatever works for you while you're learning.
The main documentation is a good place to start. Really all you need is that and Visual Code https://code.visualstudio.com/ and you should be good to go.
Personally I use Sublime these days, but Atom and Visual Studio Code are also excellent choices. I'd say they're all tied pretty closely for the leading spot, so the choice is really a matter of personal preference.
