12 ms·

This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered

This is my experience of web development, every time I return to it. I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don’t know much about programming language design, so they can’t see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods. If you recognise JS as a terribly designed language, then the last thing you would imagine doing is widening its use. But that is exactly what node.js does. You should instead isolate JS and minimise its use. So red flag - something has gone wrong here. It also feels that many web ecosystems have an over-inflated sense of self-importance. This has led to many competing frameworks for the same tasks, that try to do everything. Things are not pythonic. There appear to be an excessive number of package managers involved. There were already plenty of package managers out there - inventing new versions of existing tech makes it harder for everyone and is usually a red flag that someone somewhere is making bad decisions. I need to build a website soon and I’m dreading the front end. At the back end I can use range of solid and well designed languages and technologies, but at the front end I feel like I’ve got to choose the least poor of a bunch of crazy options. If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful. “Sane web dev to minimise the impact of the Web Dev CSS/JS disaster on your life” would be my favourite O’Reilly of all time.

keldaris 9y ago
I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing options are there now?
- Vinnl 9y ago
  Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.
  - randomsearch 9y ago
    TypeScript has previously been recommended, so I will take a look. I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.
    - fulafel 9y ago
      WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.
      - naasking 9y ago
        > WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. How come?
        machiaweliczny 9y ago
        It's too simple to support dynamic language features AFAIK.
        naasking 9y ago
        So are machine instructions. It wouldn't be any harder to build a dynamic language runtime on web assembly than for regular assembly.
k__ 9y ago
I didn't find JS any worse than Java, PHP or Python. They all have really ugly parts at least in JS they don't slow you down.
- innocentoldguy 9y ago
  I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is true: 9999999999999999 == 10000000000000000.
  - BigJono 9y ago
    I've been a professional Javascript dev for over 5 years and never once run into a bug due to any of these problems. I agree that they are problems, but their impact on day to day use of the language is zero. If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to death by the community. The language itself is the last problem with JS
    - hnzix 9y ago
      I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal. I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard. I guess worse really is better.
      - k__ 9y ago
        That's like saying group XY of people is bad because you got mugged by one person of that group one time. While I understand that a problem like this is unnerving, it isn't the rule.
pka 9y ago
> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, focused on pragmatism) would be right up your alley. If you're ok with a dynamic language (i.e. strike rigour), then look no further than Clojurescript [3], Clojure's [4] little web brother. An elegant and simple Lisp, it makes almost all other dynamic languages completely obsolete. There most definitely are sane options for developing for the web if one is willing to use a compile-to-js language. [0] http://elm-lang.org http://elm-lang.org [1] http://www.purescript.org http://www.purescript.org [2] https://reasonml.github.io https://reasonml.github.io [3] https://clojurescript.org https://clojurescript.org [4] https://clojure.org https://clojure.org
- aaron-lebo 9y ago
  That's incredibly high praise for Clojurescript. It's got some great features but it has flaws, too. I feel like many people new to web dev would be more confused setting up a Clojurescript project than they would be with JS. It was a lot of googling when I did it a couple weeks ago, and that's coming from someone who has done several times over the years (what's this boot thing, I was told lein was the best thing ever?). Those are all great languages. It is important to realize that they will increase bundle sizes, which is a common rant about web pages these days. Hello world in Bucklescript/Reason, for example, is 23 KB (anything touching the std lib at least), Elm much bigger than that. My friend's 500 line Clojurescript/Reagant app was over 500 KB uncompressed, 5k lines of JS will come in at 140 KB. It's worth being aware of the tradeoffs you are making, because often when people are selling new tech they tend to overstate advantages and understate disadvantages.
  - pka 9y ago
    > It is important to realize that they will increase bundle sizes Absolutely, and it wouldn't make sense to program a tiny static webpage in e.g. Purescript. That said, to put that into perspective, pulling 350 npm modules for a bigger project is kind of the norm now. Using compile-to-js languages will incur more overhead still and it depends on the project whether that's acceptable or not, but many times it most definitely is (also, I hope webassembly will help with bundle sizes in the future.) I'm not really up-to-date re Clojurescript's package manager, but I know people who've specifically stated that one of the reasons for using Clojurescript is that package management and bundling is just so much easier than the standard JS npm/yarn/bower/gulp/webpack/etc amalgamation.
nawitus 9y ago
Modern JavaScript is not a very badly designed programming language. It's a good, productive programming language. Most of the quirks can be disabled with a linter, and optionally a lot safety can be brought in with typing (using e.g. TypeScript). On the other hand, many developers don't know much about programming and JavaScript, and therefore tend to have unjustified criticism of the language. JavaScript was a perfect choice for Node.js. It's event-driven design is a perfect fit for a performant web server. Python would have been a bad choice, because it didn't support asynchronous programming when Node.js was created. Furthermore, using the same language in the backend and frontend will reduce context switching, enable code reuse and generally speaking improve implementation efficiency.
- pleasecalllater 9y ago
  Yea, modern JS... it's just a joke, no integers, still funny effects with []+[] and {}+{} and []+{} and {}+[]. Good luck with writing anything serious using such a crap.
  - skrebbel 9y ago
    Both ESLint and TypeScript solve all that. In all honesty, if you're not using tools like that I'm not sure you're doing "modern JS development". It's like complaining that modern C++ is a mess while refusing to use references and RAII.
    - TeMPOraL 9y ago
      In C++, proper tools are part of the language. In JS, they're part of ecosystem of third party components that's changing on a weekly basis. There's a difference.
      - skrebbel 9y ago
        ESLint was released in 2013. TypeScript in 2012. People keep complaining about this "weekly basis" stuff but really the pace has been pretty slow lately. If you want to use constexpr in C++ you're going to have to upgrade your compiler as well, right (and, if you're unlucky, "migrate your project files" and all that mess)?
