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's really trendy to complain about JavaScript changing too fast right now but the last few years have brought some great changes to JavaScript.
I'd say they've made JS development bearable, but great is really stretching it. We still don't have a type system, static analysis, multi-threading, first-class IDE support, or any of a myriad of other features that are standard in any modern programming language in 2017. I'm hopeful that projects like Blazor[0] and other efforts being made toward bringing real languages to the web via native WASM will put JS to rest once and for all.
> We still don't have a type system, static analysis, multi-threading, first-class IDE support
Let me try to address these.
Regarding type system, lot of great languages don't have type systems either. But if there's lot of discussion on type systems, it would be because of Flow vs TypeScript.
As for static analysis, JS has seen evolution of JSHint, JSLint, JSCS, ESLint, and finally, Prettier. Flow is capable of performing type-checks with dynamic analysis.
I am not sure multi-threading is the hallmark of a modern language. Because Go, Elixir etc. are providing great concurrency without exposing threading API to the developer. JavaScript lets you do asynchronous tasks via callback, promises, generators, and latest - async/await. In the browser, you can use web-worker. But in most cases, you won't need it.
JS ecosystem has great code editors. I find VSCode to have good support out of the box, with breakpoint debugging. You can also use Atom, or Sublime Text, or Webstorm. If you're missing certain functionality, you can always add open-source plugins.
I'm with you on most of your points, but IDE support is still quite crude compared to (say) Java or Kotlin. Once you're fluent with these in a Jetbrains IDE it feels like you're directly manipulating an AST (or something near it) rather than 'editing text'. Javascript (even with Typescript in IDEA/Webstorm) isn't close to this yet.
Do you actually code in JavaScript? TypeScript addresses many of these issues and even statically checks for null variable usage which puts it ahead of some mainstream type systems in my opinion. I don't hear people making fun of Python for example and that has a huge following.
I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another.
> I mean, I do occasionally, but I think one big difference is that nobody is forced to use python. If they want a feature a normal language doesn't have, they can easily choose another.
Most domains heavily constrain your language choice though...C/C++ for games, Java/Kotlin for native Android, Swift for native iOS, PHP/Node/Python/Java/Ruby for server-side. The libraries you need constrain the choice even more. I'd love to use OCaml everywhere if I could but there's just no support for it.
Anyway, my point is complaining that vanilla JavaScript is bad is a real disservice to modern JavaScript. What's so bad about it if you use TypeScript?
You can use practically any language for games or web servers; they are certainly not constrained to the ones you listed. Game engines are usually written in C++ but the logic usually isn't. Even more importantly, the reason they're written in C++ is because it's usually the best tool for the job, NOT because nothing else is available. Nothing prevents you from writing a game engine in Rust or JavaScript or assembly language or whatever you want. And on servers, anything really does go.
I love JS and especially the variety of tools available.
It's a double edged sword. But once you have your tools is great.
I love webpack, vscode, Typescript, npm, preact and mocha. All great tools to solve a specific problem.
So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs.
> So much better than a number of other language. Have you ever dealt with the horrors of package management with pip because it's inconsistent installs.
Personally I'm surprised the null/undefined checking feature of TypeScript isn't raved about more which is missing from many typed languages.
Most domains constrain your language choice into something that fits that domain.
It is just mobile and web that constrain your choice into some arbitrary stuff that may or may not work well, and it's your problem to deal with the consequences.
ATM Angular 4 w/Typescript in VS Code is in my top 5 favourite language/dev environment combinations.
It has working code completion and is fast. It lacks refactoring and doesn't help me with debugging though.
(Java with any of the three big IDEs occupies three spots but I haven't made up my mind about exact order except first place. Also these are my favourites - they are not necessarily everyone elses favourites.)
For type systems you have Flow and TypeScript, coming with their IDEs. The Chrome devtools and various plugins helps having a good IDE too. Multi threading is possible but rarely used because the concurrency model of JavaScript is event based.
Overall, I think JavaScript has a very rich ecosystem because, if you do Web programming, you do not really have alternatives to JavaScript. So the community made the language support various programming styles, tools and libraries.
I do not believe WASM will help bringing more language to the Web than today because it is already possible to compile to JavaScript with good enough performances for most use cases.
>This is wrong. JS has service workers, and sharred array buffers.
Service Workers are not really threads as the runtime environment is still single threaded no matter what, you just have the ability to spawn a new process. On top of that browser support is sketchy at best, with no planned support for Safari or IE.
It's misleading to say that there's no planned support for Internet Explorer – Edge superseded Internet Explorer so all new development is going into Edge, not Internet Explorer. Service Worker support for Edge is under development:
Microsoft might like to think so, but until all our business clients agree with them, the real IE is still a significant limiting factor in deploying with any JS feature you can't effectively polyfill.
Okay, but that's an upgrade issue, not a dead-end issue like a lot of people would assume from being told that there's no plans to add it to Internet Explorer.
Features get added to new versions, not old versions. Organisations using old versions will need to upgrade to new versions to get the new features. That's true of anything. It just happens in this case that Microsoft decided to go from Internet Explorer 11 to Edge instead of going to Internet Explorer 12. Saying that there's no plans to add support to Internet Explorer is like saying there's no plans to add support to Firefox 50 – true in a technical sense, but in practice, of course they add new features to new versions rather than old versions, and of course organisations have to upgrade.
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.
Experience tells us that those organisations aren't in a hurry to upgrade their standard desktop deployment just to get a new browser so web developers can play with the shiny new toys. Did we learn nothing from the XP and IE6 era?
So it's all very well talking about newer JS features, but pragmatically, you can't just wish away the need for compatibility with browsers more than a year or two old if your target audience is businesses, governments, or other large organisations.
There's an unhealthy complacency among parts of the web dev community, as if something being available in the latest Chrome canary now means it can be used everywhere. That's just not how a distributed system works when you don't fully control the client.
Even if it were, you're not just going to retrofit something as significant as multi-threaded architecture into most existing JS code bases. Outside the HN bubble, not everyone gets to start a greenfield JS project every six months.
I think aphextron's original comment was fair and realistic: as a practical matter, even with the rapid pace of change in the JS ecosystem, we still can't use a lot of day-to-day features in JS that would be routine in most other modern programming languages.
> 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 always convenient or timely, but it's still just an upgrade issue, not a technology you have to give up on because two major browser vendors aren't interested in developing it.
> So it's all very well talking about newer JS features, but pragmatically, you can't just wish away the need for compatibility with browsers more than a year or two old if your target audience is businesses, governments, or other large organisations.
I'm not wishing away the need to support older versions. I'm just saying that this is something we'll be able to use eventually, not something we'll never be able to use because two major browser vendors refuse to implement it. It's an upgrade issue.
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.
Unfortunately, this is just an inherent problem in the way that web tools have been repurposed for more general software development: the developers don't control a significant part of the infrastructure, so they will always have to code to the least common denominator among their target market.
> 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.
Maybe we're talking at cross-purposes, but you seem to be saying that
(a) it doesn't matter that there was no support for a feature planned for IE, because it is planned for Edge
and
(b) IE and Edge are essentially the same browser, and one is just the upgrade for the other.
I contend that this is what Microsoft's marketing department would like everyone to think, but the reality in larger organisations (and for those developing web sites and apps aimed at those organisations) is that they are two completely different browsers. In many cases, the only way you can "upgrade" from one to the other would be literally upgrading the entire organisation's standard desktop environment, including the OS.
If you're going to contend that a missing feature in one product is only an upgrade issue because you can change the entire OS and then install a completely different product to do the same job and then get that feature then I don't know what wouldn't be "just" an upgrade issue.
For all practical purposes, Edge is the next version of Internet Explorer. New features aren't being added to Internet Explorer 11, only to Edge. Yes, Edge has higher system requirements than Internet Explorer 11, but that's not relevant to my point. The same was true of Internet Explorer 9, which didn't run on Windows XP, but that didn't mean Internet Explorer 9 wasn't the next version along from Internet Explorer 8 or that it was "a completely different browser" or "a completely different product". It just means it's got higher system requirements, that's all.
The only thing the higher system requirements mean in practice is that the timetable for upgrading is delayed for some organisations. Those that aren't on Windows 10 will upgrade later than those that are. This means that it's not a blocker for using service workers, just a pretty typical delay while we wait for organisations to upgrade. As I keep saying, it's just an upgrade issue.
Saying that Microsoft aren't adding support for service workers to Internet Explorer while leaving out the massive fact that this is because Internet Explorer is the legacy version and they are adding it to the next version along, Edge, gives a radically different impression to what is actually happening. It implies that we'll never be able to use service workers because a major browser vendor isn't supporting it, when the reality is the opposite – that Microsoft are adding it to the next version of their browser and that all web developers have to do is wait for people to upgrade.
This is then compounded by the claim that Apple are doing the same thing – which is also untrue. Apple are adding service worker support to Safari right now, you can even go and look at the code yourself.
Yes, I understand that in terms of IT operations, the upgrade from Internet Explorer 11 to Edge is not without its complications. But it doesn't matter to the point I'm making. This is an upgrade issue, not a "multiple browser vendors have killed service workers" issue.
> If you're going to contend that a missing feature in one product is only an upgrade issue because you can change the entire OS and then install a completely different product to do the same job and then get that feature then I don't know what wouldn't be "just" an upgrade issue.
Changing from a previous version of Windows to Windows 10 is an upgrade. Changing from a previous version of Internet Explorer to Edge is an upgrade. It's quite clear why I'm calling this an upgrade issue, and I don't see how you can think that logic applies to things other than upgrades.
An example of what wouldn't be an upgrade issue is what I am explicitly contrasting against here. Two major browser vendors refusing to implement service workers wouldn't be an upgrade issue. If Microsoft and Apple won't add support for service workers to their browsers, then developers can't just wait for people to upgrade because newer versions won't include support either.
That's why it's so relevant to say "hang on, that's not right, both Microsoft and Apple are adding support to the latest versions of their browsers". It's the difference between service workers eventually being usable with a great deal of cross-browser support, and service workers being dead outside of small niches.
Agreed. I think the perception comes from lots of people who are using heavy frameworks for simple, mostly-static webpages. Yes, they add complexity to my life, but the experience of working with React/We pack/Typescript is unparalleled -- especially considering what I was working with only five years ago.
Yup. Converting old promise based code to using async/await and fixing all the places that give "variable could be undefined" type errors is so satisfying. Recently I did a huge refactor of some TypeScript code without running the app and just being guided by the type checker errors for several hours and it worked almost first time.
No one is complaining because its trendy. Rather, good JavaScript developers already know the core language plus jQuery and a framework or two. We can build websites without the extra stuff. We are tired of spending our time and energy learning technologies that are horizontal to what we have already mastered. We enjoy writing JavaScript and find it suspect when anyone complains about the language.
I stick mostly to JS + jQuery, but I see nothing wrong with using additional tools when the situation calls for it.
If you're going to be writing a lot of CSS, then using SASS might save you some time and improve readability. If you're writing a webapp, then a SPA or React app might be the best course. And if it's image heavy, then a tool to automatically compress images would likely make sense.
If this is too complicated to manage, then other tools like task runners or Webpack can help automate the process. Node packaging can be used to sync settings across all project owners.
Taken on their own, it seems like a lot of complexity. But if you're only adding tools when you need them, it's really not that bad.
I wrote my last site in Jekyll + SASS. No Webpack, no gulp, no React. I just didn't need them, so I avoided the complication.
I'm glad they're there if I decide I want them, though.
I still just use ES5 JS, jQuery for around 2/3rd of the frontend code I write. The remaining third is a split between simpler, more mature but decidedly unsexy frameworks like Backbone, Underscore, Handlebars and newer trendy babelifed React and Vue. Both are fine. I enjoy both still.
Some people would consider it a bad thing that eg. Backbone hasnt had a major version in years but it is still perfectly capable for many use cases and it performs well. Of course you have to have more experience and knowledge with JS and frontend development in general to get these results I think.
But the core language really is that much nicer to program in when you can freely use object destructuring, spread operators, and some of the newer built-ins, etc.
And even there it's not the pain it has been, if you write react app, thanks to create_react_app. It basically brings all of that out of the box, without any configuration needed, just like `rails new my_app_name` creates a ready to use app. Actually, I've seen several times people reporting using it for non react projects, just because of that ease of setup.
Of course, you may still want to tweak configuration, and then you have to "eject", which means that all configuration files are dumped in your directory for you to edit, and you basically don't use create_react_app anymore. You now have to get webpack and babel configuration right to make your changes, but you have a solid basis.
Nowadays, I try to never eject, and see create_react_app as a lib providing everything I need. It sometimes prevents me to try new staged js features, but on the other hand I often have new features on update that I didn't bother enough about to eject in previous version.
Such wrappers around build system are probably the way to go. I would love to see something like create_react_app but allowing to provide buildpacks, so we can find in the wild the perfect configuration for our taste.
create-react-app itself is great for quick prototyping, but for non-trivial apps, chances are, eventually some esoteric production concern will force you to "eject". At that point, the sheer volume of configuration you'll be left with will be rather overwhelming if you've never dealt with the underlying technologies before, and modifying/extending it can become rather intimidating.
My recommendation is to start your first few projects with create-react-app, to get a feel for what a modern JS dev experience feels like, and then once you find the need to eject, instead of actually ejecting, copy your code over to a new project starting with just a bare minimum Webpack + Babel config, like the one in react-hot-loader-minimal-boilerplate (https://github.com/wkwiatek/react-hot-loader-minimal-boilerp...) and refer to the ejected configs of the create-react-app version of your app and the create-react-app README to port over pieces of tooling that you feel are sorely missing from your create-react-app days, one by one. This way, you'll be left with a much simpler and leaner tooling pipeline that you fully understand and one that you'll be able to extend and maintain much more easily.
I usually refer to the react-hot-loader-minimal-boilerplate config as a baseline simply because I consider es-next transpilation and hot-reloading essential parts of the modern Frontend dev experience. If you don't, you can totally start with something even more barebones.
I like create react app a lot but i wish there was an easy way to add a second page. I tried doing this recently and found it was actually easier to implement react router with code splitting to avoid loading my main page's huge js file.
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 modify the Webpack config for a CRA app, you have a couple other options besides ejecting:
But didn’t we say the same thing about JS almost every year in the past? Only for the status quo to be obsoleted in a few months? Is the breakneck change curve slowing down finally?
Being a java-ist, I could not consider to learn JS without a proper type system, and a proper IDE (with autocompletion, static analysis & refactoring facilities). TypeScript & VSCode/IntelliJ save my day now.
More advanced programming paradigms (a la Haskell) are nowadays almost doable in the JS ecosystem.
So yes, I would consider that JS has matured as a platform.
I still have no clue about frontend web frameworks yet.
Even better. You don't even need to set up a build system for async/await, ES6 modules (coming in Chrome 61) these days. Most modern browsers support a great portion of ES6+ specifications by default.
Live / Hot reloading might take some setup though.
One thing I am yet to see implemented, is tail-recursion. It's in the spec, but I am yet to find an environment that implements it. Please correct me if I'm wrong.
I too, am learning JS in 2017, and I can't wait to go back (to cljs). Or away, to anything else. I had done some basic stuff before, but for the last days I have been writing some code for a larger SPA.
Just as an example, today I needed to do the simple task of iterating over a dictionary. I expected it to go roughly like this:
dictionary.forEach(this.someMethod);
Instead, this is apparently what passes for sane in JS world, in 2017:
for (var key in dictionary) {
if (dictionary.hasOwnProperty(key) {
this.someMethod(key, dictionary[key]);
}
}
Going back where? Would I go back from JS to Ruby. Without even thinking. Would I go back from JS to Swift? Without the shadow of the doubt. Would I go from JS to Perl? Probably not. But I am sure plenty others would. My quantum mechanics professor told us that "you cannot understand QM, but you can get used to it". Something along these lines applies to JS as well though I am not sure what word should replace "understand".
A language without a proper stdlib and with programmers who have no idea what the O notation is about has no place in any serious programmer's "to learn" list.
Aka "javascript is not a real language", I thought we were done with that since almost a decade :)
Maybe you should consider that just because a language doesn't work like what you're used to, it doesn't mean it's a bad language. Because saying nowadays that javascript is not worth learning sounds pretty absurd. Sure, you can live without it. But that's probably the most useful language to know as a "second language", for all its various applications and because when you want to add scripting in your tool, you know javascript is a solid choice for its penetration rate.
Abstracting from js, rates and popularity of the only available solution are not an argument. It is like asking 'but who else?' in a dictatorship country. Pretty absurd, right. You folks are so blind that don't even understand how this straightforward non-blocking code works in decent languages:
sql = client.read()
res = remote_db.query(sql)
client.write(res),
still writing tons of boilerplates and spaghetti instead. We drown in happy ignorants, and they can't stop doing this to us, because they're happy with penetration rates, not technologies.
The fact that the big web scripting monopoly influences other scripting and embedding markets is self-explanatory.
As for 'second' language, I'm pretty sure I'm not happy to do main work with a 'second' language, because it is second only after top 3-5 that I use on daily basis.
This is like saying "just because you are used to having a proper toilet, it doesn't mean you should have one and you should consider living without it"
We have recently implemented Angular4 in our project, and have started to pick it up. Recently picked up a story that was adding a simple confirmation modal to a page: "Alert" text in the top, body with some warning text, and a yes/no button.
This was my first experience with modern JavaScript frameworks and TypeScript. I wanted to do it right, so worked closely with team members who were more versed in this stuff, and followed the various recommended best practices.
By the time all was said and done the PR for this thing had 27 files in it.
For a modal.
This seems ludicrous to me. The frustration, somewhat humorous, expresses by TFA is completely understandable, though. While I came to appreciate TS, I'm still skeptical about this JS framework stuff. They seem overly complicated to me. (While I have only read casually about React, it seems similar in this regard.)
I've been doing heavy javascript interfacing since the end of the 2000' (it was still a rare skill back then, and made me good freelance money), and I totally understand how you feel.
I experienced the same thing when learning angular, flux and redux. It all screamed "overengineering" to me. But then I realized why it was that way, and why it had to be : you now have teams of like 50 js developers working on the same codebase. They have to have very strict and complex architecture, because their frontend codebase is just as big, if not more, than their backend codebase.
Those tools still lack alternatives for small to middle sized teams and products, IMO. React by itself is super cool to be quickly productive in that scope, but state management systems are not. For that reason, I made my own flux library, meant to keep things conceptually simple. The flux pattern by itself (data always propagating in a single direction) is not complicated, its implementations are. I would recommend that small teams working on small products take time to get the flux idea, then make their own implementation, it's worth it.
EDIT : to be more specific, here is a simple thing to do to make your own implementation:
1. build something (let's call it a store) with a `subscribe(func)` method allowing to be notified when data changed
2. add a public api to that store (`like store.addArticle(article_data)`)
3. in the `componentDidMount()` method of your root component, subscribe to store with a function that calls `setState()` on your component, then pass data as props to child components
4. when triggering an action, like clicking a button, call a method from the public api of your store
5. you now have a state manager ensuring data always flows in the same direction, and you can make your store implementation as simple or as complex as you want
How could the 27 file commit example comment not be a clear case of overengineering though? I frequently add similar functionality to Vue and Angular 1 projects in a way close to how you describe and it's simple. Even if the change involved adding a modal library (you should not be wasting time implementing that yourself) to your project first, it shouldn't be more than about 10 lines.
Personally, I'd find it very hard to be motivated to work on a project like that. It sucks all the fun out of coding when things that should be simple aren't simple, it's draining for the whole team and it creates a lot of friction in adding new features.
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 the app. I guess I could say no product should need 20 devs, but it feels like denial.
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 :)
> 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 don't see why a simple modal could take so many code changes. Can you give an example?
I've worked on Java codebases before where there's hundreds of abstract interfaces, factories, design patterns galore etc. where you can't work out where the actual work is done because every file is just delegating to another file which I hate with a passion. JavaScript gets a lot of stick around here but I find it fun and productive to work with to be honest, as long as the same silly level of abstraction is avoided.
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.
> 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.
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 :)
The example you edited in makes your point very well. Essentially, you're describing a simple MVC design, with a couple of React-specific details for rendering your view.
In desktop world, we were using this sort of software architecture decades ago. It's only a combination of modular design, separating state from presentation, and an observer, and these are all well-established principles that have stood the test of time. Countless developers have written something like this at the start of countless new projects, and they probably did it in five minutes without a second thought.
The difference In modern JS world is that some people talk as if you need 197 dependencies, a whole build process and a team of 5 just to maintain it. You really don't, and the frameworks and build systems that push in that direction make my head hurt.
That said, a modal dialog can be very hard to implement, depending upon needs (centering in viewport, mobile devices, stacking multiple modals, form modals with popup controls above them, preventing tab key allowing focus to go to form behind, plus many other hard issues!)
> Recently picked up a story that was adding a simple confirmation modal to a page: "Alert" text in the top, body with some warning text, and a yes/no button.
> By the time all was said and done the PR for this thing had 27 files in it.
Can you not just use a library for this and do it in a few lines...? I found Angular 2 verbose but I don't see how the above is common. I just did something similar in Vue today and it was about 4 lines to load the library and call it. You shouldn't be implementing modals yourself if you can avoid it.
Maybe a sign that things are too coupled through. Can make the same argument on any project, I.e. wanted to add small feature, ended up changing 27 files.
27 files sounds absurd. Maybe you're doing more than adding a store with some action?
I used mobx with react and a new store is 1 file, including its actions. Connecting it to components takes a few lines per component.
Redux may use more files but they are short.
Yeah something's not right. A modal is a line of code, not 27 files. The most extensible modal could be a single file component.
Just starting fresh, what is a modal? It's a widget (we could use a div) which when activated is moved to the front of the z axis and steals focus. CSS can do that. Now all you need it do is keep attributes regarding the text of the modal and state representing whether it's activated (we can juse a regular JS object for both), and you've got a working modal.
Some of the frameworks are needlessly complex, which is frustrating, because it's hiding something very basic.
Does that work in several versions of different rendering engines that date back a decade, at resolutions from 800x600 to an iMac 5K screen? How about on tablet and mobile devices? What happens when the user's scroll position is half way down the page? Does it listen for events to update or close itself?
A good modal library is going to weigh in at a few thousand lines of code across JS, CSS and HTML for a reason. If you have a simpler use case then you don't need all that extra edge case handling, but that doesn't mean it's not pointless code.
A good modal library is going to weigh in at a few thousand lines of code across JS, CSS and HTML for a reason.
No. Sorry, but that's just nonsense.
A modal is probably going to be rendered as an HTML div element, styled so it appears with a fixed centre-viewport position.
You probably also want a second div as an overlay to de-emphasize the rest of the page while the modal dialog div is visible.
You might want a standard X button to close the dialog, which hides the above when it's clicked.
You can write all of that in less than a screenful of code, and you can do it using nothing but basic web standards that are supported as far back as IE8 and iOS5 -- in other words, well before the browser generations that even Microsoft and Apple themselves still support today.
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 you have copy pasted same html boiler-plate with only the content change, somewhere there is a button that has a special attribute that magically opens this modal(bootstrap js does that in the background), this does not scale and we searched for a good library so we can put each modal in it's own file and we also needed full control to create the modal if and when we needed it and not have it loaded in the main html but hidden. The solution would be to have modals implemented as standard and not having to hunt for a library because the lib we used is for angular+bootstrap but it will not work for react+bootstrap or for no framework projects.
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 your UI. There's nothing magic about the fact that this particular div happens to be styled as a modal dialog.
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
OK, so you need two callback functions, a couple of buttons to proceed or cancel, and possibly a couple of event handlers for keyboard and mouse/touch events.
Again, you surely have something to render buttons and handle their events for your UI more generally anyway. Other than that, the only thing special about the modal is that maybe you're connecting a couple of other events to the same handler logic as the explicit cancel button.
Really, none of this is difficult, nor does it need anything like thousands of lines of code just to handle modal dialogs. You could code everything we've been talking about here from scratch in a few minutes, and you could integrate it straightforwardly with any UI library I can think of if you're already using something else to render templates or handle input events. If you already have something available that will save you those few minutes, great, go right ahead and use it, but let's not pretend this is some tricky problem that requires a lot of thought and a lot of code written by experts. It's an elementary exercise in UI design, which I'd expect any junior dev to handle easily.
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
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.
What's the likelihood that he's supporting engines going back a decade? Modern rendering engines and CSS handle that pretty well. IE 8 is 8 years old. Bootstrap 3 supports IE 8 and has modals.
Point being, you can either write up a simple modal if you are targeting semi-modern browsers and don't need much, or you can use one of a dozen libraries that do this, but 27 files sounds pathological.
Agree. More importantly, I see this nasty trend where people bag on jQuery code just because it's jQuery code.
I've seen devs complain about how coupled some small jQuery one-liner is and then replace it with some muli-hundred line monstrosity of a module that's buggy, incredibly hard to understand and impossible to actually reuse...then when you call them out on it, they just say "fuck you, we're writing ES6 now".
The code they replaced was simple, just worked and didn't have side-effects. And they're still using jQuery elsewhere in their project anyway...
The vanilla solution doesn't offer as many features:
* With the vanilla solution, the user can check a box that says 'Prevent this page from creating additional dialogs' (which can break the site). With a non-vanilla solution, the user cannot check that box
* The vanilla solution can't be themed in tune with the rest of the site or webapp
* The only options you have are 'OK' and 'Cancel' - you may wish to have other buttons/labels for your modal. Never mind if you want three buttons, or a list or the like
Of course there isn't perfect feature parity, but considering how much more complex a custom solution is, you should definitely think twice about what that complexity actually gets you
UIs on the web suffer much more than UIs elsewhere from the disease of people designing their own UI elements in order to achieve a novel, unique style. Perhaps, some day, this will be considered pointless and unprofessional like on the desktop...
But web design philosophy has been creeping on to the desktop for quite a while now. Apps like Skype and Slack are ludicrously overstyled these days. Flash and chrome have always played teeter-totter with utility and functionality, in every field.
But has it been solved if you take into account the various constraints/issues:
- clients that range from tiny phone screens to full desktop screens
- incompatibility when it comes to what features clients support, and even how they support it
- a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers)
- serious limitations in payload file size for the entire UI codebase
- much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'.
- backend systems that are not optimized for these kinds of things
I am a relatively 'young' programmer, so maybe I'm utterly wrong about thinking that, considering the above, we're in kind of uncharted territory. By all means correct me!
All that said, I do get the feeling 'we' in the javascript world reinvent the wheel more than necessary. But perhaps that's because none of the historical solutions are 'complete' enough to get enough mindshare in the way that, say, Ruby On Rails was, or jQuery.
Also, personally I'm becoming more convinced that until all this stabilized, many of use (or at least I personally) might benefit from just not aiming that high when it comes to UI. If I'm honest with myself, an 'old-fashioned' backend that produces HTML with perhaps a few dynamically loaded components (as just HTML fragments, even) is perfectly fine and I truly doubt it would have a negative impact.
(hey carsongross, this is where you bring up intercooler.js!)
I've done stuff with Delphi back in the day, but I'm not too experienced. Would you mind explaining point by point how desktop UI 'does' this?
For example, I can't really think of a desktop app where most of the crucial app/UI logic is reliant on async communication with a server. Most data is stored locally and permanently.
I'd actually really like to hear because I have been eying native development lately!
Young developer here too, but I started about a decade ago with robotics/desktop development. Thus, I can sympathize with the comment earlier that desktop UI has done all this:
clients that range from tiny phone screens to full desktop screens -- Desktop UI could support this if developers wanted to its just resizing a window. You just don't see it because devs assume the existence of a mouse which allows easing panning in a scroll bar window.
- incompatibility when it comes to what features clients support, and even how they support it - Desktop UI has or had solutions: Swing, JavaFX, QT, Adobe's Flex.
- serious limitations in payload file size for the entire UI codebase: There have been desktop XML UI for so long. The oldest I can recall would be Adobe's that went along with ActionScript to build Flex apps.
- much of the UI depending on asynchronous operations. The only 'UI' that I can think of that is similar is when I SSH into my server. All other user interfaces are mostly 'local'. -- The desktop analogy here is some long running process. Whether that is a slow disk, long computation, or some network access, desktop UI solved this a long long time ago with a rendering thread and worker threads.
- backend systems that are not optimized for these kinds of things - not sure what you mean here.
I think we're talking cross purposes. I'm not saying that there we never came up with better things; far from it!
Rather, disregarding how we got here, the situation we're in now provides challenges that sort of justify the complexity and confusion we're in now. Maybe this comment better expresses what I'm saying: https://news.ycombinator.com/item?id=14218425
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 had just announced the first version of .NET (though no-one quite knew what .NET actually meant yet) and the Internet was taking off as a mainstream technology for the general public. The manager in question would wander around the department asking us if we were using this new .COM framework to build our new software...
a foundation not meant for UI's that is pretty much required to be abstracted away leakily (HTML, browsers)
This is the problem, right? It's not that the other problems are unsolved, it's that we're buiding on a lousy foundation. But even that is just an annoyance, something we know how to overcome, it's not a fundamental impossibility.
With the way callbacks work in Javascript and jQuery, you lose some flexibility in organizing your code. It is true the types in Javascript make it difficult to build large projects. These drawbacks can be overcome, of course, but this is all orthogonal to the main point......
If Javascript and jQuery truly are bad (though I would claim they are not, they are mediocre but workable), it's because their creators didn't know history, not because the problem is unsolvable.
Eich wasn't ignorant of history, he just had marching orders to deliver something that resembled Java for marketing reasons, and only a week to finish or be displaced by something worse. The trouble is nobody ever got to fix it until ECMA.
A refreshing read. Was expecting a satirical negative take on the complexity.
However, this only covers a small part of front-end development with VDOM based approach, and a few ES6 constructs (destructuring, arrow functions, let-const).
The author misses out on mobile development, Node JS and NPM modules, server side, and Electron-based desktop apps.
It's a good thing to take the positive approach, and get introduced to some interesting, low-barrier-to-entry items. At the same time, it would be prudent to keep in mind what lies ahead.
I sense that the target audience is probably people who are already developers but have a negative view on the current js ecosystem.
They are likely to be fairly happy with their existing approaches to desktop and server development and want to learn to use javascript where it is currently unavoidable.
I submitted this after 'brlewis linked it (it's his piece) in a comment because it really hit home. Like, I've never used Mithril, but I dove into React (both web and React Native) this year and it reminds me of when doing web stuff was fun. Which, for me, was before anyone was actually using JavaScript.
There are a lot of skeptics about modern JS frameworks, and I get it (my inclination in every programming environment I've ever worked in is to avoid frameworks, etc. until I know I need them), but boy is this a big, and awesome, change.
Thanks, glad it hit home. I also remember back when best practice in web dev was to avoid JavaScript. A lot of the new shiny things in between then and now just weren't it, but a lot of today's new shiny things are for real.
You know a lot of people are terrified of change and new stuff because it might mean their skillset is obsolete.
That's a lot of what this backlash against JS is. Some of the criticism is warranted, but a lot of it isn't, it comes from people who have never done anything other than sneer at the language, and for every issue JS has, you can find a matching issue in another language that either a) isn't a problem because there are idiomatic solutions or b) everyone in the choir knows it's dumb but they don't say it to outsiders, because why advertise your weaknesses?
JS today is very expressive (more expressive than Python simply due to good lambdas - not to pick on Python but it's a language that doesn't get the hate of a JS or Go), it's been fast for awhile, it's got a dozen new interesting frameworks, the tooling keeps getting better, etc. This can either scare you or represent opportunity.
We've got a 5k line JS app. It was written by people who weren't programmers, in a jQuery/d3 ball (it was still an impressive interface). Over the summer we've converted it to Mithril and modern JS, now it's half the size, our dev environment is setup with a simple npm install and npm start, we have reusable components that multiple people can grok and use, it only takes a 20 line webpack file to do this all, and before the summer started none of us had used the framework.
It's amazing what it has enabled us to do and how simple the whole stack is. I've been building desktop apps and small intranet web apps for a decade, they don't hold a candle to what's possible if you harness this stuff. People can complain all they want but this is what progress looks like. Someone might not think it's cool that you can write an interactive single page application in 50 lines of code that anyone in the world can access, but isn't that what we wanted?
It takes a day to grok this stuff, a week to build interesting stuff in it. It's worth the investment, you might actually learn to do things you couldn't before. That's fun.
> You know a lot of people are terrified of change and new stuff because it might mean their skillset is obsolete.
That's a lot of what this backlash against JS is. Some of the criticism is warranted, but a lot of it isn't, it comes from people who have never done anything other than sneer at the language, and for every issue JS has, you can find a matching issue in another language that either a) isn't a problem because there are idiomatic solutions or b) everyone in the choir knows it's dumb but they don't say it to outsiders, because why advertise your weaknesses?
I think a lot of the "sneering" is less about fear of "new" things and more about frustration that old ideas that they previously considered are now being presented as "new" by a generation of people who either did not see themselves or did not ask an oldster about the old ways.
The tell for me, is in what things get the most sneered at. Node and npm tend to get a lot of sneering, because they're essentially attempts at solving problems people had already solved before. People don't sneer as much at other things like React (except for its license and large number of dependencies, and the latter is really npm/language sneering).
I think this is a pretty good analysis. NPM, to me, is a pretty consistent string of "you did what and why?" reactions. But once I get away from that, to stuff like React, my attitude changes to "oh, yeah, this is good stuff."
Cool story of what you've been able to do by investing in modern web technologies like Mithril.
The part where you say a lot of people are terrified of heir skillset becoming obsolete -- I'm not sure I see that in web developers. Everybody I talk to is happy that their knowledge is now obsolete of which array methods don't work in IE8, for example.
Possibly a lot of the backlash against JS comes from conversations that go like the "How it feels to learn JavaScript in 2016" essay rather than like the one posted here.
Agree: for me it's nothing to do with fundamental obsolescence. JS as a language is doing fine and I welcome the new additions in the various ECMA standards.
What I'm not so welcoming of is, for example, the Angular 1.x -> Angular 2, 4, whatever transition. I don't want to have to keep thrashing my projects due to incompatible upgrades.
And I'm tired of the hype cycles. Not so very long ago everyone and their dog was banging on about how React was the next big thing, and now a lot of them are running scared over the patents issue. It seems like almost overnight all I read about now is Vue.js, but I know that in another few months, or maybe a year, everyone will have moved on again.
Fundamentally there's just no incentive to invest, especially not if you have other things you also need to focus on in your work and life.
The easy way to avoid hype cycles is to just ignore the thing being hyped for a few years. I don't know the exact value of a few; five should be enough to clearly tell whether a fad is a failure but you might miss too many new things that are actually novel that way.
Not to be pedantic, but if you have a 5k line JS app that "wasn't written by programmers" who was it written by? If they wrote and shipped a 5k line JS app, in my eyes they are programmers - but possibly not very good ones.
Well, they weren't professional programmers (not their main job, done out of necessity) and they weren't trained. As I understand it they were actually learning it all on the go (like a lot of new programmers). It wouldn't be shocking if a lot of JS devs were in a similar boat, which explains the community a little bit.
So yeah, they're programmers now, but they didn't start out that way and the app showed it. That's what JS and the browser allowed them to do.
So experienced devs are afraid of learning something that took non-programmers a week to get up to speed and develop a well-architechted app with reusable components etc?
We had a set of non-programmers who built a complex jQuery app over a year, which was then translated into a Mithril app over a summer.
What I said was you can be building complex applications in one of these frontend frameworks in a week. Judging from a few responses in this thread, there are a lot of people who don't want to do that for whatever reason.
Having used only re-frame and Clojurescript for two years now every time I look at where the Javascript guys are I roll my head.
Is nobody even slightly wondering how OOP has infiltrated modern JS development?
Old school Java web development has fully seeped into Javascript with JSX replacing JSP, OOP everywhere.. It looks exactly like the bells and whistles of early 2000 web development.
> Is nobody even slightly wondering how OOP has infiltrated modern JS development?
I would like you to give an example of this. We use the class-syntax, yes, but inheritance usually never goes beyond one level of parent-class-child-class relationship.
If anything, the JS community at large hates OOP the traditional way, and somewhat open to the prototypical pattern.
The ecosystem actually prefers functional constructs. At the very least, an attempt to write pure functions.
That OOP is only skin deep. Look at the way data flows, which pieces of code need to understand any given data structure. Look at the preferred way of extending classes - composition. I think what we have now is not old-school anything, but cherry-picked good parts together forming a New Thing.
The whole story felt sarcastic and also a little nauseous. Not exactly sure whether there is intended sarcasm or not.
The process looks quite complicated where you have to figure out lots of "buts," "whys," and "gotchas," while keep telling yourself, "What the hell?" all the time.
Yeah to me it read like porn dialogue. The first person narrator gives gentle instructions and every line from the naïve second party is unrealistically enthusiastic.
It cannot be simple - it's there to intimidate the new employees/team members. The setup is never wrong, but "the way we do it here" - a particular initiation ceremony. Those indocile will be reported to line manager as bad team members who undermine the team spirit. Usually a junior QA person and a scrum master are the gatekeepers of the setup, green build, and the history of git commit messages.
In all seriousness, if this is what you encounter at your workplace, you need to get out and work somewhere else; this is an extremely toxic environment.
Even if the build setup is the most complex thing on the face of the earth, if you or team members get reported for undermining the team because you don't understand it, then those are not the team members or managers you want to work with or for.
I had a dev write some "modern" Javascript in a project. We neglected to test in slightly out-of-date safari on Mac. Took forever to figure out that "let" keyword was not supported.
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.
Want a library faster than mithril, no runtime download, & handlebars syntax? Try Sveltejs.
Rollupjs also has "treeshaking", meaning your transpiled bundle only includes the functions that are referenced allowing you to organize your code into large modules or even use a monorepo.
I am too old and I wrote an AJAX chat before AJAX was called that and before jQuery existed. This left a mark on my soul manifesting in a very hostile attitude towards JS.
But of course as JS spreads I am looking, reading and mostly just shaking my head. But man, Svelte makes sense. For the first time in about 15 years, a JS framework makes sense.
you don't have to make a monolith web app, or use React, Angular et.al, or transpilers, not even JQuery. State can be managed by observable pattern or event listeners. example:
Parts of the app can be abstracted into micro-services. For example the signup can be it's own micro-service.
Or using the plugin pattern each widget can be independent/untangled.
I think a more appropriate title is what it's like to learn front end web development in 2017, not much of the discussion has anything to do with language details and everything to do with MVC and html.
That's a very impressive demo. I did Javascript development full time from 2012-2014 (Node.js 0.8 and Angular 1.0) and it's amazing to me that essentially none of the constructs he mentions were available then. It wasn't that long ago!
That article is focused on React/JSX. Having coded Nuxt/Vue apps I seriously can't relate. With Nuxt you don't even have the build/setup pains. It just works. It just builds.
You haven't read the article, apparently. It focuses on Mithril (not React). And Nuxt simply abstracts the build step away server-side, so it's still there.
It's too bad they don't address state management. Right now it's just showing how to bootstrap a static app without state changes. How do you even update your data in Mithril?
The planets variable is static in this example, but planetFilter changes. The "Voila, it works" link near the bottom of the essay leads to a live demo: https://brlewis.github.io/2017/planets.html
Was there a particular aspect of state management you want to hear more about? I'm thinking of a follow-on post. Not sure whether the next one should be state or build system.
Oh, you're right. The state management was so subtle that it actually didn't click when I read it. I don't understand how it knows to rerender though? From what I can tell you're just setting the variable planetFilter and that's it, while with React you would have to do a setState to register it.
By default, Mithril redraws the app after DOM events fire (in this case `onchange={filterHandler(func)}`), and when ajax requests are complete (using the `m.request()` XHR wrapper).
You can also manually trigger a redraw by using `m.redraw()`, but it is rarely needed.
