Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How it feels to learn JavaScript in 2017

medium.com

Post reply on HN
Print view View original

141–150 of 167 posts

Re: How it feels to learn JavaScript in 2017

#141

Post by _pmf_ »

seanwilson wrote: post #29

It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features like async/wait and ES6 modules along with live + hot reloading, it's impossible to go back. It's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.

> It can be a pain getting the build system up and running but once you're writing typed JavaScript code with modern features

Of course, once you're writing typed JavaScript, you're no longer writing JavaScript.

Re: How it feels to learn JavaScript in 2017

#142

Post by JimDabell »

Silhouette wrote: post #140
JimDabell wrote: post #136

Earlier quoted context omitted.

> It's not just an upgrade issue. Many organisations aren't running Windows 10 and so have no browser upgrade path to Edge at all. Many organisations still have an older version of IE, probably IE11 but sometimes earlier, as their standard desktop browser. That's an upgrade issue. They are using older software and a feature you'd like to use is being added to a newer version of that software. Yes, upgrades aren't alw…

Well, OK, but by that argument almost anything is just an upgrade issue, so I'm not sure that really gets us anywhere. In particular, it doesn't solve the practical problem that even with all the recent developments in the JS ecosystem, as things stand today a lot of front-end web developers don't have access to language features and programming techniques that are widely available in other environments. Unfortunatel…

> Well, OK, but by that argument almost anything is just an upgrade issue, so I'm not sure that really gets us anywhere.

That makes no sense. My argument is very narrow, clearly applies here, and I don't see how it applies to "almost anything".

> In particular, it doesn't solve the practical problem that even with all the recent developments in the JS ecosystem, as things stand today a lot of front-end web developers don't have access to language features and programming techniques that are widely available in other environments.

That doesn't really have much to do with what I've been saying.

Re: How it feels to learn JavaScript in 2017

#143

Post by simion314 »

Silhouette wrote: post #139
simion314 wrote: post #132

Earlier quoted context omitted.

You need more functionality for a non basic modal, first problem is if you have 20 modals you want not to copy paste over and over again. For non basic modals you also need events to know if user accepted or dismissed the modal, you want the Escape key to also work, you want the option to allow or not closing the modal when clicking outside of it, The project I work on uses bootstrap, this means in the main html file…

first problem is if you have 20 modals you want not to copy paste over and over again. Of course, but you can trivially generate the required divs in JS, and you can easily track the number of current modals displayed and set the z-index to ensure proper stacking if necessary. Other than that, what you put in the modal in terms of HTML content or rendering a template presumably works the same way as any other part of…

Ypu also need to have the modal setup the focus correct in the first input(or the one that makes sense), usually GUI libraries have a property for tab index that specify how focus changes when you press Tab, bootstrap seems to not properly setup the focus and I had to write code to fix that. It is not impossible to write such code but I am sure the code you will write in 10 minutes will not be good enough, my point is this modal feature should be native and not have people re-invent it, Also what if you want to allow resize or move, then you get again more and more code that is reinvented each time. IMHO is the same issue as with the dropdown/select , when you need a dropdown that has icons or something that the native one is not good enough it is easy to write one yourself, soem divs, some events but this 10 minutes dropdown will have missing feature or issues, like corner cases when the popup thing goes outside the screen or conflicts with something else,or the thing that opens contains 6 and half entries and if you want to look good you need to put more work into it, then if you want support for arrow keys more work, or if you want the feature where the user presses the first letters and selection jumps down to the correct item even more code, my point is basic implementations are fast, good enough implementation like you have in Qt,Flex, WPF is a lot more work and we do not have a standard way of doing it, and the developer needs to research what library works with the current stack he uses

Re: How it feels to learn JavaScript in 2017

#144

Post by troygoode »

trynewideas wrote: post #118
aaron-lebo wrote: post #12

Earlier quoted context omitted.

You're probably aware of this but that's why you put everything through Babel or Typescript to convert it. That setup is easy enough.

Assuming they read the post, they're not only aware of it but also read the post's author warning their fictional subject about the performance problems of using transpilers in production, and shrugging it off for the example because it's just a learning exercise and "easy to change later".

The warning in the content is (correctly) against performing the transpilation in the client; the fix is to run the transpiler on your server, preferably as part of your CI build process.