mnm1 9y ago
Try Clojurescript + Reagent. There's no reason to use JS if you have a choice.
cc81 9y ago
I would argue that web development have never been as easy as it is now and that a lot of people just does not take it seriously enough to bother to learn it properly. People think that just because that they did some jQuery development 10 years ago they should be able to use to the same skills now and discard all new developments. Being able to use modern JavaScript and with linting/prettier will in practice make it pretty rare that you end up doing stupid things due to language limitations. And if you want types you have TypeScript that works very well in most work flows. html/css is pretty ok to work with these days and libraries like React and that echo system makes it pretty easy to scale web development so that many people can be involved in the same code base.
- adventured 9y ago
  The nice thing about the current situation is, if you want to you can still use jQuery, basic CSS & HTML5 and ECMA sub version 6 for 99% of all sites that exist and are likely to exist. That will remain true for the next decade at least. Most sites are not applications and never will be. Most businesses will never need a complicated site. Most of the Web has zero beneficial use for React or ECMA 6. Factually that's easily demonstrated just by looking at data compilations of what the Web largely consists of: static content, typically pushed out into the world via a basic CMS. That isn't going to change. Most of what's going on is an evolution in the top tiers, up the value chain. Facebook & Co have dramatically greater technology demands than Joe Small Business or Susan the blogger.
- ffang 9y ago
  Easy? No, I believe it's very hard to setup a frontend project.
  - cc81 9y ago
    1. install node.js 2. npm install create-react-app 3. create-react-app your-app 4. npm start Now you have a react app with a development up and running. To create a production build write "npm run build". To add a package write "npm install the-package".
  - shados 9y ago
petra 9y ago
>> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend Low-code tools are worth a look, depending on your task. Due to some reason, they are rarely mentioned at HN, But they already work very well for business apps, with some tools even claiming "pixel-perfect" ui creation, so maybe it can work well for consumer apps too. And Amazon/Microsoft and Maybe Google are all working/having on such tools, so it may indicate these tools are becoming popular.
cousin_it 9y ago
I think JS is fine. The root of the "problem" is that the web is an unusual platform. It actually punishes bloat, in a way other platforms don't. A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly. That means web developers must learn that code reuse is a tradeoff instead of seeing it as a pure positive. That's a good thing in my book. Either take the heat and replace your 10 dependencies with 1000 custom-written lines, which is usually easy in JS, or get out of the kitchen.
- gaius 9y ago
  * A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly.* Except that native apps, in practice, don't do that, and websites routinely load 10Mb of JS when the user only wants to read a 5Kb article.
  - cousin_it 9y ago
    The New York Times app for iOS is 119.8 MB.
gaius 9y ago
I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language Let's take a step back here: the web is designed, from the ground up, for hypertext, interlinked documents comprising text and images, some of which are clickable and lead to other hyper-documents. HTTP - hypertext transfer protocol. "Web dev" should be referring 100% to things that happen on the server, which can be in any language you like, generating documents that are rendered as the end user would like. Forcing a thing designed for documents to run entire applications is what has gone wrong, it is, on the most fundamental level, an incredibly stupid thing to even try, but the entire industry did, and here we are today. It would be like MS declaring all Windows development henceforth will be in VBA macros for Word. This is why the real engineering disciplines don't take software engineers seriously. You would never see a civil engineer try and construct a bridge out of some completely inappropriate material...
- bryanrasmussen 9y ago
  it may be, on a fundamental level, an incredibly stupid thing to even try, but it also seems to have been an incredibly necessary thing and incredibly appreciated thing by most of the world.
  - gaius 9y ago
    Necessary how? All the actually useful things you can do on the web you could have done with a 90s browser. I bet Amazon still works in one! Moving apps into browsers is a step backwards for most apps and most users. I was using Jupyter the other day; it’s clunky as hell compared to MathCAD from 20 years ago. We use 1000x the computing power, literally, to deliver 10% of the experience. Keeps a lot of devs employed I guess...
    - adventured 9y ago
      > All the actually useful things You're pre-emptively trying to define what's useful for everybody else. That's the only way your premise works. In my equally subjective view, XMLHttpRequest radically altered and improved the useful things you can do with the Web. You can't use a 90s browser for Google Maps, Gmail, YouTube, nearly any online productivity software, and dozens of other common activities on the Web today. You would have to strip the services down to make them work, ie turn them into completely different products. Simply put, most of the things most people do online today, can't function in a 90s browser. Just try using IE 5 or Netscape 4 with nearly any of the major Web services today. You can't. IE 5 with Facebook's non-mobile site? You have to build an entirely different product to make that work, basic interactivity drops to near zero. 1990s MapQuest sucked, big time. Google Maps is a radical improvement. How about simple things, such as smooth, fast, highly interactive stock charts, or real-time updating stock quotes, without having to reload the page constantly? 1998 browser? Nope. Would the user experience be better if everything on the Web adhered to strict 1998 standards? That's an obviously subjective opinion. I don't think so. Do people like to see instant previews of the content they're about to post to Facebook or Twitter? When they click the little upvote arrow, do they like to see an appropriate reaction? When posting basic content or interacting with simple site features, do they like having to reload the entire page?
