I’m a web developer and can't make anymore the simplest web app | Hacker News Reader

I’m a web developer and can't make anymore the simplest web app

medium.com

79 pointspistacchioso42 comments

I have yet to see a "modern" JavaScript project that wasn't a witches brew of shitty decisions and dependency hell.

The last one I looked at, had an npm dependency tree like crab grass. No less than 9 copies of the same module, all different versions between 0.x and 6.x - and all that module does is parse query strings.

The best part was when the developer of said module release v6 changing all `var`s into `let`s and `const`s and then basically responded to people who filed bugs along the lines of "fuck you not my problem".

The last few years have seen both JavaScript and PHP gain community powered package management tools that actively encourage this type of behaviour, and until cool-kid developers understand that they need to actually be aware of the code they're relying on, nothing will change.

This is so very, very silly. Yes, there are lots of options... just like development on any other platform or in any other language. If you allow yourself to be sidetracked by all the shiny things, of course you'll never get any real work done. And if decision paralysis is preventing you from even starting the project... well, I'm sorry to say you may not have the stamina that's needed to see a project to it's full completion.

Really, it's just so simple- Write the code that does the stuff. That's it. Everything else is bullshit. Pick a framework at random. Don't write tests. Use vanilla javascript. Don't bother with a build tool. That's really all there is to it. Every other decision is premature- you likely do not know your requirements yet, much less understand the costs and benefits of gulp vs grunt. Don't even try. Just start writing. When the problem becomes apparent, then cross that bridge. Yes, you will re-write a lot of code. Pull up your pants and get it done. Re-writing code is always better than never-writing code.

You don't need to collect all your tools before you begin. Just start your work.

> Yes, there are lots of options... just like development on any other platform or in any other language.

Errr, not really.

Let's pick a platform/language: Java

Build => maven (majority)

Unit-Test => JUnit (majority), Mockito (helper) Version => don't care, anything from Java 5 and above are good enough

Framework => Spring Framework or JEE (all batteries included)

Keep in mind either Spring Framework or JEE do component libraries so one does not have to use everything in there and they can mix-and-match.

spring-tests component provides stub objects for a few important JEE/Spring objects in case if you need them.

Ok, let's try one more time with: Ruby

Build => gems + rake + bundler

Unit-Test => Test::Unit or Rspec

Version => 1.8.7 or above, not a big issue, (having said that Rails do influence the version uptake)

Framework => Rails, Sinatra

I like what I'm seeing from these two ecosystems: high-quality tools that help me be more productive without spending too much time in either selecting or setting things up.

Well if we just want to pick majorities than we can do the exact same thing in JS.

Build => npm + Gulp (optional) + Webpack

Unit-Test => Karma + Jasmine or Karma + Mocha + Sinon

Framework => React+Redux+Data (modular) or Angular (all batteries included)

Same deal. High quality tools. You are pretending that there aren't hundreds of frameworks for Ruby (Cuba, Brooklyn, Scorched, Hobbit). The only people overwhelmed by choices are people afraid to make one.

It's not that simple I think.