Re: How it feels to learn JavaScript in 2017

#145

Post by oelmekki »

seanwilson wrote: post #134
oelmekki wrote: post #122

Earlier quoted context omitted.

Yep, I feel the same way, but then again I usually work with small startups. I had an experience with a bigger team, recently (about 20 devs) and went all the way "what you do is too complicated". I was quickly humbled when I realized that my "simple" designs were quickly growing out of control and breaking a lot after a few months so many devs were adding code in it, most of them knowing only a very small part of th…

> So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :) Hmm, if each component is properly isolated though and you're not all working on the same area I still do…

> Can you give an example?

Oh, no, absolutely no real life example. Note that something that huge is not something I encountered (gladly, 20 devs was the biggest team I was in). I'm trying to answer the question "in which circumstances people doing this may be right", which is my usual approach when I don't understand a behavior (provided it's not morally questionable behavior, obviously, but it's not the case here).

And I totally get what you mean with over-abstractions, many rails teams have the same problem, nowadays. I'm not advocating that, just trying to understand why it makes sense for them, and which problems they have that I don't.

So, if I had to give an hypothetical example, I would go with a chart modal on an e-commerce, like amazon. You have the list of items with their quantity, in it, quite basic, and a few devs are responsible of that part - those who manage checkout base code.

But you want your modals to look the same all over the domain, so you make an abstraction for it, made by a team who work on abstraction for the whole domain, expecting to be used in a certain way, but trying to avoid preventing devs to implement what they need.

Now, the thing with checkout is that there are a lot of legalities which vary upon countries. You have developers in those countries, so why not make them work on the specific VAT, legal mentions, or whatever that they're already used to, instead of having a team who should get all the different legal frameworks of all countries in the world? Or you can split responsibilities about those to various teams, each handling several countries, but none having to know the law of all countries. To do that, you'll probably add an API in the basic chart component and allow different teams to plug on it.

And then, there's the team handling promotional content. Most of the time, they can do with existing abstractions, but sometimes it requires new specific content, so you decide to have a team on that, since you're a giant and you deal with several promotions a day.

All those people keep editing the same feature, but none know the whole codebase for it, so they have to be pretty sure they won't break someone else part by making a change.

And now, people in all those teams keep coming in and leaving company, and you have to make sure no knowledge is lost when they leave, and that new people can make changes fast. If you split all of this in 30 files with a clear separation of public api and internals, it probably helps.

This is my best - although probably naive - guess of where an over-specified architecture may be useful for a modal.

Re: How it feels to learn JavaScript in 2017

#146

Post by oelmekki »

acemarke wrote: post #130
oelmekki wrote: post #80

Earlier quoted context omitted.

I always do that, actually. I see what is provided in the App.js file as just a placeholder, meant to be replaced. Since you have webpack, you can import files from all over the place, deciding how to organize your project. It works just fine without ejecting :)

I think the issue the parent is referring to is that CRA's Webpack configs only define a single "entry point", for your index.js, where each entry point becomes a separate bundle in and of itself. Having multiple entry points, like an "app page" and an "admin page", would require editing the Webpack config, which CRA deliberately keeps abstracted and hidden away until you eject. If you really want to be able to modif…

Oh, you're right, thus the "huge js file". Thanks for pointing it.

Re: How it feels to learn JavaScript in 2017

#147

Post by pjmlp »

Silhouette wrote: post #95
pjmlp wrote: post #89

Earlier quoted context omitted.

I can think of native desktop applications on banks with 3 tier architecture, using DCOM and CORBA in the 90's, just as one possible example.

Oh, you're an evil person for bringing those up. Now I'm going to have COM and CORBA nightmares for days! It still blows my mind that we managed to write half a screenful of code, essentially just to call a function. On the bright side, I will never forget a manager of that era who was very good with buzzwords but not so good with the technologies behind them. We had some existing software built using COM, Microsoft…

Sorry about that. :)

Re: How it feels to learn JavaScript in 2017

#148

Post by seanwilson »

oelmekki wrote: post #145
seanwilson wrote: post #134

Earlier quoted context omitted.