z3t4 9y ago
can your web site be pre-rendered or rendered on the fly? then do server side rendering - only send html to the client. if you need dynamic rendering - use static js - only for those parts. if you need everything to be dynamic rendered eg live push, multiplayer games etc do full js rendering but do not use static html! only css/js. i think the complexity comes from web devs familiar with server rendering tries to use the same paradigm with dynamic sites for example angular and react. you should do it more like a desktop app instead of web page. if it makes sense do the rendering in canvas instead of the dom.
jugularkill 9y ago
You said it. You're not an expert. You are comparing a prototype based language to oop languages. You're basically putting the wrong fuel in a car and blaming the car. You are lazy in my opinion because yes there are few resources that teach you how to use the language properly but plenty that compensate for those who want to make it familiar to back end devs. If you looked for good resources you will slowly discover that most JavaScript developers do not understand the language well because of the same assumptions you are making. It's a highly misunderstood language due to human stupidity.
- eitland 9y ago
  While it is certainly possible to understand JS it is - IMO - a waste of brain cycles that we have to live with. There's no doubth in me that even very good Javascript programmers can be significantly better in a better language. E.g. Typescript gives you literally all of JS - and a way to keep things tidy. Typescript which is a compile-to-js language in a weird way proves how lacking js is - while still buildiing on top of it.
  - jugularkill 9y ago
    "very good Javascript programmers can be significantly better in a better language." This is not how it works. Take this idea that JavaScript is a "badly designed language" out of your head and understand that about 99% of JavaScript's behaviours are intentional. The majority of gotchas in JS are shown by people who don't understand type coercion, prototypes or who expect it to behave like x language. It is not just misunderstood by your average Joe JS dev, but also by many who claim to be pros and experts. JavaScript is a language that doesn't tell you how to do things, there are no constraints. This is why so many people suck at it. They want to use statically typed classical inheritance constraints on a language oriented around higher-order functions, coercion and literally everything being an object. If you are somebody who is intuitive enough to create your own restrictions on what to use and what not to use in JS from the POV of the language's architecture then you will love it. If you are convinced that there is already a holy grail structure to programming languages then you will always have problems with JS. TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP. OOP languages are already hugely problematic when it comes to complexities. So imagine how overly complex the JavaScript eco system is becoming due to a generation of developers who want it to be more like x OOP language it does not have the foundation to be like. There is no defacto solution for software engineering everything still sucks, and nobody remotely has it figured out.
rco8786 9y ago
> There appear to be an excessive number of package managers involved. Largely agree with your assessment except for this. Which package managers are you referring to? 99% of the js world uses npm, and the other 1% uses yarn. I’m not aware of a single other package manager in the web ecosystem. In fact this is probably one thing where they got it right.
- tatersolid 9y ago
  Bower?
  - LocalPCGuy 9y ago
    It's all moving to npm
- LocalPCGuy 9y ago
  And those 2 are largely interchangeable because they use the same repository (barring unusual setups)
naasking 9y ago
> I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. It is, but it's getting better because so many different approaches have been tried that some of the more scalable and maintainable ones have been worked out. Also, (thank heavens) browser support is a lot more consistent now. > I need to build a website soon and I’m dreading the front end. If you're a software developer, I recommend some atomic/functional CSS toolkit, like Tachyons. That will free you from having to do probably 90% of the CSS work you used to have to do, and it matches a more programmer-type mindset to styling elements. I'm building a site now, and so far it I've just needed to define some style classes for the colours, and the rest of the styling is already included out of the box via their reusable classes. For the JS side, really depends what sort of dynamism you're looking for. You can go with a tiny JS library for polyfilling and standardizing browser behaviour [1] if you're just doing simple DOM manipulations, or if you expect to be doing a lot of AJAX with dynamic rendering, go with something like Surplus [2], or Vue, React or Mithril if you want something more standard. [1] https://github.com/naasking/PithyDOM https://github.com/naasking/PithyDOM [2] https://github.com/adamhaile/surplus https://github.com/adamhaile/surplus
deleted 9y ago
[deleted]
konschubert 9y ago
I feel like everyone is picking up on your language complaint, but maybe that is not your biggest concern. It seems like you give JavaScript as an example, but what really worries you is the complexity of the front end ecosystem. Here are a few ideas to reduce that complexity: Don't use a package manager, you can copy dependencies into folders. Remove steps from your build pipeline unless you really need them. Use ES16 to get native promises and imports. Or don't use ES16, so you can remove that step from your build pipeline. Use as few dependencies as possible. Whenever you can, make use of native browser behavior and CSS.
- LocalPCGuy 9y ago
  Less automation may help reduce his complexity, but will lead to more instances of breaking things do to mistakes due to manually performed steps. In general, I agree with part of your point - only use what you need. But make sure you are using the things you should.
dylanhassinger 9y ago
Node.js with ES6 is a dream. i love it
tastyham 9y ago
What is "PL"? I find it kinda funny that you compare to Python as the way you want webdev to be, since Python and JS are very similar in my mind, aside from minor syntax differences and JS keeping more warts from it's early days, they are very similar environments. I like Python and have been doing some Tensorflow recently, and one thing I've definitely noticed is that Python docs really suck compared to mdn JS docs. The biggest problem with JS on the other hand, is it's lack of a decent standard library so you have to use a lot more 3rd party libs, and setting up a modern babel/webpack/linter/test tool chain is a pain in the ass with so many different options to choose from.
- rwaldron 9y ago
  PL = Programming Language
