11–20 of 23 posts
Why limit yourself to a client side JS framework? Certain server side frameworks such as rails let you build apps that feel very similar to client side js apps without having to use them.
"The best way to predict the future is to invent it". - Alan Kay Therefore, the obvious solution is to invent a new JS framework. To me, it looks like the Google team is committed to staying relevant based on their roadmap to 2.0. I personally feel confident AngularJS will be around in 5 years. Web components and dart fit well with angular, so I doubt it'll go the route of GWT.
Please, no more JavaScript frameworks unless you're doing something truly interesting, ala React with its virtual DOM or Angular with its.. everything. There are enough to go around already.
Why would you be "in a rut" if the way you built your site is no longer the latest fad in 3 years?
Sometimes a need arises for browser-based apps that are not on the net, usually as part of a system installed at a location without access to public internet for various reasons. If these systems are planned to have a life time of say 5-7 years, it would be best to not start developing parts of them with libraries and frameworks that are due to be phased out in just 2 or 3 years. E.g. AngularJS, the writing is clearl…
Why limit yourself to a client side JS framework? Certain server side frameworks such as rails let you build apps that feel very similar to client side js apps without having to use them.
How is Rails different from any other server side solution in creating apps that feel like applications?
I can't speak for other frameworks but rails has turbolinks and also seamlessly handles the ability to send back pre-compiled html results to the client as a response to an xhr.
Basically you get the best of both worlds and it's all unobtrusive so all of your content is crawlable and you get a great user experience without having to do hacks or extra work.
How do you write a modern web app and be sure it will still be maintainable in the 2-3 year time frame? There is no magic. 1. Write your code using standard JavaScript, avoiding corner cases and features that aren't universally supported. 2. Use libraries (you decide the architecture and when to call them) instead of frameworks (they establish the architecture and your code has to fit within it). Neither of these is…
I totally agree with this. When I first started working on my product (http://gitsense.com), I decided to use extjs and it did the job in the beginning. However, as I got better with JavaScript and became more design savvy, I found extjs to be an anchor. Getting it to work the way I wanted, basically required overriding everything and it was at that point that I decided I was better off going my own route.
Now I'm sitting at around 180,000 lines of custom JavaScript code. I still have some extjs code, but 98% of my current JavaScript code is custom. And it should last as long as my product does.
How do you write a modern web app and be sure it will still be maintainable in the 2-3 year time frame? There is no magic. 1. Write your code using standard JavaScript, avoiding corner cases and features that aren't universally supported. 2. Use libraries (you decide the architecture and when to call them) instead of frameworks (they establish the architecture and your code has to fit within it). Neither of these is…
"you can do more things quickly at first with these tools, but at the expense of introducing portability and maintenance overheads" I totally agree with this. When I first started working on my product ( http://gitsense.com ), I decided to use extjs and it did the job in the beginning. However, as I got better with JavaScript and became more design savvy, I found extjs to be an anchor. Getting it to work the way I wa…
Earlier quoted context omitted.
"you can do more things quickly at first with these tools, but at the expense of introducing portability and maintenance overheads" I totally agree with this. When I first started working on my product ( http://gitsense.com ), I decided to use extjs and it did the job in the beginning. However, as I got better with JavaScript and became more design savvy, I found extjs to be an anchor. Getting it to work the way I wa…
I'd definitely be interested in reading how you organize and maintain your codebase. Have you developed an in-house framework?
It's a bit involved to explain how it works, and I probably should do a blog post to explain it in detail. I'm pretty sure the solution that I have is what other big JS code bases uses, but I could be wrong. What I really like about it, is it lets me debug individual un-minified JS code.
The more that I think about it, my overall build and development environemnt/process is rather unique. My Java code base is about 100,000 lines spread over 200 Java files and I don't use maven or any ide. It's good old makefiles and vim with ant sprinkled in there.
There is a lot to blog about, so I'll see what I can come up with next week.
Build something people want.
Nobody cares what JS framework you use. Look at Craigslist.
Earlier quoted context omitted.
I'd definitely be interested in reading how you organize and maintain your codebase. Have you developed an in-house framework?
Yeah everything was in house. I can't remember how I came about my build solution, but it works amazingly well. If I do a quick find on my JS code base, I see that I have 343 JS files, which is spread over 44 directories. It's a bit involved to explain how it works, and I probably should do a blog post to explain it in detail. I'm pretty sure the solution that I have is what other big JS code bases uses, but I could…
Do you use map files for debugging unminified JS?