9 ms·

Yes. I feel like we're in the dark ages right now. JavaScript - Dynamically typed, does not scale what so ever. Code written in it becomes 'read only' very qui

• mncolinlee 10y ago
  These complaints are all valid and serious. I believe the solutions involve writing more readable code in languages that compile down to Javascript, CSS, and HTML. There are thousands of languages that compile down to JS. https://github.com/jashkenas/coffeescript/wiki/List-of-languages-that-compile-to-JS https://github.com/jashkenas/coffeescript/wiki/List-of-langu... There are several languages that compile to CSS, like COMPASS and SASS. There are various document formats that freely convert to and from HTML, like Markdown and DocBook. However, HTML is probably the most readable of JS/CSS/HTML. While you can write native JS/CSS/HTML, you're inviting unintended complexity to your project whether or not you remember sending the invitation. There's nothing wrong with that, but you should be aware which choices are best for your team and for the scope and requirements of your project.
  • flukus 10y ago
    Those are incredibly leaky abstractions. You have to know the language, you have to know javascript (for debugging) and in many cases you have to know exactly how the language is transpiled into javascript.
• captainbenises 10y ago
  This post makes me sad. Javascript, CSS and HTML can all be used powerfully, performantly and in a managed way where anyone can come on board and contribute. Facebook, Google and Microsoft all use the web stack to run huge companies. To broadly paint this web stack that so many people poured countless hours into making, as 'impossible' to use is doing it a great disservice. But hey man, that's just like your opinion.
  • pdonis 10y ago
    > Facebook, Google and Microsoft all use the web stack to run huge companies. And they throw huge amounts of resources at the web stack to do it. It might work for them, but I'm not sure that makes it powerful, performant, and manageable for those of us who aren't huge companies.
    • wcarss 10y ago
      And even their code is still often bloated, maddening hacks on hacks.
    • gbog 10y ago
      You probably do not have the complexity level of these companies either. To me js and css are kind of manageable, a bit the same way as python: use strongly enforced linters forbidding anything ambiguous, do not jump every other day in a new sexy bandwagon, and do not let one line of code commited in without an automated test running it on a ci machine. What I found harder to manage is the young FE devs themselves: for them it seems every new project, or every new view in the same project, is the opportunity to use a completely different, new toolset. Oh, and some new syntaxic sugar candies supposed to "save" a couple of keystrokes (which is the worst reason you can find to use a new syntax requiring its own tools). I find this very dangerous, especially when the github repos holding these tools are 3 months old.
      • sotojuan 10y ago
        Your last paragraph describes my experience with web development exactly. Ironically I'm 22, but I've worked with people or talked to people online who want to use the "latest and greatest" for what could've been a simple CRUD app.
      • tempodox 10y ago
        > You probably do not have the complexity level of these companies either. Have you looked at the microservices craze lately? You need a new one of these each time you scratch your head.
      • 10y ago
• lobster_johnson 10y ago
  React is, in my opinion, a big step forward in reclaiming the front end as a mature UI environment. I have also found that CSS becomes a lot more tolerable with CSS Modules, in combination with React, which allows you to write CSS that targets one component and only that component. By eschewing cascading, you can finally write modular, reusable CSS that avoids side effects and still allows fine-tuning (overriding) by the component user.
  • niccaluim 10y ago
    I agree—I loathe frontend development, but React made it tolerable to do for limited periods—but it's still a hack on a teetering Jenga tower of hacks.
    • dcposch 10y ago
      The really funny thing is that the OS runs a simple event + render loop, then the browser implements a wildly complex stateful/declarative structure on top of that (the DOM), then React apps create a simple event + render loop again, this time with special diffing logic to update the underlying DOM as little as possible
      • jacobush 10y ago
        And no doubt this layering will continue... "Look how I easily render this document decription into react primitives".
        • sotojuan 10y ago
          https://news.ycombinator.com/item?id=12473549 https://news.ycombinator.com/item?id=12473549 I made this comment in another thread, but it fits right into this one too.
        • tempodox 10y ago
          Yes, we write web browsers in JS, simply because our browsers let us write nested browsers in JS. I'm only waiting for an OS written in JS so we can use its editor to write an OS in JS.