terragon 9y ago
> Things are not pythonic. You say that like it's always a good thing. I remember I spent 4 hours trying to import a function from a file that was in a sibling directory before I finally gave up and copy pasted the function. There's also other things that really rub me the wrong way in Python. Once you get used to writing computations as a map/reduce/filter pipeline with fat-arrow functions in ES7, Python lambdas and list comprehensions feel so crippled and lacking in comparison. There's a lot of other things that ES7 does really well such as imports, asynchronous code with promises/async-await, array/object destructuring, the spread operator, etc. Don't get me wrong; I love Python and use it heavily in my day job, but it's not the end all and be all. There are fantastic libraries written for Python that make life really good (think Reportlab), but for applications that are highly asynchronous and I/O heavy, I'd take ES6 running on Node any day over Python.
davidjnelson 9y ago
You'll likely love typescript. You can spin it up with: npm install -g typescript then put this in a tsconfig.json file: { "compilerOptions": { "emitDecoratorMetadata": true, "module": "commonjs", "target": "ES5", "outDir": "ts-built", "rootDir": "src" } } then run tsc -w you can tweak the compiler for prod or debugging output etc. with these flags for the cli or the json config: https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option... Then you could add a single css file in which you prefix class names using something like: myprojectuniquename__someelement. Then if you use async/await instead of callbacks, flexbox in your css, check supported browser features by googling 'caniuse feature', and use fetch for network access, you could have a pretty simple system that works for you in under an hour.
donohoe 9y ago
Javascript WAS terribly designed but still allowed su to do amazing things. I would argue that in the last 3 years its come a long way and is no longer a terrible language. I think complications of today came from the problems of its past where it was taken for granted that you needed a framework to get around browser differences. My personal and professional view has been use plain vanilla modern JS. Make an informed decision on whether using a framework makes sense for your particular project. If you're making a mess of JS, its more likley you need to re-evaluate your approach to the problem rather than the easy thing to do which is to blame the language.
elmelmelm 9y ago
Use elm.
Dash1909 9y ago
I read all of this, made a 8 paragraph long retort about the stupidity of backend devs in this thread, then deleted it. The reality is, if you don't currently serve a website 1,000,000 people want to use, just pick some terrible server side piece of crap and call it good. If you want 1,000,000+ people to use your website, you better learn that a dynamic user experience is expected, and delivered with eloquent javascript and design.
- deleted 9y ago
  [deleted]
- ccachor 9y ago
  Yes!!!!
mmargerum 9y ago
JS isn’t really terrible, I’ve done 25 years of c, c++, go, pascal, swift and I found js lack of typing refreshing. I built a fairly complex app in 4000 LOC. This would surely have been 10x bigger in any of the languages mentioned above. If you use es6, you get rid of the most common js issues (var hoisting, this scoping, etc) At some point 10x less LOC has to be factored in as a significant benefit
deleted 9y ago
[deleted]
jsvader 9y ago
TLDR; The language design of JavaScript is not the problem. There are 2 problems in my opinion: 1. Our reliance on typed languages, compile-time errors, and IDEs 2. Too many choices for frameworks and libraries. I wouldn't agree that JS is a poorly designed language. I will come back to that soon. I would argue, like some others here that we are just too lazy. We enjoy the safety provided by typed languages and compile-time errors. That is one reason to love our IDEs. Back to the problem. There are a lot of things that you are saying. I will try and address them one at a time. > web dev has been badly engineered. * Yes, no, and it depends. Web Dev is a very board, it encompasses many technologies, like HTTP, HTML, CSS, JS, Application servers, etc. So you are saying HTTP id bad? or HTML is bad? I know I'm reading it out of context, but bear with me. I believe you meant JS is bad. That brings us to your next opinion. > JavaScript is a very badly designed programming language. * When you say badly designed language, what is it that you exactly mean? Is it the syntax? Is it the grammar? Or is it the fact that it is loosely typed dynamic interpreted language? And what are the problems you talk of, any examples? > Is JS a recognized terribly designed language? * Who recognized it, any sources? Like the U.S.A. recognizes ISIS as a terrorist organization. I'm pretty sure the developers of node.js do not recognize that JS is a terribly designed language. > There are many frameworks for the same tasks, that try to do everything. * Yeah, I agree. I really hate having so many choices. I have to spend too much time investigating which is the best one for my use-case. I'm just too lazy. (sarcasm was intended) That said, I still agree, and it does make life hard. But too many choices is not a bad thing necessarily. > There "appears" to be an excessive number of package managers. * There is only NPM, everything else is either deprecated or based on NPM. Please inform yourself better. > ... range of solid and well-designed languages and technologies, but at the front end ... choose the least poor of a bunch of crazy options. * WHAT? There is only 1 option on the web today; JavaScript. Period. Unlike backend. What you are talking about are framework and libraries. Check the "too many choices" point above. If you believe that backend development has fewer choices involved, then I assume that you sir have limited experience. Anyway only recently has the community invested in improving this. Give it time, unless you believe something else can replace it before that.
machiaweliczny 9y ago
For website you don't need any libraries. You might consider some static site generator. For SPA go with create-react-app with react router with TypeScript and MobX and you will be satisfied. If you don't need/want to configure things swap webpack for parceljs.
jpjitendrapal 9y ago
I know when someone comes from C family language, he/she is not able to understand JS first but the person who knows JavaScript programming will never write like this. Actually JavaScript has few concepts those are much different compare to C family language like prototype and pure function which are superb. Even C family languages developer are now thinking to add few concepts from JS language.

keldaris 9y ago

I'm in a similar position, and I've formed the same impression. Furthermore, even though browsers are stuck with JS, given the influx of languages able to compile to JS (or even WebAssembly now) it feels like there should be plenty of options for those of us who would rather stay away from the craziness. Perhaps someone with more frontend experience could comment on what (comparatively) sane, simple and JS-minimizing options are there now?