> So I guess that, to the question "How could the 27 file commit example comment not be a clear case of overengineering though?", the answer would be : "when there are 100 modals in your codebase and various devs work on various parts of those modals". Not saying that's a place I want to work either, obviously :) Hmm, if each component is properly isolated though and you're not all working on the same area I still do…

> Can you give an example? Oh, no, absolutely no real life example. Note that something that huge is not something I encountered (gladly, 20 devs was the biggest team I was in). I'm trying to answer the question "in which circumstances people doing this may be right", which is my usual approach when I don't understand a behavior (provided it's not morally questionable behavior, obviously, but it's not the case here).…

> Oh, no, absolutely no real life example. Note that something that huge is not something I encountered (gladly, 20 devs was the biggest team I was in). I'm trying to answer the question "in which circumstances people doing this may be right", which is my usual approach when I don't understand a behavior (provided it's not morally questionable behavior, obviously, but it's not the case here).

Well I've been on teams on two where the software architect would insist on abstractions and dependency injection absolutely everywhere so it's probably not team size dependent. :P

I find it funny how some people promote the "you aren't gonna need it" principle but yet abstract absolutely everything in the incredibly slim chance they might want to swap something out in the future. I feel overabstraction is a very, very bad and common thing yet it is rarely mentioned compared to e.g. avoid goto, avoid comments. Overabstraction bloats your code and makes it really hard to understand.

> And now, people in all those teams keep coming in and leaving company, and you have to make sure no knowledge is lost when they leave, and that new people can make changes fast. If you split all of this in 30 files with a clear separation of public api and internals, it probably helps.

I could imagine how if you were dealing with Amazon's scale abstraction would be more common and more useful than in other places.

Re: How it feels to learn JavaScript in 2017

#149

Post by oelmekki »

seanwilson wrote: post #148
oelmekki wrote: post #145

Earlier quoted context omitted.

> Can you give an example? Oh, no, absolutely no real life example. Note that something that huge is not something I encountered (gladly, 20 devs was the biggest team I was in). I'm trying to answer the question "in which circumstances people doing this may be right", which is my usual approach when I don't understand a behavior (provided it's not morally questionable behavior, obviously, but it's not the case here).…

> Oh, no, absolutely no real life example. Note that something that huge is not something I encountered (gladly, 20 devs was the biggest team I was in). I'm trying to answer the question "in which circumstances people doing this may be right", which is my usual approach when I don't understand a behavior (provided it's not morally questionable behavior, obviously, but it's not the case here). Well I've been on teams…

Yeah, totally, small and medium teams don't need all of those. That was my initial point about implementing our own flux-styled store layer for react, instead of using flux (the actual lib) or redux, which are made for such giants.

We have a big problem with small companies wanting to imitate giants and go with elasticsearch/kubernetes/rabbitmq/whatever from the start when they clearly don't need those (and the same goes for code architecture).

I just won't say that the simple architectures I write are how everybody should write code and that giants' devs are bad developers for solving problems I don't have :)

Re: How it feels to learn JavaScript in 2017

#150

Post by Silhouette »

simion314 wrote: post #143
Silhouette wrote: post #139

Earlier quoted context omitted.

first problem is if you have 20 modals you want not to copy paste over and over again. Of course, but you can trivially generate the required divs in JS, and you can easily track the number of current modals displayed and set the z-index to ensure proper stacking if necessary. Other than that, what you put in the modal in terms of HTML content or rendering a template presumably works the same way as any other part of…

Ypu also need to have the modal setup the focus correct in the first input(or the one that makes sense), usually GUI libraries have a property for tab index that specify how focus changes when you press Tab, bootstrap seems to not properly setup the focus and I had to write code to fix that. It is not impossible to write such code but I am sure the code you will write in 10 minutes will not be good enough, my point i…

It is not impossible to write such code but I am sure the code you will write in 10 minutes will not be good enough

Well, you keep saying that, yet putting focus on a designated element when opening the dialog is literally one line of code, and setting tab order isn't particularly difficult either (and is probably something you'd have to do in much the same way whether you wrote the code yourself or used someone else's library to create your modal).

In any case, we seem to have drifted well off the original topic now. The comment by revscat was about a requirement to add a very simple modal without any of these hypothetical complications you keep introducing, and how the resulting PR involved 27 files. That's crazy.

Post reply on HN