• segmondy 10y ago
  Languages don't scale. Systems scale. Without said, Javascript has never really been the language for programming in the large. But make no mistake about it, it's slowly getting there as is evident by huge applications, not just web but even desktop that are being built with it. It's not impossible to refactor. The issue from what I've seen is that people think it as if it's a class based language instead of the prototypical language that is.
  • rer 10y ago
    > Languages don't scale. Why not?
  • wvenable 10y ago
    > The issue from what I've seen is that people think it as if it's a class based language instead of the prototypical language that is. This always gets trotted out as the issue. "It's not JavaScript that's bad for building large applications, it's just everyone is using it wrong." Prototype inheritance is even more brittle and hard to follow than class-based inheritance which is why developers, for their own sanity, try and shoe-horn it in.
    • astrodust 10y ago
      We put people on the moon without benefit of "scalable" languages, we built entire operating systems in C which is notorious for quickly becoming unreadable, and we've somehow built an entire world of content using HTML and CSS. JavaScript is just a language, and while improvements to it are being made constantly, the biggest obstacle is not the language, nor the way browser makers support it, but the absurdly slow pace of some organizations to update their browsers to something sane. Pick a language, any language, and then restrict yourself to features only ten years old. That's what JavaScript is like in some cases, but the good news is ten years ago some pretty good things were happening.
      • wvenable 10y ago
        > We put people on the moon without benefit of "scalable" languages The computer for the Apollo missions had approximately 64Kbyte of memory and operated at 0.043MHz. My wrist-watch is many orders of magnitude more powerful than that. But the programming effort that went into it was huge (literally: https://cdn-images-1.medium.com/max/800/1*qJnPOGdtk1q7dq17tx1aYg.gif https://cdn-images-1.medium.com/max/800/1*qJnPOGdtk1q7dq17tx... ). If we were stilling coding things that way, we might be able to go to the moon but we wouldn't have self-driving cars. > Pick a language, any language, and then restrict yourself to features only ten years old. C# 2.0 in 2006 added: Generics Partial types Anonymous methods Iterators Nullable types Getter/setter separate accessibility Method group conversions (delegates) Co- and Contra-variance for delegates Static classes Delegate inference Not to mention C# 1.0 already being statically and strongly typed, had properties and events, reference and value types, interfaces, namespaces, and a reasonably complete standard library. And that's just one language. JavaScript is so far away from this it's not even funny. It doesn't even have proper numeric types. It's casting rules compare favorably with PHP! So I don't buy the argument that JavaScript isn't suitable for large projects because browser makers aren't keeping up with the latest standards. JavaScript is a scripting language that's been pushed into tasks it's not suitable for because it is everywhere.
• veidelis 10y ago
  We use TypeScript and at first it seems like a burden, but pays off after a while. We used to have a problem with CSS - every time we had to implement some new UI, we just ended writing stronger selectors to override the parts that felt would break if we refactored them. CSS modules solves that problem for us. It's nice that we are allowed to use flexbox. The biggest problems for us are that <video> events are not being dispatched properly or scaling problems when keyboard appears.
• jordanlev 10y ago
  CSS is not impossible to manage if you keep things modular and avoid specificity issue (basically, use something like BEM and pretend the "C" in "CSS" doesn't exist). re: HTML: layout and positioning is the domain of CSS, not HTML. HTML's purpose is to provide semantic structure to the content and non-semantic styling hooks (divs and classes) for CSS. It's true that layout has sucked for a long time (more accurately, it hasn't really existed in CSS), but with the coming grid spec, it will finally get a lot better. Flexbox is great for solving certain problems, but wasn't intended to deal with overall page layout. (Basically, flexbox is for laying out one dimension -- a single row or column -- whereas the grid layout spec will handle two-dimensions.)
  • hackerboos 10y ago
    We use BEM and Sass at work and our CSS is still an unwieldy mess.
    • StrangeOrange 10y ago
      Ever thought you're just not that great at writing it? I tend to use a combination of BEM component based rules and AtomicCSS inspired class-style, and my Sass tends to be pretty damn clean. I think a lot of the problems with "web dev sucks!!12" mentality is that people come to it thinking that it should be easy, but it really isn't, and it's not going to be anytime soon. Trying to build applications for multiple browsers to be used on multiple devices on multiple OSs that look good and work well isn't an easy job. No, it's not perfect, but if you pay enough attention and do things right then it's quite a nice experience. If your CSS sucks, maybe don't blame your tools before you blame yourself.
  • GrinningFool 10y ago
    The thing that makes me dubious of this claim is the number of years for which we've been reading variants of, "the upcoming (grid/flex/canvas/css3/html5/ecma spec/etc) will make things much better".
    • jordanlev 10y ago
• myfonj 10y ago
  > HTML - At the heart of it, the foundation is the layout engine and positioning I'd oppose: HTML is particularly a Markup Language for (more or less) semantically structured static documents tied together with Hyper Text links (see the abbreviation?). It has with very limited (if any) amount of layout, positioning and visual hints incorporated; these things are supposed to be left for the CSS.
• snicky 10y ago
  While I agree with most of what you wrote, I also understand where it all came from. We have a handful of browsers which all implement w3c guidelines in their own way and there's no single de-facto standard of how one should write for web. Yet we write milions of different websites and they have to be properly displayed on at least a couple of popular browsers, no matter how bad they interpret the guidelines. Yes JS is a major pain in the a and there are loads of various packages achieving the same things floating around, there's no agreement regarding which package manager to use and everybody uses different implementation or wrapper (es6, es7, typescript, flowscript, coffee), but if you look around you can find solutions that are actually really helpful to manage the mess. It helped me a lot when I started to write JS in a OOP fashion utilizing dependency injection and MVVM. The real trick is to realize which technology is really helpful and which is just bloat. I don't think this is much different from the backend programming. In terms of CSS it's a whole world on its own and I keep repeating that managing it properly is well underestimated. It requires making lots of predictions about how you might extend your site in the future. Luckily, there is also plenty of great reusable boilerplates made by very smart people like bootstrap or materializecss. Bootstrap did change a lot how we write and think about our styles. Btw, leave classes for styling and use ids for js instead. Finally, I don't agree with your opinion on HTML at all. It's super simple and you can build anything with it. I have learned the basics and built my "home page" when I was 12. These days kids are probably building sites before they even go to school. Also, as mentioned above you have to fit dozens of different browsers and hundreds of thousands of various devices. I find building UIs on iOS and Android not much easier, even though you build for a single system. Nonetheless I'm waiting to see how people could improve building UIs in the future, without falling into "everything looks and feels like wordpress" kinda world.
• LBarret 10y ago
  look at elmlang maybe ? it solves a few of these problems, but this is quite different from what we are used to.
• deleted 10y ago
  [deleted]
• andrei_says_ 10y ago
  I think it's important to acknowledge that today we're using CSS in ways that were hard if not impossible to imagine for the creators of the standard years ago. The much higher complexity requires new ways of thinking and methodologies. BEM for example is one such approach which helps with scaling.
• gaius 10y ago
  The web was conceived for hypertext and doesn't do a bad job of it. The actual problem is that people took something that was always intended for displaying (illustrated but mainly text) documents that happened to have clickable words that would display other documents, and tried to make it do desktop-style applications too. We've been hammering square pegs into round holes ever since. And the infuriating thing is we had a great system for doing what HTML+JS+AJAX etc etc does now - it was called NEWS. But those who forget history are doomed to repeat it, first as tragedy and then as farce. Not sure which stage we're on now, maybe both.
  • refset 10y ago
    >clickable words that would display other documents https://en.wikipedia.org/wiki/NeWS https://en.wikipedia.org/wiki/NeWS ;)
  • DanielBMarkham 10y ago
    That's exactly what I was going to say. It was never meant for all of this in the first place. We've spent millions of man-hours trying to turn a squirrel into a dinosaur. Worse yet, it's becoming more and more difficult to simply read the freaking web as a series of documents, which was the entire purpose in the first place. There's TOS, pages that don't work without JS, and so on. I fully expect publishers to try to force legislation to require people to download all this crap simply to read an essay, whether they want to or not. We had a nice hammer, and we're doing a pretty good job of pounding everything else in the universe into various versions of a nail. But it's ugly.
    • TheOtherHobbes 10y ago
      >We've spent millions of man-hours trying to turn a squirrel into a dinosaur. And worst of all - we succeeded.
  • rtpg 10y ago
    Is it really square pegs for round holes? I don't think that the web as a mechanism for distributing applications would look much different even if it hadn't gone through the HTML stage. If not JS, it would have been Java applets. If not HTML, then some weird XML layout schema. There might have been a time where the web as a platform for applications was beyond silly, but this is not htat time. The platform is decidedly for shipping applications as well as pages.
• zyngaro 10y ago
  When I see something like visual studio code to cite the first that comes to mind I think that these claims are overstated.
• douche 10y ago
  I think you mean write-only. It doesn't help that the inclination to minify and bundle CSS and JS makes them somewhat impervious to organization. Sourcemaps are supposed to help with that, or so I've heard... they are another of those things that I've not seen work reliably.
• meredydd 10y ago
  If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages and three frameworks: * HTML * CSS * JS * A server-side language (eg Python) * SQL And then come the (leaky) abstractions on top of them: * A framework to make JS bearable (eg Angular) * A framework to make server-side bearable (eg Django) * A framework to make CSS bearable (eg Bootstrap) ...and often... * A framework to make SQL bearable (eg SQLAlchemy...) When someone asks me how to learn to build web apps - even someone who can already program a bit - I feel embarrassed explaining to them what a pile of patches the Web is. Even if the languages themselves were saner, this is a monstrous amount of complexity for something that takes one language and a drag'n'drop GUI builder on any other platform. Trying to fix this, at least for simple apps, is why we built Anvil - https://anvil.works https://anvil.works - where everything is in Python, and the GUI is drag'n'drop.
  • erlich 10y ago
    You can literally use Javascript for all of this.
    • meredydd 10y ago
      I think you may be misunderstanding my point. If you have to invoke a brand new JS framework with limited uptake and many competitors, and "one of a million" CSS frameworks, in order to declare this problem solved, you are perpetuating the problem. I don't want to knock these tools too hard, because I can readily believe that (eg) Flow, or Typescript, or whatever we'll all be using next week, is much better than using vanilla JS/CSS. But the fact that we need to know all of Flow, and all of JS, and all of bootstrap, and all of CSS, and we're still not even off the client yet, is exactly why the web is a mess.
      • erlich 10y ago
        My thinking on this is that everytime someone has tried to unify these tools it hasn't gone well. Think about Google Web Toolkit, or Microsoft's XAML. It's better to have everyone experimenting, blogging and doing their thing, and the best ideas rise to the top. 2015 was probably the worst time to be a web developer on a greenfield project. You had Angular deprecation and the Flux wars, and Babel 5 -> 6 migration. I do agree its a mess and a freaking nightmare most of the time. I've spent hundreds of hours setting my toolchain up and if something like webpack were to lose favour, I would be devastated. I think we are in need of a Rails for modern JS. My prediction is that we will see this emerge soon. A shift from project-templates to simple, generic plugin system. Webpack seems quite strong as the packager. Angular 2 CLI just migrated to webpack from Brocolli for example. React and Redux are standard now. And npm is the package manager of choice.
• erlich 10y ago
  It sounds like you are unfamiliar with what modern JS looks like. > JavaScript - Dynamically typed, does not scale what so ever. Flow has resolved this. It has good investment from Facebook, plenty of adoption, a flexible type system, and you can sprinkle it into existing code as you like. Also try wallaby.js for instant test running. > CSS - Also becomes impossible to manage. See webpack's local css scope. https://github.com/webpack/css-loader https://github.com/webpack/css-loader. > HTML - At the heart of it, the foundation is the layout engine and positioning, and it sucks. Flexbox was supposed to bring sanity, but I feel like we're still waiting on it. Bootstrap or any million css libraries. Just have to wait for Flexbox and we are good.
• unclebucknasty 10y ago
  Indeed. You only left out the proliferation of frameworks du jour, which promised to deliver us from this pain, yet somehow seemed to only amplify it with additional layers of pain.
• HeavyStorm 10y ago
  Only, in my case, I don't think of it as high paying.
• kenbellows 10y ago
  Minor comment regarding CSS: Flexbox alone was never supposed to fix layout; the real magic is supposed to be Flexbox + CSS Grid. As I understand it, Flexbox is truly designed for use in one dimension to govern local dynamic behavior within a larger CSS Grid layout that structures the whole page. At the moment the problem is the lack of CSS Grid adoption by browsers (see http://caniuse.com/#feat=css-grid http://caniuse.com/#feat=css-grid). I'm still hopeful that the state of CSS layouts will drastically improve once Grid and Flexbox are both sufficiently supported.
• simonhamp 10y ago
  When you build a better language, server platform, viewer application, development tools and ecosystem that can create, render, transmit and load dynamic user interfaces over the wire - even rapidly on limited bandwidth connections - please let me know ;) I'm not saying it's the best thing ever, but we're not doing too badly all things considered. The web is still young. Let's work together to make it what we want it to be - what it should be - instead of moaning about what it isn't.
• jawarner 10y ago
  So instead, just use: * TypeScript * Sass * A data-binding framework like Angular Problems solved :)
• nameless912 10y ago
  Blaming JavaScript's failure to be maintainable on being dynamically typed is a bit of a red herring in my opinion. Lots of dynamically typed (or, more accurately, duck-typed) languages have plenty of facility to make good, maintainable code, and JavaScript does too. The problem is that JavaScript has more warts than good parts, and the warts prove to be too easy a temptation for many average programmers.
• tengbretson 10y ago
  > JavaScript - Dynamically typed, does not scale What does this even mean? I see the phrase "does not scale" bandied about all the time. In what way is a language supposed to scale? It seems like its just the latest semi-technical hand-wavy way to disparage something.
  • morenoh149 10y ago
    I think he means very large projects. > 10k loc. See http://www.pgbovine.net/migrating-legacy-codebase-to-typescript.htm http://www.pgbovine.net/migrating-legacy-codebase-to-typescr... for example
• 0xmohit 10y ago
  JavaScript - Dynamically typed, does not scale what so ever. Code written in it becomes 'read only' very quickly. Impossible to refactor. Consider the _brighter_ side of it: - the one who authored the code is irreplaceable - employment generation: many more are needed to maintain (and possibly enhance) what one person might have written
• lucb1e 10y ago
  > Same problem, read-only, it only gets bigger I think that's write-only