Vinnl 9y ago
Compiling-to-JS brings in its own set of crazy, and really almost never is worth it. In fact, the only two that make any sense are Babel and TypeScript, and that is only because are (practically) Javascript and because they are stable and widely used projects. If those two wouldn't hold, you'll quickly be running into a whole host of problems w.r.t. interoperability with the rest of the ecosystem, and you'll end up reinventing the wheel again.
- randomsearch 9y ago
  TypeScript has previously been recommended, so I will take a look. I assume web assembly will bring sanity to the frontend PL world, which will be a step forward.
  - fulafel 9y ago
    WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. JS is a vastly more attractive compile target for managed, GC'd languages.
    - naasking 9y ago
      > WebAssembly is not an attractive compile target for general web apps in the foreseeable future, it's going to remain a C/Rust thing unless it changes dramatically. How come?
      - machiaweliczny 9y ago
        It's too simple to support dynamic language features AFAIK.
        naasking 9y ago
        So are machine instructions. It wouldn't be any harder to build a dynamic language runtime on web assembly than for regular assembly.

k__ 9y ago

I didn't find JS any worse than Java, PHP or Python. They all have really ugly parts at least in JS they don't slow you down.

innocentoldguy 9y ago
I disagree. While Python, for instance, certainly has its quirks, it doesn't have multiple ways of declaring a function, each with their own scope and hoisting gotchas. In Python, self isn't ambiguous the way this is in JavaScript. Python's datatypes are straight forward, unlike JavaScript, where 1 + "1" produces a valid result. In Python, 9999999999999999 is precisely 9999999999999999, however in JavaScript this is true: 9999999999999999 == 10000000000000000.
- BigJono 9y ago
  I've been a professional Javascript dev for over 5 years and never once run into a bug due to any of these problems. I agree that they are problems, but their impact on day to day use of the language is zero. If you want examples of real problems that give good front end devs hell day in and day out, start looking at some of the libraries, tooling and abhorrent "best practices" that get thrown out and cargo culted to death by the community. The language itself is the last problem with JS
  - hnzix 9y ago
    I've spent days tracking down a bug around a color picker widget, turns out JS was implicitly casting my string value to octal. I've worked with heaps of toy languages like Lingo, vbscript and ActionScript, and nothing has made me as viscerally angry as JavaScript (ok maybe PHP's complete lack of naming consistency). JS is an accident of history that has somehow become the de facto standard. I guess worse really is better.
    - k__ 9y ago
      That's like saying group XY of people is bad because you got mugged by one person of that group one time. While I understand that a problem like this is unnerving, it isn't the rule.

pka 9y ago

> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful Sounds like Elm [0] (pure, functional, very very easy to start with but lacks abstractions), Purescript [1] (pure, functional, powerful, the best language for the web right now, imo) or ReasonML [2] (functional but impure, familiar syntax, focused on pragmatism) would be right up your alley. If you're ok with a dynamic language (i.e. strike rigour), then look no further than Clojurescript [3], Clojure's [4] little web brother. An elegant and simple Lisp, it makes almost all other dynamic languages completely obsolete. There most definitely are sane options for developing for the web if one is willing to use a compile-to-js language. [0] http://elm-lang.org http://elm-lang.org [1] http://www.purescript.org http://www.purescript.org [2] https://reasonml.github.io https://reasonml.github.io [3] https://clojurescript.org https://clojurescript.org [4] https://clojure.org https://clojure.org

aaron-lebo 9y ago
That's incredibly high praise for Clojurescript. It's got some great features but it has flaws, too. I feel like many people new to web dev would be more confused setting up a Clojurescript project than they would be with JS. It was a lot of googling when I did it a couple weeks ago, and that's coming from someone who has done several times over the years (what's this boot thing, I was told lein was the best thing ever?). Those are all great languages. It is important to realize that they will increase bundle sizes, which is a common rant about web pages these days. Hello world in Bucklescript/Reason, for example, is 23 KB (anything touching the std lib at least), Elm much bigger than that. My friend's 500 line Clojurescript/Reagant app was over 500 KB uncompressed, 5k lines of JS will come in at 140 KB. It's worth being aware of the tradeoffs you are making, because often when people are selling new tech they tend to overstate advantages and understate disadvantages.
- pka 9y ago
  > It is important to realize that they will increase bundle sizes Absolutely, and it wouldn't make sense to program a tiny static webpage in e.g. Purescript. That said, to put that into perspective, pulling 350 npm modules for a bigger project is kind of the norm now. Using compile-to-js languages will incur more overhead still and it depends on the project whether that's acceptable or not, but many times it most definitely is (also, I hope webassembly will help with bundle sizes in the future.) I'm not really up-to-date re Clojurescript's package manager, but I know people who've specifically stated that one of the reasons for using Clojurescript is that package management and bundling is just so much easier than the standard JS npm/yarn/bower/gulp/webpack/etc amalgamation.

nawitus 9y ago

Modern JavaScript is not a very badly designed programming language. It's a good, productive programming language. Most of the quirks can be disabled with a linter, and optionally a lot safety can be brought in with typing (using e.g. TypeScript). On the other hand, many developers don't know much about programming and JavaScript, and therefore tend to have unjustified criticism of the language. JavaScript was a perfect choice for Node.js. It's event-driven design is a perfect fit for a performant web server. Python would have been a bad choice, because it didn't support asynchronous programming when Node.js was created. Furthermore, using the same language in the backend and frontend will reduce context switching, enable code reuse and generally speaking improve implementation efficiency.

pleasecalllater 9y ago
Yea, modern JS... it's just a joke, no integers, still funny effects with []+[] and {}+{} and []+{} and {}+[]. Good luck with writing anything serious using such a crap.
- skrebbel 9y ago
  Both ESLint and TypeScript solve all that. In all honesty, if you're not using tools like that I'm not sure you're doing "modern JS development". It's like complaining that modern C++ is a mess while refusing to use references and RAII.
  - TeMPOraL 9y ago
    In C++, proper tools are part of the language. In JS, they're part of ecosystem of third party components that's changing on a weekly basis. There's a difference.
    - skrebbel 9y ago
      ESLint was released in 2013. TypeScript in 2012. People keep complaining about this "weekly basis" stuff but really the pace has been pretty slow lately. If you want to use constexpr in C++ you're going to have to upgrade your compiler as well, right (and, if you're unlucky, "migrate your project files" and all that mess)?