For example, in the framework front, you guys argued that React is way better than Angular. I don't even know what's going on with Ember.js, Vue.js (fine, I'll give that this one is very new and untested), Backbone+Marionette.

I don't see that kind of argument in the other communities.

Your build: why are you omitting Grunt? What about broccoli and bower? what about Yeoman? Bower is kind of a big deal for front-end dev.

There's no "majority" in the JS world unlike the other ecosystems.

Cuba? I heard Cuba _once_ in HN. Brooklyn and the rest? never heard.

There are bajillion newer Java "microservice" frameworks but the usage is just rounding error.

Also keep in mind that in other ecosystems, the major players are already established while in JS ecosystems, all of them are considered new/young. There is no _established_ players for each tool segment (except unit-testing where I think Mocha is better than Jasmine, unfortunately due to lack of exposure and whatnot, Jasmine is still lurking around)

> Write the code that does the stuff.

But that's far from what I usually want from my code.

I want the code that is easy to change, code that I understand, code that is reliable, code that works well with garbage data, code that will still be maintainable after I extend it. Having reasonable performance (notice, I'm not saying the best performance, just reasonable) is a must, too.

And in most other cases, when I move to a new tech, I get most of it pretty quickly. Of course, there's some learning involved, but I never aim just for code that "does the stuff". Just "doing the stuff" is so abysmally insufficient for good software that I don't expect any programmer to be satisfied with this single requirement.

And yet, having a product that just just barely holds together is the best I could have hoped for, given the time and money constraints. And my barely working stack of crap is better than most other products, because most folks can't even get that far.

Easy to change? Reliable?! Maintainable?!?

Bah humbug! Who needs it? Not me. I'll probably trash this version anyways! If I can get the thing to do one thing reasonable well, it's a winner. The code quality is always secondary to actually getting something done. Once you have a product and some customers and you've proven that it won't explode, then we can talk about performance. But I've seen too many projects strangled under the high-minded ideals of better programmers than I.

If the issue is really making the simplest web app, the principal of YAGNI should be applied liberally.

Complex dependencies that add up-front development burden should be added only if, and only when, there is an expected benefit justifying the cost.

Amen! I wrote a handful of offline-cacheable HTML5 apps made simply with CSS, vanilla JS, and HTML. Nothing more! Don't write a single line or character you don't need in the final result.

I have 'app update fatigue' and often after I update an app I end up preferring previous versions I can no longer install or use again once they're 'updated away' and no longer current. My wants for what my phone or tablet can do are really simple, but I just don't want to have to wait to update anything I've already taken time to save to be sure I'd have when I needed it.

So I wrote the following apps and they all have manifests and icons. I have plenty more pages I use that aren't as polished (like http://staticresource.com/base64.html) but this whole exercise has made me feel like I have some control back over my phone.

Doesn't matter iOS or Android, I can always run my crappy little apps equally as crappy everywhere, and I know they'll never need updating, needlessly waste my battery, include malware that's tracking me or spying on me, and they do much of what I would use the device for anyway! If I've learned anything it's that building your own tools is VERY worth it, and I should invest more time in learning how to do this and doing it :)

Sketch

- View: http://staticresource.com/sketch.html

- Source: http://staticresource.com/inspect?/sketch.html

Sketch is a browser-based sketchbook! Draw with the mouse or your finger and export SVG by email or download.

---

SpeedTest

- View: http://staticresource.com/speedtest.html

- Source: http://staticresource.com/inspect?/speedtest.html

SpeedTest is for responsive web testing. Load a URL into the input and press Go or hit 'enter' to load a page into the window below. Pressing the buttons (or keyboard keys 1-0) will resize the window allowing you to quickly test sites at a variety of widths on desktop, and allow you to test sites at widths other than your device width on mobile.

---

Reminders

- View: http://staticresource.com/reminders.html

- Source: http://staticresource.com/inspect?/reminders.html

Reminders is a lightweight reminders app that uses localStorage. Helpful for grocery lists or to-do items.

---

Encode/Decode

- View: http://staticresource.com/encode.html

- Source: http://staticresource.com/inspect?/encode.html

Encode text by shifting its unicode character range. Decode by reverting the text back to the regular character range.

---

Clock

- View: http://staticresource.com/clock.html

- Source: http://staticresource.com/inspect?/clock.html

Analog clock made from JavaScript and CSS

---

Snake

- View: http://staticresource.com/snake.html

- Source: http://staticresource.com/inspect?/snake.html

Move the mouse or touch the screen to draw a rainbow snake on the screen

---

Shuffle

- View: http://staticresource.com/shuffle.html

- Source: http://staticresource.com/inspect?/shuffle.html

Tap the page to draw a new random card and roll a die (unlimited decks)

Virtual Deck of Cards

- View: http://staticresource.com/deck.html

- Source: http://staticresource.com/inspect?/deck.html

1 deck of cards, shuffled,flippable, no rules, no dealing. You can play solitaire, it's just like a real deck of cards you have to deal it yourself :)

---

Calc

- View: http://staticresource.com/calc.html

- Source: http://staticresource.com/inspect?/calc.html

Calc is a very basic calculator to demonstrate how JavaScript can think about strings

---

Piano

- View: http://staticresource.com/piano.html

- Source: http://staticresource.com/inspect?/piano.html

Piano is a small synth with a piano keyboard, capable of generating square waves on the piano scale to make noise for tuning things, or sketch out a melody, or just to jam around when bored.

I also have my own personal web-based 'command line interface' called JOE that end up being my most-used website and app on whatever device I'm using. I use this to check the weather and USD at least once daily, plus many more times for other things: http://staticresource.com/

is there a reason you decided to list all of these apps unsolicited? nobody is going to read these

is there a reason you decided to be unpolite unsolicited? nobody is going to appreciate that

I looked at a couple. Probably for the same reason a girl in the mall looks at how other girls are dressed. And my analysis... OMG such a slut! (kidding... but I do like looking at other people's work).

Yeah! A couple of years ago I thought JavaScript was hard, and I couldn't figure out how to do what I wanted. Somebody posted a teeny tiny code editor here on Hacker News and seeing the source code sparked something, and now I'm writing and releasing my own HTML apps and tools that help me and others.

I listed these here (with the source) to show how small and how LITTLE code you need. Each of these files are single-file apps - icon included! Many of these I either started or created on my iPad, showing that building HTML apps can be so simple that you can execute on the device itself.

I'm just putting it here hoping it can help somebody else. If that's no you, that's fine - but if it is I'm glad I took the time to write them out :)

I looked at them and bookmarked your comment listing them. Thanks for posting them.

I share your motivation -- a while back I wrote a web app for myself that gave me my daily checklist. It was a great experience. Your apps have renewed my interest in this idea and given me some inspiration. Thanks!

What's up with decoding the JS and using eval?

any time you see 'encoded' JS it's just the canvas-based icons (like this: http://codepen.io/tomhodgins/pen/VvjNKq ) being minified and encoded just to keep it out the way.

If I made the icons as PNG's I'd have embedded them as `base64` encoded blobs of data, but in this case the icons are JS that gets decoded and run to draw the icon, then attach it to the page as favicon and apple-touch-icon.

I wrote a short post about how I put together these teeny tiny HTML5 apps if you're interested: http://codepen.io/tomhodgins/post/building-an-html5-app-for-...

> Remember, this is a simple personal project, I mostly wanted to have fun, so my mind was set to zero-tolerance mode. As soon as something annoyed me I went away looking for something else to smoothen my experience

...

> Javascript mixed with HTML seems ugly after having tried React

I think these highlight the real problem. Because we are constantly bombarded by such cool tech, it is easy to notice that some aspect of something could be done in a better way. The key to success is to ignore those minor papercuts and just focus persisting on your own project.

Here is a great link from today. "JavaScript fatigue fatigue" http://www.2ality.com/2016/02/js-fatigue-fatigue.html

> Don’t try to know everything – it’s impossible in modern web development.

I didn't get this whole "JavaScript fatigue" thing...

When I started web development. There already was a bunch of different stuff and no one tried to learn it all.

Pearl, PHP, .Net, ColdFusion, Java and what not...

I suspect that part of it was because there was a brief time when there appeared to be (at least, in certain important segments of the non-enterprise market) a consolidation around a fairly narrow set of frameworks, tools, and approaches in web development, and that time roughly corresponded with a point in time when web development itself was really taking off and drawing lots of people in -- this roughly corresponds with the height of Rails ascendancy for the server side.

As a result, there's a lot of people who started web development at a time when it may have seemed, if not simpler, less diverse in terms of strongly-supported options -- and trending toward greater consolidation, rather than greater diversity. For those people, the current state of web development could legitimately be a surprising array of more-complicated-than-they-would-have-expected decisions, with lots of opportunities for analysis paralysis.

I'm getting really tired of these sort of posts/comments on how hard it is to make a "simple website" these days. If you want to make a website the old way no one is stopping you. Tools exist because no one wants to do it the old way because the old way sucks.

Which combination of tools should you use? Ember if you have no idea where to start - otherwise thing about the problem you have with other tools and find tools that solve those problems.

I wonder how many people can rewrite the same article?

As long as there are yaks to shave.

The title is misleading. Should be changed to "I'm a web developer and I realized that chasing after every new tech under the sun can be counterproductive".

I do agree that with the semi-recent "resurgence" of Javascript there's an abundance of frameworks and tools out there both for the client and server side making the selection of the "ecosystem" that would fit your needs challenging.

My take on this is stick to the basics until you realize that you need to look into something new. Client-side technology upgrades are reasonably simple as long as the client-server contract is defined up front (we doing old school gets/posts or ajax or wss etc?).

Server-side decisions are a little more tricky than that but once you commit to a definite decision on the server side tech, the specifics can be worked out down the road without affecting the client.

The content of the article is read rather like "I've been stuck with the simplest app for 10 days because I didn't really want to create one". If you want to create an app, you go and create one. If you want to play with a bunch of fancy frameworks, just don't call it "create an app", as apparently it isn't...

Two way binding is hard in react? I never noticed. My only react app so far is basically a giant form (I split it into 5 tabs based on categories so there wasn't too much on the page at a time), and I had zero problem doing so.

Granted the analysis paralysis wasn't so bad as react was much newer when I started, so I didn't even look at redux (though looking at it now, I'm still not sure what problem I was supposed to have that it solves).

As far as packing everything into a single file, I used make which would pipe cat through a minifier (or not minified with "make debug").

So ironically, I suppose all these new tools have made it harder to get started on React, which is perhaps the point of the article.

How many more of these articles do I have to read?

How many more of these comments do you have to read?

> I envisioned the opportunity to try out a few new things I’ve been reading about online, refresh my web-dev tools and have some fun.

> The core of the problem is choice and the overwhelming abundance of tools to choose from.

Excuse me, did you want to try out a few new things, refresh web-dev tools, have some fun or start coding immediately?

Because, it looks like: I am chief-cooker and i can't cook simple meal. There are so much vegetables, juices, it looks like a game.

> I want a bread for my meal.

Leavened, Rye, Flatbread?

Uhhh, ohhh, it's too haaard, i wanted to try new things, but I'm seeking for best, standard choice.

> Excuse me, did you want to try out a few new things, refresh web-dev tools, have some fun or start coding immediately?

These two things don't have to be mutually exclusive. In any other area of programming that I've tried recently, they're not — except for JS-based web development.

Tell us, in what area you've refreshed your dev tools and started coding immediately.

I remember I was trying to replace maven with gradle in Java -- it was fail because I wasn't able to add new repository to gradle. I'm still not sure how to it.

> I’ve already laid out my models, but React.js likes to mix models and states and properties, so I had to rethink it

=> Redux

> this Gulp configuration file...

=> Webpack

This might be opinionated but for a personal SPA pet project without any legacy a good up to date stack has ES6/Babel, React, Redux, Webpack included. Curious what others prefer.

You just described his exact problem. He's confused by react so you tell him to use redux. He's intimidated by gulp so you tell him to use webpack.

It doesn't matter what he uses, he just wants to write code and everyone telling him to use some other marginally different tool is just contributing to the paralysis.

> He's confused by react so you tell him to use redux.

I meant React + Redux, Redux or Flux is the missing piece for React. He used just React wondering how to manage the models, if he got a bit deeper in the React ecosystem he would have seen Redux or other Flux based frameworks. Besides, the React team and site explicitely states that some architecture such as Flux is required, so guess he just dipped just into React before he wrote his JS fatigue post.

> ...marginally different tool

Wouldn't agree with this. Tools/libs/frameworks are quite different and you can decide by comparing and having personal preferences. And the more choice the better tools. I don't know of any other ecosystem where such strong competition leads to so many innovations. Eg: Webpack, Redux and all the new kids on the block have significant learning curves but do this investment and you learn new stuff every minute and afterwards you are enlightened (if you like tech) because you find always something which works 10x better/faster/easier/more elegant than existing solutions. If you just want to get a job done, then learning new stuff might be perceived as too time-consuming and sticking to learned stuff allegedly seems easier.

This. If you read the comments here seems like I've been stuck in analysis paralisis because I didn't use Redux, Webpack, Clojurescript, Ember. Guess what? Maybe I should investigate those four, right? This surely solves the problem. /s

> It doesn't matter what he uses, he just wants to write code

Good, then he can stop reaching for new libraries and frameworks every time he gets "confused" or "intimidated". Invest the effort to learn one of them in-depth and the knowledge will still be applicable to new tools that come along. After all, they're just "marginally" different.

ClojureScript. Just learn that; the ClojureScript community will keep it up with the times, and you can help out too at times. Yes, you'll have to debug a little under the hood, but your background should be sufficient for that.

The solution is to use a boilerplate/generator. I've used one for every JS project I've started in the past two years.

The main benefit is that you get something that already has the whole development/test/build workflow set up, with your framework of choice. Then you can tweak things as necessary.

Since all of the processes should be able to be run through a small set of CLI commands, there isn't much mental overhead switching between projects.

Seems like the author just has trouble making good choices.

I think you're right. At least build the thing first and then improve on it. Like, if you want to use TypeScript, try vanilla JS first, then rewrite it - not as hard with small projects.

> Having worked mostly with C# in the last months, I remembered how cool it is to have a statically typed language

Really? I used to work with Java. I sometimes miss type checking, but I don't miss the Java type system - is C# a lot better?

I find C# to be better, but things are ok everywhere as long as they're kept easy. I think that function (param?: Array) is simply better than function (param) because the IDE can hint you that the function accepts a single parameter, that it is optional and warns you if you try to pass a string because it must be an Array.

Reply on news.ycombinator.com