Starting a new JS project these days can be a huge hurdle for many users because they have to manually set up all the compilation/linting/testing/formatting etc infrastructure, each of which have multiple possible libraries, versions, and non-trivial configurations. You could spend a week configuring webpack alone to get code splitting, css compilation, etc to work. Projects like create-react-app and next.js have helped remove some of this fatigue, and you can see by their adoption just how much of an impact this has. Seems like Rome should be similarly beneficial without being inherently tied to an application framework like create-react-app or next.js – the challenge will be avoiding a confusing mess of 1000 configuration options to fine-tune each subsystem.
This is exactly it for me. Just setting up my project took well over a week (not like I couldn't do anything before that week was over, but getting everything how I wanted it was very non-trivial). Granted, a lot of it was because I was new to TypeScript, but I also got into a bunch of version hell trying to get TypeScript/Prettier/ESLint/VSCode to all work together on my machine because there were a bunch of version incompatibilities when tslint was essentially deprecated in favor of eslint for TypeScript.
I'm building a no-code web app development platform. There are numerous existing tools in this space, but I don't think anyone has really hit the sweet spot of having the same composability/reusability/conditional benefits of code in a WYSIWYG interface that drastically increases development speed.
Also happen to be looking for a cofounder as well. I'm a developer myself but I'd love to partner with another product-minded dev or a product person with significant industry experience. Let me know if you're interested.
I just listened to the JRE clip from that ep(https://www.youtube.com/watch?v=l2AbxWr6I4s) - Everyone Can Be Rich. And based on the below excerpt in which he misses the mark by a million miles, I'm doubting his wisdom.
from 02:13 on ..
> okay imagine if tomorrow we could wave a wand and everybody was trained as a scientist or an engineer everybody, even if you weren't very good, you had enough understanding computers you could write some code.
You could build some hardware and don't tell me people can't do it because they can that's just a tyranny of soft expectations.
That's just you looking down on somebody else they can't do it they just have to be educated. Now if they're educated all this hardware software engineers scientists biologists technicians hard sciences not the social sciences we would all be done within five years. Robots would be doing everything from cleaning toilets to cooking food to flying airplanes and driving goobers and what would we be doing? We would be doing all creative jobs to entertain each other and researching science and technology we would have wonderful lives so it is really just a question of Education nothing else is this a scale issue
My (rushed, sorry) take is that Naval expresses a rather naive take on the future.
I've seen this sort of scenario promised for 5 decades now, and while the technological benchmarks get met, most people are still slogging away in boring office or technical jobs, just the same.
This dream would also require a different form of government and economy. As I see it, it will require some heavily state-controlled economy or a substantial Universal Basic Income.
Capitalism isn't exactly going to thrive under the pseudo-gig economy that Naval's take suggests. Most people will continue to have regular, necessary monthly expenditures. And, they are not going to be saving money as a cushion, they're going to be buying the new iPhone/Watch/AirPods/TV/Shiny Thing over and over again every year.
And while I love Naval, I see these naive takes of his , quite often. But that's OK, because it still provides me with food for thought and hey, sometimes I find I'm wrong myself.
This is one of the strongest cognitive dissonances that I have. And I have no idea why it exists. I know that rationally, tabs are really the better choice. Each user can choose how to display code in their editor.
But I just hate using them.
Maybe it was the 8 space default of vim (nano?) when I was sysadmining. Maybe it was that there was inertia, and tabs are always the thing that's causing problems. But I just can't get over it. I just don't like tabs.
I've never understood the dislike of tabs; when I was first presented with the concept of spaces-over-tabs I was new to the industry and went along with it, assuming there was some good reason. But I've never actually found one. Tabs are so much more semantic.
In my experience, tabs generally cause code that looks like:
if (c == ESC)
{
*r++ = '\\';
c = 'e';
}
else if (c == '\\' || c == '"')
*r++ = '\\';
*r++ = (unsigned char)c;
}
*r = '\0';
That's from the readline library version 7.0, bind.c, line number 727.
How does that happen? Because people end up mixing tabs and spaces. Some lines are indented with spaces, some with tabs, too many with tabs intermixed with spaces (I mean things like <space><tab><space>). I'm not even sure how people end up doing the last one, but it's common:
gdb 8.3 include/libiberty.h line 543 has 15 spaces, then a tab, then 10 spaces, then 2 tabs, then 3 spaces.
binutils 2.32 gas/itbl-parse.c line 119 has 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces, then 1 tab, then 4 spaces.
binutils 2.32 zlib/make_vms.com line 831 has 6 spaces, then a tab, then 2 spaces, then 3 tabs, then 5 spaces.
I'm sure they added tabs to give the convenience of being able to adjust the indentation to what I like, but in reality they just force me to change it to what others like to even read a file. Using hard-tabs seems like naive idealism. I haven't yet seen a project that uses hard-tabs consistently. It's either consistent spaces or tabs intermixed with spaces. At least, that's been my experience.
A tabbist would say the problem was that someone used spaces.
One of Dante's lesser hells is surely reserved for anyone that mixes tabs and spaces.
The issue really is that someone is not following guidelines (C, project, or implicit) and is not using tools that highlight such mistakes.
There is another level of hell reserved for those that use their own personal styles and conventions without paying attention to the existing code (or who just don't care).
> One of Dante's lesser hells is surely reserved for anyone that mixes tabs and spaces.
Mixing tabs and spaces for indentation is demonic, while mixing tabs for indentation and spaces for alignment is the only good choice without redefining what tabs are.
From a quick look, the mentioned projects appear to be using a 2-space indent, but with 8 consecutive spaces being replaced by a tab character (with varying consistency - readline seems to do so always, the other examples less so).
> I'm sure they added tabs to give the convenience of being able to adjust the indentation to what I like
I don't think this is the case. It looks like the authors of those projects decided that a tab character always is 8 chars wide, and that one tab vs eight spaces thus only is a question of encoding the same thing. So they're quite far removed from the idea that each indent level should be a tab (which is what most "tab-proponents" argue for).
As I mentioned in another comment, any modern editor will let you at least detect, if not automatically fix, mixed tabs/spaces. And there's nothing about deciding on spaces-only that prevents people from mixing.
Here's one: when your code has no tabs, it's very obvious that whitespace is just a bunch of spaces. With tabs, it's harder to say, especially when mixed. It's one less thing to think about.
I'm 100% on board with not mixing them and making sure everyone on the team is on the same page. But that's a red herring; it can easily be remedied with linters/editor settings. The same is true for preventing tabs.
Eh, not really. A string with a tab is still hard to tell apart from a string with spaces. Linters don't help there (why would they?). And no way in hell am I going to change Vim to display them differently!
For me, I think it's from my underlying interest in being good at something without having to make compromises or handicaps. As a benign example, I rarely/almost never change the keybinds in any of the code editors that i've used because I like the idea of being able to competently use all of them in their default settings to have a consistent experience everywhere. This allows me to use another instance of VSCode/PyCharm/Eclipse/etc. that's not my own and be able to reasonably be productive in that instance. It's a little silly, but it's something that I like.
Tabs runs counter to that underlying interest to a very small degree. They're there to be customized, and there's an expectation that you are supposed to customize their appearance for each view that you use to view them if you want a consistent appearance.
To an extent, I view the debate between the two as something similar to the debate between configuration vs convention. Convention is great when you're working within the 99% of the use cases that it supports, but it becomes difficult for the folks who need to do something not supported by the built in conventions and vice versa. Some people like one, some people like the other as a matter of preference. However, there's a small subset of the population that basically need configuration for one reason or another to operate. Whether it's because you're building a product that needs a feature that the framework doesn't support to stay afloat, or in this case, they need to be able to customize the appearance of code on the screen easily to be able to perform their duties in a reasonable time. I don't know if this comparison makes sense or is reasonable.
I will say that i've ran into enough errors due to people entering tabs into places that they shouldn't that my hate for tabs has grown more than it should. This ranges from people somehow (via copy+paste or whatever) entering a tab into a form field that doesn't allow for it to other engineers doing something similar for code and causing weird issues.
I really think the split is almost purely a generational thing. If your first exposure to computers/coding was using a terminal, I think you will end up leaning towards spaces. If you grew up in the post GUI world on Windows or Mac, I think you end up leaning towards spaces.
Did you have a typo or was that intentional? You wrote "end up leaning towards spaces" for both. I'm not even sure which you meant to be tabs. I grew up post-GUI, but now use mostly the terminal. My preference is only spaces.
Purely a guess, but I think that spaces vs tabs is a proxy indicator of some psychological difference. Perhaps it is conscientiousness. On some editors, you have to go out of your way to change tabs to spaces. If you're very picky about how your code looks and want it to always look the same in every editor and to everyone, then maybe you use spaces. Personally, I do ascii diagrams and even arrows inside of comments to point to different variables and make comments on active code. I am very very picky about how my code looks. I know code aesthetics isn't a be all end all, but maybe it could be some psychological tendency like this. Also, I'm not a paragon of big bucks or awesome, revolutionary code. Over time, perhaps conscientiousness or fastidiousness keeps you employed or people give you more responsibility and money.
Presumably the second one was supposed to say "leaning towards tabs".
I think you're onto something. In old-school editors there wasn't an abstraction layer between the characters and the way they were displayed. You were moving bytes themselves, so a character byte that took up multiple columns but which you couldn't edit the middle of must have seemed gross and unnecessary.
In today's world there's more abstraction, so people are more comfortable with abstraction. I use a font that merges "=>" into a single two-column-wide arrow, because it's more pleasant to read. I don't take offense at the fact that what's on my screen is slightly removed from what's literally on disc, because today you get more benefits from having that separation.
It was at one time a holy war. Spaces won. I used to be strongly pro-space so I was happy. However, with time and much reflection I've soften my stance considerably.
In any case, improvements with code editors have helped a lot to paper over the differences.
That's still language dependent, and mainly (IMO) one of Python's Windows-isms.
Speaking of Python, my ideal variant would:
# be whitespace insensitive (add back the braces and an official linter to use ANY kind of standard convention for enforcing a 'look')
# (Mostly un-do the external changes of Python 3 back to 2, BUT align to UTF8 rather than some 16 format)
# and would also handle all forms of 'strings' like C (though not necessarily null terminated, it'd be the array length + array style)
# with some added pre-tags that MAY be used to track if it's known to be in a given encoding.
# Validation/translation to such an encoding would be done only if requested and by a sub-library. Such encodings might include: Validated-UTF8-NFC, Validated-UTF8-NFKD, Mixed-UTF8, Tainted-UTF8... The Mixed variant would be the result of combining two UTF8 strings normalized to different standards, while the tainted one would be applied if the string is combined with, modified / returned from a function not known to be Unicode safe.
# File handles and other external I/O could also be opened without an encoding or explicitly with a binary encoding to allow raw binary access, and with an encoding to cause a final coercion to the desired encoding on output (and validation on input).
A thousand times this. I could come up with a whole bunch of arguments in favor of either side, but they all pale in significance compared to this.
What I really wish is that we had better ways to express indentation or alignment than just these two. Or to associate inline commentary with code other than by using either spaces or tabs to fake a two-column layout. Separating content from presentation, including affordances for the visually impaired, is practically a solved problem for other kinds of text. Why not adopt some of those same techniques for the text we work with every day?
In that thread the OP decides that the needs of a few outweigh the needs of the many. He went from trying to achieve "consistency across environments," which is very convenient and efficient to purposely making his workflow less efficient and more time consuming to suit the needs of two co-workers in an environment where his code will probably be read hundreds of times.
Develop how you want to develop and commit how your codebase is written. How is that hard? I guarantee whatever IDE you use has a feature to convert/change the indendation model of a file. Why is this even a topic?
You're not going to guilt me into using spaces because two people who read my code didn't like it. If you're using tab-width 8 I'm probably not going to like reading your code very much either. Does that mean you should change your entire workflow to suit me?
One can see this as just deciding on spaces as a path of least resistance, and then taking the time saved arguing or pondering the question to make money instead.
I don't understand this reasoning, I can set my editor to show x-spaces at the beginning of a line as however many I want. So I can make code indented with 2 spaces look like it was indented with 4.
That approach doesn't work if you use spaces both for indentation and alignment, you'd only want to multiply the indentation spaces. What editor has that setting?
Hey Joel–awesome service and post. Your tip about parallelizing via browser instances instead of tabs resonated with me as I've had a lot of headaches with one bad request taking down a full instance. That said, it does seem like the constant launch/close of puppeteer browser instances does have some sort of memory leak – Here's what happened when I switched from parallelizing via pages to browsers: https://imgur.com/a/rCz3oow
Have you seen any similar behavior in your system? I initially thought I was forgetting to close the browser instance but triple checked my code and it does seem like I'm calling close() everywhere.
- Sometimes Promise returned by page.close() never resolves so it's good to call Promise.race() on that together with a Promise that resolves after some timeout period (30s?)
- Sometimes Chrome process doesn't get killed so we are also manually killing remaining Chrome process after browser.close()
Are you using something like dumb-init or equivalent? That's a definite requirement as _not_ having it results in zombie processes hanging around (which do retain some memory footprint). Read more about that here: https://github.com/Yelp/dumb-init#why-you-need-an-init-syste...
I'm using dumb-init for the main node process in my docker container (node in-turn spawns chrome instances via puppeteer as requests come in). Is there a way to use dumb-init for each individual chrome instance as well? Or are you suggesting we make chrome the main container process and start new containers for each session?
This is cool–it's worth mentioning that you might be trading runtime performance for bundle size though, here's a contrived example to demonstrate: http://i.imgur.com/38CR3Ws.jpg
Keep in mind that everything is gzipped nowadays, so it may not make a big difference in network usage. Although it is still likely to cause some memory overhead
No, I have done and pubpished an article about how gzip works with JS and the result will compress pretty well. Not better than the code, but I would guess within the same order of magnitude.
JavaScript parsing is still a huge bottleneck. 1mb of it will still take 1 whole second to parse in V8 (note: just to parse it, not actually evaluate or run it!).
I thought that number sounded low as well, but it sort of checks out after doing back of the hand math. 130M books / 107B people that ever lived = 0.0012 books/person, 1:1000 book to person ratio.