mnm1 9y ago

Try Clojurescript + Reagent. There's no reason to use JS if you have a choice.

cc81 9y ago

I would argue that web development have never been as easy as it is now and that a lot of people just does not take it seriously enough to bother to learn it properly. People think that just because that they did some jQuery development 10 years ago they should be able to use to the same skills now and discard all new developments. Being able to use modern JavaScript and with linting/prettier will in practice make it pretty rare that you end up doing stupid things due to language limitations. And if you want types you have TypeScript that works very well in most work flows. html/css is pretty ok to work with these days and libraries like React and that echo system makes it pretty easy to scale web development so that many people can be involved in the same code base.

adventured 9y ago
The nice thing about the current situation is, if you want to you can still use jQuery, basic CSS & HTML5 and ECMA sub version 6 for 99% of all sites that exist and are likely to exist. That will remain true for the next decade at least. Most sites are not applications and never will be. Most businesses will never need a complicated site. Most of the Web has zero beneficial use for React or ECMA 6. Factually that's easily demonstrated just by looking at data compilations of what the Web largely consists of: static content, typically pushed out into the world via a basic CMS. That isn't going to change. Most of what's going on is an evolution in the top tiers, up the value chain. Facebook & Co have dramatically greater technology demands than Joe Small Business or Susan the blogger.
ffang 9y ago
Easy? No, I believe it's very hard to setup a frontend project.
- cc81 9y ago
  1. install node.js 2. npm install create-react-app 3. create-react-app your-app 4. npm start Now you have a react app with a development up and running. To create a production build write "npm run build". To add a package write "npm install the-package".
- shados 9y ago

petra 9y ago

>> If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend Low-code tools are worth a look, depending on your task. Due to some reason, they are rarely mentioned at HN, But they already work very well for business apps, with some tools even claiming "pixel-perfect" ui creation, so maybe it can work well for consumer apps too. And Amazon/Microsoft and Maybe Google are all working/having on such tools, so it may indicate these tools are becoming popular.

cousin_it 9y ago

I think JS is fine. The root of the "problem" is that the web is an unusual platform. It actually punishes bloat, in a way other platforms don't. A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly. That means web developers must learn that code reuse is a tradeoff instead of seeing it as a pure positive. That's a good thing in my book. Either take the heat and replace your 10 dependencies with 1000 custom-written lines, which is usually easy in JS, or get out of the kitchen.

gaius 9y ago
* A native app can use a hundred libraries and a gigabyte of download size to do something trivial, but on the web that won't fly.* Except that native apps, in practice, don't do that, and websites routinely load 10Mb of JS when the user only wants to read a 5Kb article.
- cousin_it 9y ago
  The New York Times app for iOS is 119.8 MB.

gaius 9y ago

I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. JavaScript is a very badly designed programming language Let's take a step back here: the web is designed, from the ground up, for hypertext, interlinked documents comprising text and images, some of which are clickable and lead to other hyper-documents. HTTP - hypertext transfer protocol. "Web dev" should be referring 100% to things that happen on the server, which can be in any language you like, generating documents that are rendered as the end user would like. Forcing a thing designed for documents to run entire applications is what has gone wrong, it is, on the most fundamental level, an incredibly stupid thing to even try, but the entire industry did, and here we are today. It would be like MS declaring all Windows development henceforth will be in VBA macros for Word. This is why the real engineering disciplines don't take software engineers seriously. You would never see a civil engineer try and construct a bridge out of some completely inappropriate material...

bryanrasmussen 9y ago
it may be, on a fundamental level, an incredibly stupid thing to even try, but it also seems to have been an incredibly necessary thing and incredibly appreciated thing by most of the world.
- gaius 9y ago
  Necessary how? All the actually useful things you can do on the web you could have done with a 90s browser. I bet Amazon still works in one! Moving apps into browsers is a step backwards for most apps and most users. I was using Jupyter the other day; it’s clunky as hell compared to MathCAD from 20 years ago. We use 1000x the computing power, literally, to deliver 10% of the experience. Keeps a lot of devs employed I guess...
  - adventured 9y ago
    > All the actually useful things You're pre-emptively trying to define what's useful for everybody else. That's the only way your premise works. In my equally subjective view, XMLHttpRequest radically altered and improved the useful things you can do with the Web. You can't use a 90s browser for Google Maps, Gmail, YouTube, nearly any online productivity software, and dozens of other common activities on the Web today. You would have to strip the services down to make them work, ie turn them into completely different products. Simply put, most of the things most people do online today, can't function in a 90s browser. Just try using IE 5 or Netscape 4 with nearly any of the major Web services today. You can't. IE 5 with Facebook's non-mobile site? You have to build an entirely different product to make that work, basic interactivity drops to near zero. 1990s MapQuest sucked, big time. Google Maps is a radical improvement. How about simple things, such as smooth, fast, highly interactive stock charts, or real-time updating stock quotes, without having to reload the page constantly? 1998 browser? Nope. Would the user experience be better if everything on the Web adhered to strict 1998 standards? That's an obviously subjective opinion. I don't think so. Do people like to see instant previews of the content they're about to post to Facebook or Twitter? When they click the little upvote arrow, do they like to see an appropriate reaction? When posting basic content or interacting with simple site features, do they like having to reload the entire page?

z3t4 9y ago

can your web site be pre-rendered or rendered on the fly? then do server side rendering - only send html to the client. if you need dynamic rendering - use static js - only for those parts. if you need everything to be dynamic rendered eg live push, multiplayer games etc do full js rendering but do not use static html! only css/js. i think the complexity comes from web devs familiar with server rendering tries to use the same paradigm with dynamic sites for example angular and react. you should do it more like a desktop app instead of web page. if it makes sense do the rendering in canvas instead of the dom.

jugularkill 9y ago

You said it. You're not an expert. You are comparing a prototype based language to oop languages. You're basically putting the wrong fuel in a car and blaming the car. You are lazy in my opinion because yes there are few resources that teach you how to use the language properly but plenty that compensate for those who want to make it familiar to back end devs. If you looked for good resources you will slowly discover that most JavaScript developers do not understand the language well because of the same assumptions you are making. It's a highly misunderstood language due to human stupidity.

eitland 9y ago
While it is certainly possible to understand JS it is - IMO - a waste of brain cycles that we have to live with. There's no doubth in me that even very good Javascript programmers can be significantly better in a better language. E.g. Typescript gives you literally all of JS - and a way to keep things tidy. Typescript which is a compile-to-js language in a weird way proves how lacking js is - while still buildiing on top of it.
- jugularkill 9y ago
  "very good Javascript programmers can be significantly better in a better language." This is not how it works. Take this idea that JavaScript is a "badly designed language" out of your head and understand that about 99% of JavaScript's behaviours are intentional. The majority of gotchas in JS are shown by people who don't understand type coercion, prototypes or who expect it to behave like x language. It is not just misunderstood by your average Joe JS dev, but also by many who claim to be pros and experts. JavaScript is a language that doesn't tell you how to do things, there are no constraints. This is why so many people suck at it. They want to use statically typed classical inheritance constraints on a language oriented around higher-order functions, coercion and literally everything being an object. If you are somebody who is intuitive enough to create your own restrictions on what to use and what not to use in JS from the POV of the language's architecture then you will love it. If you are convinced that there is already a holy grail structure to programming languages then you will always have problems with JS. TypeScript is miserable. I see people building libraries in TypeScript and it's sad because they will never know how much better their performance could be or how small their lib size could be because the can only think in OOP. OOP languages are already hugely problematic when it comes to complexities. So imagine how overly complex the JavaScript eco system is becoming due to a generation of developers who want it to be more like x OOP language it does not have the foundation to be like. There is no defacto solution for software engineering everything still sucks, and nobody remotely has it figured out.

rco8786 9y ago

> There appear to be an excessive number of package managers involved. Largely agree with your assessment except for this. Which package managers are you referring to? 99% of the js world uses npm, and the other 1% uses yarn. I’m not aware of a single other package manager in the web ecosystem. In fact this is probably one thing where they got it right.

tatersolid 9y ago
Bower?
- LocalPCGuy 9y ago
  It's all moving to npm
LocalPCGuy 9y ago
And those 2 are largely interchangeable because they use the same repository (barring unusual setups)

naasking 9y ago

> I’m really not an expert in web dev, but it _feels_ like web dev has been badly engineered. It is, but it's getting better because so many different approaches have been tried that some of the more scalable and maintainable ones have been worked out. Also, (thank heavens) browser support is a lot more consistent now. > I need to build a website soon and I’m dreading the front end. If you're a software developer, I recommend some atomic/functional CSS toolkit, like Tachyons. That will free you from having to do probably 90% of the CSS work you used to have to do, and it matches a more programmer-type mindset to styling elements. I'm building a site now, and so far it I've just needed to define some style classes for the colours, and the rest of the styling is already included out of the box via their reusable classes. For the JS side, really depends what sort of dynamism you're looking for. You can go with a tiny JS library for polyfilling and standardizing browser behaviour [1] if you're just doing simple DOM manipulations, or if you expect to be doing a lot of AJAX with dynamic rendering, go with something like Surplus [2], or Vue, React or Mithril if you want something more standard. [1] https://github.com/naasking/PithyDOM https://github.com/naasking/PithyDOM [2] https://github.com/adamhaile/surplus https://github.com/adamhaile/surplus

deleted 9y ago

[deleted]

konschubert 9y ago

I feel like everyone is picking up on your language complaint, but maybe that is not your biggest concern. It seems like you give JavaScript as an example, but what really worries you is the complexity of the front end ecosystem. Here are a few ideas to reduce that complexity: Don't use a package manager, you can copy dependencies into folders. Remove steps from your build pipeline unless you really need them. Use ES16 to get native promises and imports. Or don't use ES16, so you can remove that step from your build pipeline. Use as few dependencies as possible. Whenever you can, make use of native browser behavior and CSS.

LocalPCGuy 9y ago
Less automation may help reduce his complexity, but will lead to more instances of breaking things do to mistakes due to manually performed steps. In general, I agree with part of your point - only use what you need. But make sure you are using the things you should.

dylanhassinger 9y ago

Node.js with ES6 is a dream. i love it

tastyham 9y ago

What is "PL"? I find it kinda funny that you compare to Python as the way you want webdev to be, since Python and JS are very similar in my mind, aside from minor syntax differences and JS keeping more warts from it's early days, they are very similar environments. I like Python and have been doing some Tensorflow recently, and one thing I've definitely noticed is that Python docs really suck compared to mdn JS docs. The biggest problem with JS on the other hand, is it's lack of a decent standard library so you have to use a lot more 3rd party libs, and setting up a modern babel/webpack/linter/test tool chain is a pain in the ass with so many different options to choose from.

rwaldron 9y ago
PL = Programming Language

terragon 9y ago

> Things are not pythonic. You say that like it's always a good thing. I remember I spent 4 hours trying to import a function from a file that was in a sibling directory before I finally gave up and copy pasted the function. There's also other things that really rub me the wrong way in Python. Once you get used to writing computations as a map/reduce/filter pipeline with fat-arrow functions in ES7, Python lambdas and list comprehensions feel so crippled and lacking in comparison. There's a lot of other things that ES7 does really well such as imports, asynchronous code with promises/async-await, array/object destructuring, the spread operator, etc. Don't get me wrong; I love Python and use it heavily in my day job, but it's not the end all and be all. There are fantastic libraries written for Python that make life really good (think Reportlab), but for applications that are highly asynchronous and I/O heavy, I'd take ES6 running on Node any day over Python.

davidjnelson 9y ago

You'll likely love typescript. You can spin it up with: npm install -g typescript then put this in a tsconfig.json file: { "compilerOptions": { "emitDecoratorMetadata": true, "module": "commonjs", "target": "ES5", "outDir": "ts-built", "rootDir": "src" } } then run tsc -w you can tweak the compiler for prod or debugging output etc. with these flags for the cli or the json config: https://www.typescriptlang.org/docs/handbook/compiler-options.html https://www.typescriptlang.org/docs/handbook/compiler-option... Then you could add a single css file in which you prefix class names using something like: myprojectuniquename__someelement. Then if you use async/await instead of callbacks, flexbox in your css, check supported browser features by googling 'caniuse feature', and use fetch for network access, you could have a pretty simple system that works for you in under an hour.

donohoe 9y ago

Javascript WAS terribly designed but still allowed su to do amazing things. I would argue that in the last 3 years its come a long way and is no longer a terrible language. I think complications of today came from the problems of its past where it was taken for granted that you needed a framework to get around browser differences. My personal and professional view has been use plain vanilla modern JS. Make an informed decision on whether using a framework makes sense for your particular project. If you're making a mess of JS, its more likley you need to re-evaluate your approach to the problem rather than the easy thing to do which is to blame the language.

elmelmelm 9y ago

Use elm.

Dash1909 9y ago

I read all of this, made a 8 paragraph long retort about the stupidity of backend devs in this thread, then deleted it. The reality is, if you don't currently serve a website 1,000,000 people want to use, just pick some terrible server side piece of crap and call it good. If you want 1,000,000+ people to use your website, you better learn that a dynamic user experience is expected, and delivered with eloquent javascript and design.

deleted 9y ago
[deleted]
ccachor 9y ago
Yes!!!!

mmargerum 9y ago

JS isn’t really terrible, I’ve done 25 years of c, c++, go, pascal, swift and I found js lack of typing refreshing. I built a fairly complex app in 4000 LOC. This would surely have been 10x bigger in any of the languages mentioned above. If you use es6, you get rid of the most common js issues (var hoisting, this scoping, etc) At some point 10x less LOC has to be factored in as a significant benefit

deleted 9y ago

[deleted]

jsvader 9y ago

TLDR; The language design of JavaScript is not the problem. There are 2 problems in my opinion: 1. Our reliance on typed languages, compile-time errors, and IDEs 2. Too many choices for frameworks and libraries. I wouldn't agree that JS is a poorly designed language. I will come back to that soon. I would argue, like some others here that we are just too lazy. We enjoy the safety provided by typed languages and compile-time errors. That is one reason to love our IDEs. Back to the problem. There are a lot of things that you are saying. I will try and address them one at a time. > web dev has been badly engineered. * Yes, no, and it depends. Web Dev is a very board, it encompasses many technologies, like HTTP, HTML, CSS, JS, Application servers, etc. So you are saying HTTP id bad? or HTML is bad? I know I'm reading it out of context, but bear with me. I believe you meant JS is bad. That brings us to your next opinion. > JavaScript is a very badly designed programming language. * When you say badly designed language, what is it that you exactly mean? Is it the syntax? Is it the grammar? Or is it the fact that it is loosely typed dynamic interpreted language? And what are the problems you talk of, any examples? > Is JS a recognized terribly designed language? * Who recognized it, any sources? Like the U.S.A. recognizes ISIS as a terrorist organization. I'm pretty sure the developers of node.js do not recognize that JS is a terribly designed language. > There are many frameworks for the same tasks, that try to do everything. * Yeah, I agree. I really hate having so many choices. I have to spend too much time investigating which is the best one for my use-case. I'm just too lazy. (sarcasm was intended) That said, I still agree, and it does make life hard. But too many choices is not a bad thing necessarily. > There "appears" to be an excessive number of package managers. * There is only NPM, everything else is either deprecated or based on NPM. Please inform yourself better. > ... range of solid and well-designed languages and technologies, but at the front end ... choose the least poor of a bunch of crazy options. * WHAT? There is only 1 option on the web today; JavaScript. Period. Unlike backend. What you are talking about are framework and libraries. Check the "too many choices" point above. If you believe that backend development has fewer choices involved, then I assume that you sir have limited experience. Anyway only recently has the community invested in improving this. Give it time, unless you believe something else can replace it before that.

machiaweliczny 9y ago

For website you don't need any libraries. You might consider some static site generator. For SPA go with create-react-app with react router with TypeScript and MobX and you will be satisfied. If you don't need/want to configure things swap webpack for parceljs.

jpjitendrapal 9y ago

I know when someone comes from C family language, he/she is not able to understand JS first but the person who knows JavaScript programming will never write like this. Actually JavaScript has few concepts those are much different compare to C family language like prototype and pure function which are superb. Even C family languages developer are now thinking to add few concepts from JS language.